Enjoy your stay in Hotel Gitmo! Wake-up calls begin at 3AM. What makes you think he's going to need a wake-up call. Wake-up calls assume you were asleep.
Personally, I find aesthetics to be a perfectly valid reason to preserve the pristine nature of something, be it a natural area here on Earth or somewhere out in the stars. Whole theories of philosophy have been predicated solely on aesthetics. Simply because you're an uneducated boor who can't appreciate beauty for its own sake, doesn't mean that the rest of us should suffer to live in your cold, sterile world.
That said, I don't necessarily think we could ever damage Saturn to the point of destroying its beauty... it's huge! And if we do somehow develop the ability to damage it, I would hope that there would be more people like me who want to preserve it than people like you who are willing to destroy it for some temporary advantage.
Heh. I've got that one too... need to get around to flying it though. And I don't think Tim Van Milligan was ever expecting a slashdotting:) Reminds me I need to get back to building and flying... been working too hard.
You should already have the test cases, and if the other places it's being used depend on the broken behavior _their_ test cases should now fail.
Re:Lemme check my last home appraisal...
on
Linus on GIT and SCM
·
· Score: 3, Insightful
The thing is, you've got the wrong solution to the problem. Rather than not allowing branches, you need to control when and how often they're made, and how long they're allowed to survive. Your fixing a policy problem with technology, which never works well. If the branches are kept under control, you don't have the last-second merge problem. Merges should be happening constantly throughout the process so everyone stays in sync. If someone isn't committing their work at least once a day, that's when they get a stern talking to from the lead developer. Because if a developer needs to coordinate with another developer to change one line of code, then you've wasted two people's time instead of one.
Which illustrates the proper use of the term unpossible... something that is impossible but clearly has happened or is happening. Generally used (by me) when software misbehaves in unexpected ways. Unpossible things can have a wide variety of causes, from race conditions to library incompatibilities, and are especially aggravating to debug because the failure is usually due to a subtle misunderstanding of the software or its environment.
Yes, I'm yelling, but damned, I'm tired of only hearing people bashing NASA here. What has any other agency private or public done that comes anywhere near the achievements of NASA? When someone is designing an aircraft, where do they go for data to calibrate their simulations? NASA. What agency has launched more successful missions out of Earth's gravity well? None, but NASA. Sure, they're a big, slow moving organization... but try to do what they've done with a smaller organization. It won't work.
And of course, a private engineer would never CYA. No matter if there's a failure, he'd be legally liable, he sure as well wouldn't CYA. If you're not sure what the effect is, it's better to err on the side of caution, especially when lives are at stake. Now, stop being a dumbass; this is a good engineering decision... they've assessed the risk, and they don't have to replace the tank.
Someone who thinks Clearcase is the worst example of configuration management software has obviously never used CMSynergy. Maybe it's just the way our CM group have things set up, but I find it gets in the way more than any other CM system I've used.
I definitely have to agree about Rose. I can't speak to XDE (or whatever they call it now), but RealTime sucks goat balls, at least if you're developing in C++. First, if you want to use the STL, you have to add it to the model yourself (granted, that's a problem with pretty much every model-driven development tool... you'd think it'd occur to someone that they should include models for standard libraries). Unfortunately, their code analysis tool sucks, so if you try to use that to reverse engineer the libraries you're using, it'll take more time than just adding the classes by hand.
Second, it doesn't properly understand templates... if you want to declare a template function, you need to define an empty macro to use as the return for the function, and then put the entire template declaration into the name field, otherwise it won't generate the correct code. If you want to create a class that inherits from an instantiation of a template, you have to first create an instantiated class (essentially a typedef naming the parameters to the template), unless the new class itself is a template, in which case you can do the inheritance directly. It's also terrible for doing round-trip engineering, since it only allows you to make changes in specific marked places in the code, so if you discover you need a new attribute or whatever, you can't just add it and have it show up in the model on the next round trip... you have to round trip it, and then add it in the model and regenerate the code.
All that said, it does have some nice things, too... the RealTime Services Library is (mostly) well designed, though some of the design decisions they made seem rather arbitrary (e.g.: you can dynamically resize the replication of a port, but you can't dynamically resize the replication of a capsule role).
Re:You have no idea what you're talking about
on
SQL Hacks
·
· Score: 4, Insightful
What you've just illustrated is one of the biggest problems I see with computer science education today. It seems that the kids coming out of computer science programs have absolutely no idea what has come before. They have no sense of the history behind the technologies they're learning, and so are blind to the fact that they're simply repeating what has already been done. If you don't know where you came from, how can you know where you're going to?
Car: You appear to be trying to start me. User: Yes. Car: Are you sure? User: Yes. Car: Really? There's a slight change in the current draw on the starter motor. Maybe you want to talk to a mechanic? User: Just start, dammit! Car: OK. -click-click-click- -BOOOOOOOOM-
The feature is a bad solution to the problem of users accidentally destroying their work. Undo, the trashcan/recycle bin, and versioning are all much better solutions than confirmation. Especially since, if you ask the users to confirm everything, they'll end up still losing the data. Why? Because the common case is that yes, they do want to perform the action being confirmed, so they'll inadvertently train themselves to blindly click yes. Rarely will they realize their mistake until after the confirmation.
Just like the annoying confirmation Slashdot is giving me because I moderated in this discussion:)
RPG guidance systems are easy... they're passive... i.e. they don't have a guidance system. Just make sure the center of pressure is in front of the center of gravity, and it'll fly straight enough for a short distance, say 100 yards. Any further, you've got to take ballistics and wind into account... but you can get some pretty impressive ranges if you don't care what you hit:). I've got a passively guided 3-stage rocket design that, under the right conditions, could put a 1 pound payload 3 miles down range. Granted that's based on a simulation with fairly ideal conditions (i.e. no crosswinds), and it was using a engine that would probably have shred it if it was constructed as designed (iow, a working version probably wouldn't go as far, since it'd be heavier). But, considering I didn't design the rocket to be used for long-range bombardment (it was designed to see how high an altitude I could get on engines that I didn't need a permit to buy), it's pretty impressive. A one stage design with the same power would've been better, but I was too lazy to throw one together:)
Active guidance systems actually aren't easy, but certainly could be done (and have been done by hobbyists). The hardest part is getting the sensors small enough that you can still have a useful payload. You can get them fairly easily now (though they're pretty pricey--$42 for a 1-axis gyro--and you'd need three per missile) but you probably couldn't make them. Then you'd need microactuators that again, you probably couldn't build. Finally, you'd need some kind of target recognition system... probably the Mk.1 human would be the simplest (i.e. radio or wire-guidance), though a heat-seeker wouldn't be terribly hard.
A more difficult problem than making an active guidance system is coming up with a powerful enough propellant that won't raise alarm bells saying "Hey! This guy's making rockets!". That and getting the explosives for the warhead without raising the same flags. Already, if you want to purchase model rocket motors containing more than 62.5 grams of AP propellant, you must have a low-explosives user permit, and access to an approved storage facility which has been inspected by the ATF (and usually the local fire marshall as well). So, unless you can make your own propellant, you won't be able to buy it covertly. For small payloads, like that on an RPG, you probably can use black powder, but anything larger you need a more efficient propellant. I'm not an expert on making your own propellants, so I can't really comment on what's out there that you could make in a clandestine lab without raising too many flags.
First, none of DPRK's missiles are in silos. The Nodong is launched from a mobile platform like a Scud. In fact, it pretty much _is_ a Scud. Mobile launchers are extremely easy to hide in the rough terrain of North Korea. Not that it really matters, since there's no way a Nodong could mount a first-generation nuclear warhead, nor does the Nodong have the range to reach the US, so it's no threat (to us). Second, as has been mentioned elsewhere, North Korea has the 5th largest army in the world. They don't need to be surrounded by people pouring in to create an insurgency... that army combined with the terrain is quite capable of creating a quagmire on its own. Or perhaps you never heard of the Korean War? Third, the main strategic reason to fight North Korea is to protect South Korea and Japan. The moment we attack North Korea, shells start dropping into downtown Seoul from the thousands of fixed and mobile artillery emplacements on the border. We can't possibly hit all of them in a first strike, and each individual emplacement can put several shells a minute into Seoul. The South Korean government is destroyed, the economy collapses, and no matter what we do to North Korea, we've lost the war. Oh, and remember those Nodongs that can't hit us and that we can't find in the rough terrain? Well, they're perfectly capable of hitting Japan, including Tokyo. Again, Japanese government collapses, along with its economy, and we lose the war. And that doesn't even require North Korea to use its chemical and biological weapons stockpiles. Oh yeah, and (for now at least) China has agreements to protect the North in case of an invasion. In addition, as other posters have mentioned elsewhere, even without those agreements, China cannot accept an American presence in the North. We definitely can't win _any_ kind of conventional war with China.
Now, if China renounces its defense commitments to DPRK, and then invades, then we could conceivably move from the south to support such a move. In fact, we would almost have to move north, to prevent China from gaining all of North Korea. However, for the past 50 years, the North's entire defensive plan has centered around an attack from the south, with Chinese reinforcements from the north. In addition, China can cross the Yalu near the eastern coastline, and move quickly through the lowlying coastal areas straight to Pyongyang, while we'd have to cross some of the most difficult terrain in the country. This means that effectively China could move further south faster than we could move north thus gaining a large portion of the most populous parts of North Korean territory, including Pyongyang, which it most likely will not let go. That's bad for the South Korean economy, since (again, others have mentioned this... I'm just bringing it all together in one place) South Korea needs a slow, controlled reintegration with the North to fuel its own economic expansion in order to compete with China. Again, our primary strategic interest in the area is to protect trade with South Korea and Japan. We need to be able to play both of them economically off of China, to keep China in check. Again, we lose in this scenario.
When it comes right down to it, the only way for us to win a war in North Korea is not to fight it, and to prevent (through diplomacy) China from fighting it for us.
Apparently, none of these students have read the IP policy at their school. At least at my University, anything you turn in for a grade becomes the property of the University. By turning it in, you have implicitly waived your intellectual property rights over it anyway. Granted, I don't think that's fair in the first place, but the simple fact is that many of the students don't have any rights to the papers to begin with.
They'd also be useful for process improvement. One method of measuring the quality of of your QA process that we (briefly) studied in one of my software engineering classes is a technique called defect seeding. Basically, before sending a unit to QA, you inject known defects. By measuring how many of the known defects were caught by QA, you can get an estimate on the effectiveness of your QA process. The problem is injecting realistic defects. You could use this tool before sending the unit to QA to find a set of known defects, that most certainly are realistic, because they're real defects. Of course, if your QA organization uses this tool as well, then your defect detection metric is boned... but QA shouldn't be looking at the source, anyway.
Slashdot Mirror
Personally, I find aesthetics to be a perfectly valid reason to preserve the pristine nature of something, be it a natural area here on Earth or somewhere out in the stars. Whole theories of philosophy have been predicated solely on aesthetics. Simply because you're an uneducated boor who can't appreciate beauty for its own sake, doesn't mean that the rest of us should suffer to live in your cold, sterile world.
That said, I don't necessarily think we could ever damage Saturn to the point of destroying its beauty... it's huge! And if we do somehow develop the ability to damage it, I would hope that there would be more people like me who want to preserve it than people like you who are willing to destroy it for some temporary advantage.
If only they would be a better influence...
So in other words, make sure not only to empty your longs, but let rip a big long fart before you open that airlock.
So, would that be lawful or chaotic, good or evil? Personally, I think sysadmins tend toward chaotic evil, myself...
(come on, somebody had to make the joke:)
Did it ever occur to you that the AI drivers were worthless because they were meant to simulate a _human_ driver?
I think they're also satirizing B5 there... but either way it's incredibly funny... haven't seen that episode, but could definitely picture it.
Heh. I've got that one too... need to get around to flying it though. And I don't think Tim Van Milligan was ever expecting a slashdotting:) Reminds me I need to get back to building and flying... been working too hard.
You should already have the test cases, and if the other places it's being used depend on the broken behavior _their_ test cases should now fail.
The thing is, you've got the wrong solution to the problem. Rather than not allowing branches, you need to control when and how often they're made, and how long they're allowed to survive. Your fixing a policy problem with technology, which never works well. If the branches are kept under control, you don't have the last-second merge problem. Merges should be happening constantly throughout the process so everyone stays in sync. If someone isn't committing their work at least once a day, that's when they get a stern talking to from the lead developer. Because if a developer needs to coordinate with another developer to change one line of code, then you've wasted two people's time instead of one.
Which illustrates the proper use of the term unpossible... something that is impossible but clearly has happened or is happening. Generally used (by me) when software misbehaves in unexpected ways. Unpossible things can have a wide variety of causes, from race conditions to library incompatibilities, and are especially aggravating to debug because the failure is usually due to a subtle misunderstanding of the software or its environment.
Yes, I'm yelling, but damned, I'm tired of only hearing people bashing NASA here. What has any other agency private or public done that comes anywhere near the achievements of NASA? When someone is designing an aircraft, where do they go for data to calibrate their simulations? NASA. What agency has launched more successful missions out of Earth's gravity well? None, but NASA. Sure, they're a big, slow moving organization... but try to do what they've done with a smaller organization. It won't work.
And of course, a private engineer would never CYA. No matter if there's a failure, he'd be legally liable, he sure as well wouldn't CYA. If you're not sure what the effect is, it's better to err on the side of caution, especially when lives are at stake. Now, stop being a dumbass; this is a good engineering decision... they've assessed the risk, and they don't have to replace the tank.
Ah yes! We definitely need more globetrotter algebra
Hey Adam! is that you? I'm glad I was able to enlighten you somehow:)
Someone who thinks Clearcase is the worst example of configuration management software has obviously never used CMSynergy. Maybe it's just the way our CM group have things set up, but I find it gets in the way more than any other CM system I've used.
I definitely have to agree about Rose. I can't speak to XDE (or whatever they call it now), but RealTime sucks goat balls, at least if you're developing in C++. First, if you want to use the STL, you have to add it to the model yourself (granted, that's a problem with pretty much every model-driven development tool... you'd think it'd occur to someone that they should include models for standard libraries). Unfortunately, their code analysis tool sucks, so if you try to use that to reverse engineer the libraries you're using, it'll take more time than just adding the classes by hand.
Second, it doesn't properly understand templates... if you want to declare a template function, you need to define an empty macro to use as the return for the function, and then put the entire template declaration into the name field, otherwise it won't generate the correct code. If you want to create a class that inherits from an instantiation of a template, you have to first create an instantiated class (essentially a typedef naming the parameters to the template), unless the new class itself is a template, in which case you can do the inheritance directly. It's also terrible for doing round-trip engineering, since it only allows you to make changes in specific marked places in the code, so if you discover you need a new attribute or whatever, you can't just add it and have it show up in the model on the next round trip... you have to round trip it, and then add it in the model and regenerate the code.
All that said, it does have some nice things, too... the RealTime Services Library is (mostly) well designed, though some of the design decisions they made seem rather arbitrary (e.g.: you can dynamically resize the replication of a port, but you can't dynamically resize the replication of a capsule role).
What you've just illustrated is one of the biggest problems I see with computer science education today. It seems that the kids coming out of computer science programs have absolutely no idea what has come before. They have no sense of the history behind the technologies they're learning, and so are blind to the fact that they're simply repeating what has already been done. If you don't know where you came from, how can you know where you're going to?
Car running Windows Automotive:
Car: You appear to be trying to start me.
User: Yes.
Car: Are you sure?
User: Yes.
Car: Really? There's a slight change in the current draw on the starter motor. Maybe you want to talk to a mechanic?
User: Just start, dammit!
Car: OK.
-click-click-click-
-BOOOOOOOOM-
The feature is a bad solution to the problem of users accidentally destroying their work. Undo, the trashcan/recycle bin, and versioning are all much better solutions than confirmation. Especially since, if you ask the users to confirm everything, they'll end up still losing the data. Why? Because the common case is that yes, they do want to perform the action being confirmed, so they'll inadvertently train themselves to blindly click yes. Rarely will they realize their mistake until after the confirmation.
Just like the annoying confirmation Slashdot is giving me because I moderated in this discussion:)
RPG guidance systems are easy... they're passive... i.e. they don't have a guidance system. Just make sure the center of pressure is in front of the center of gravity, and it'll fly straight enough for a short distance, say 100 yards. Any further, you've got to take ballistics and wind into account... but you can get some pretty impressive ranges if you don't care what you hit:). I've got a passively guided 3-stage rocket design that, under the right conditions, could put a 1 pound payload 3 miles down range. Granted that's based on a simulation with fairly ideal conditions (i.e. no crosswinds), and it was using a engine that would probably have shred it if it was constructed as designed (iow, a working version probably wouldn't go as far, since it'd be heavier). But, considering I didn't design the rocket to be used for long-range bombardment (it was designed to see how high an altitude I could get on engines that I didn't need a permit to buy), it's pretty impressive. A one stage design with the same power would've been better, but I was too lazy to throw one together:)
Active guidance systems actually aren't easy, but certainly could be done (and have been done by hobbyists). The hardest part is getting the sensors small enough that you can still have a useful payload. You can get them fairly easily now (though they're pretty pricey--$42 for a 1-axis gyro--and you'd need three per missile) but you probably couldn't make them. Then you'd need microactuators that again, you probably couldn't build. Finally, you'd need some kind of target recognition system... probably the Mk.1 human would be the simplest (i.e. radio or wire-guidance), though a heat-seeker wouldn't be terribly hard.
A more difficult problem than making an active guidance system is coming up with a powerful enough propellant that won't raise alarm bells saying "Hey! This guy's making rockets!". That and getting the explosives for the warhead without raising the same flags. Already, if you want to purchase model rocket motors containing more than 62.5 grams of AP propellant, you must have a low-explosives user permit, and access to an approved storage facility which has been inspected by the ATF (and usually the local fire marshall as well). So, unless you can make your own propellant, you won't be able to buy it covertly. For small payloads, like that on an RPG, you probably can use black powder, but anything larger you need a more efficient propellant. I'm not an expert on making your own propellants, so I can't really comment on what's out there that you could make in a clandestine lab without raising too many flags.
First, none of DPRK's missiles are in silos. The Nodong is launched from a mobile platform like a Scud. In fact, it pretty much _is_ a Scud. Mobile launchers are extremely easy to hide in the rough terrain of North Korea. Not that it really matters, since there's no way a Nodong could mount a first-generation nuclear warhead, nor does the Nodong have the range to reach the US, so it's no threat (to us). Second, as has been mentioned elsewhere, North Korea has the 5th largest army in the world. They don't need to be surrounded by people pouring in to create an insurgency... that army combined with the terrain is quite capable of creating a quagmire on its own. Or perhaps you never heard of the Korean War? Third, the main strategic reason to fight North Korea is to protect South Korea and Japan. The moment we attack North Korea, shells start dropping into downtown Seoul from the thousands of fixed and mobile artillery emplacements on the border. We can't possibly hit all of them in a first strike, and each individual emplacement can put several shells a minute into Seoul. The South Korean government is destroyed, the economy collapses, and no matter what we do to North Korea, we've lost the war. Oh, and remember those Nodongs that can't hit us and that we can't find in the rough terrain? Well, they're perfectly capable of hitting Japan, including Tokyo. Again, Japanese government collapses, along with its economy, and we lose the war. And that doesn't even require North Korea to use its chemical and biological weapons stockpiles. Oh yeah, and (for now at least) China has agreements to protect the North in case of an invasion. In addition, as other posters have mentioned elsewhere, even without those agreements, China cannot accept an American presence in the North. We definitely can't win _any_ kind of conventional war with China.
Now, if China renounces its defense commitments to DPRK, and then invades, then we could conceivably move from the south to support such a move. In fact, we would almost have to move north, to prevent China from gaining all of North Korea. However, for the past 50 years, the North's entire defensive plan has centered around an attack from the south, with Chinese reinforcements from the north. In addition, China can cross the Yalu near the eastern coastline, and move quickly through the lowlying coastal areas straight to Pyongyang, while we'd have to cross some of the most difficult terrain in the country. This means that effectively China could move further south faster than we could move north thus gaining a large portion of the most populous parts of North Korean territory, including Pyongyang, which it most likely will not let go. That's bad for the South Korean economy, since (again, others have mentioned this... I'm just bringing it all together in one place) South Korea needs a slow, controlled reintegration with the North to fuel its own economic expansion in order to compete with China. Again, our primary strategic interest in the area is to protect trade with South Korea and Japan. We need to be able to play both of them economically off of China, to keep China in check. Again, we lose in this scenario.
When it comes right down to it, the only way for us to win a war in North Korea is not to fight it, and to prevent (through diplomacy) China from fighting it for us.
Apparently, none of these students have read the IP policy at their school. At least at my University, anything you turn in for a grade becomes the property of the University. By turning it in, you have implicitly waived your intellectual property rights over it anyway. Granted, I don't think that's fair in the first place, but the simple fact is that many of the students don't have any rights to the papers to begin with.
Wow. At first glance I thought that was German.
They'd also be useful for process improvement. One method of measuring the quality of of your QA process that we (briefly) studied in one of my software engineering classes is a technique called defect seeding. Basically, before sending a unit to QA, you inject known defects. By measuring how many of the known defects were caught by QA, you can get an estimate on the effectiveness of your QA process. The problem is injecting realistic defects. You could use this tool before sending the unit to QA to find a set of known defects, that most certainly are realistic, because they're real defects. Of course, if your QA organization uses this tool as well, then your defect detection metric is boned... but QA shouldn't be looking at the source, anyway.