With this weapon system, we take away cover from [enemy targets] forever," Lehner told FoxNews.com on Wednesday. "Tactics are going to have to be rewritten. The only thing we can see [enemies] being able to do is run away.
This advertisement could stand a bit of healthy skepticism. Right now, I can think of an easy way to defeat this weapon: use some kind of overhead cover. That's right, a simple roof covered with sand bags, or a bunker, would be enough.
The spokesperson for this company seems to lack a crucial sense of imagination.
I'm all for frustrating TSA agents. Those people are traitors to the cause of liberty. 200 years ago, they would have all been hanged. I think frustrating them is a little less extreme, don't you?
Yes, and subscribing to the wisdom of 200 years ago sets an excellent standard. Slavery, no rights for women, lethal working conditions. I'm glad we're moving back to these core values.
Re:It's easy to overthink even in the simplest cas
on
Taco Bell Programming
·
· Score: 2, Informative
Psst,
" | sort | uniq -c "
Will sort and then count repetitive lines and output count, line. You can pipe the result back through sort -n if you want a frequency sort or sort -k 2 for item sorting.
The problem was not figuring out how to count the unique items. It's the part before the pipe that was difficult. The poster needed to combine the results of two different commands and then compute the unique items. The solution would have to be, logically, "command1 + command2 | sort | uniq -c".
Unless you can find a way to pass the output from command1 through command2, you will lose command1's data. The solution he/she found was elegant: (command1):(command2) | someKindOfSort. My syntax is probably wrong. If you were simply pointing out a better way to sort, then please disregard.
You're still working up to 40 hours per week extra with the commute and getting paid less for it.
No, I said it was comp time, I get paid the same year round, excepting quarterly bonuses, and I drive only 2-3 days a week during the slow times.
I guess we account for time in different ways. I consider commute time as being work time. If I'm commuting I'm not doing something I would choose to do in my free time. Though being salaried does not technically affect how you are paid for the number of hours you put in, the net result is that you're working extra time for no extra money.
During the busy time of year, it is only 10 hours per week or less, during the slow, only 4 or 5. The time I quoted included both to and from.
That is fine, but if you could do the same comp schedule if you lived in the city then you have still lost time (and essentially money) through the hours you've burned commuting.
Biking/walking to work becomes out of the question
99% of people would never consider those two options except at the point of a gun, or out of poverty.
That's their loss, but at least you have the option should you decide to use it to better your health. I've lived in Dallas, the Piedmont Triad, and now I live out west in a bike friendly town. I've biked in all these places. Dallas was the worst, but it was doable. Many others I know have regularly biked more hostile routes.
You're still working up to 40 hours per week extra with the commute and getting paid less for it. The weekend is 48 hours long for those of us who live in the city too (don't tell anyone).
There are health drawbacks associated with extra driving. Biking/walking to work becomes out of the question, and you're sitting on a couch for 2 hours extra per day. Don't forget about the increased risk to your health from MVA's.
If you can handle the 12 hour days for 1/3 of the year and this lifestyle suits you, great. I think it would really stress things if you had a family. Would your employer forbid your working 20 hours per week if you lived closer to town?
I'm not knocking the exurb thing -- to each his/her own. Just pointing out it that it has some unique drawbacks that aren't immediately apparent.
Having worked on a project from conception through production, written in JRules, I'd have to agree that the marketing examples for rules engines are way oversimplified.
You're right, they present simple if/then logic as being applicable to every problem. As you demonstrate with the "compute average age" example, this can quickly break down. The problem is that it's hard or impossible to maintain context on an object from rule to rule. BREs expect each rule to be independently applicable to an object. This works in some domains, but many business rule flows require that context be maintained throughout the flow.
Another problem is database access. BREs expect that the object will be pulled completely from the database at the start of execution, and no further database interaction is required until the object is finalized and persisted. Again, this is way too simple for many business requirements.
To extend your insurance example, ask how you would calculate a driver's premium based on a code associated with the object. There can be millions of codes for which the premiums may change at any time, so they must be pulled from a database at execution time.
Extend this to similar db transactions on nearly every decision in the tree, and execution quickly bogs down. Yes, you can cache a certain amount of this data, but with a large enough set, the model breaks. Multithreading and parallel processing will buy some speed, but only so much. If database transactions are dependent on path of execution in the tree, the BRE model will have problems.
Perhaps the reason rules authors are so well paid (if this is true) is perhaps because they're often required to use the wrong tool for the job. If I were required to use a sledgehammer to chop down trees I would expect better pay.
SUVs were a fad, started by marketing departments. In fact it was 100% marketing that led to the suburban drivers buying them....Clearly you don't know anyone that lives down a gravel road, or someplace that regularly gets feet of snow, or where roads wash out. Or anyone who actually does use the payload and passenger space at the same time...
Unless your gravel road is full of boulders and mud pits, you don't need a truck. A front wheel drive car can handle any city snow and any reasonably maintained dirt road. Few city SUV drivers exceed these demands
Cargo capacity is another thing, if you regularly need it. Most people don't
Anyone with knowledge of how hardware sales works knows that's not the fault of the sales reps. Management sets sales quotas and promotions, as well as the sales goals for each item.
If you expect sales reps to give you an unbiased recommendation, then you are an ideal customer. Sales reps will pursue the strategy that retires the most quota
Any laser that can melt mirrors very quickly would self-destruct even faster unless its own mirrors were constantly changed. Well, I s'pose you'd only have to change the surface rather than the entire mirror. Either operation would be tricky to do precisely in field conditions. Also remember, the atmosphere itself is gonna tend to scatter that beam, so if you want to melt mirrors from a distance, your own are gonna have to get considerably hotter.
Why not use a spinning mirror disc instead of many small disposable mirrors? The laser would burn a spiral groove in the targeting mirror as it fired, sort of like a reverse compact disc.
To continue the party theme, just make it a mirror sphere. Then you have a free mirror ball to use at the Number 6 dance later that evening.
Say you are in New Orleans, and a big storm knocks out your power. You want to get a message to your mom in Chicago that you are OK (so she doesn't worry and have a stroke or something). So your friendly neighborhood Ham will fire up his rig on battery or generator, relay a message to another Ham in Huntsville, who picks up a phone and calls your mom in Chicago. Only problem is if BPL is deployed in Huntsville, that message ain't getting through to the Ham operator there. Or to any other Ham who's area has deployed spectrum polluting technologies.
The way to work around this is to relay using VHF and UHF. A 50 watt VHF signal with a good antenna can easily radiate 50 miles in one direction. Couple that with other operators on the same band in different locations spaced apart, and you can relay out of a dead zone without needing HF. VHF and UHF are much less affected by BPL interference, and are way more reliable and available in general.
I've never seen any real cost savings by setting it up to run less often during the day when nobody's home. (Once the walls and floors and ceilings warm up (or cool down in the winter) to a certain point, then the A/C or furnace has to work a lot harder to move the temperature back to the comfort zone for your return home.
Your AC uses more energy when you leave it on during the day vs. letting the house heat up. There are 3 reasons:
When you run it all day, it cycles on and off multiple times. An air conditioner reaches peak efficiency after about 30 minutes of operation Running during the day causes you to pull hot air from your attic ducts into your house. This increases the heating load. Running in the evening when the ducts are cooler will be more efficient. Finally, whether you leave it on all day or turn it on in the evening, it doesn't change the net amount of heat entering your home
I have collected about two years of temperature data on my AC and these are the results I've found. This graph shows that the longer the AC continuously runs, the colder the air output is:
Also, the AC output temperature is warmer during the hottest part of the day (when you are probably at work) because it must pull the return air through hot duct work. The most efficient way to run an air conditioner is to leave it off during the day and then turn it on in the evening and have it run for a long time (at peak efficiency) to cool your house.
If you need guaranteed, fault tolerant, one-time message delivery you could use IBM's Websphere MQ. It is expensive bloaty, but it gets the job done and will tolerate intermittent connectivity problems. It runs on every platform and there are client API's for many languages.
Place an MQ server at each end, then have the client enqueue the message at one end and a listener dequeue at the other end. If the link or other host is down, the clients can still send messages which are stored and delivered when the comm. link comes back up. Transactions and rollback are supported, and large files are automatically segmented and reconstructed by the system.
You can configure it to send message receipts, prioritize messages, and report any failures to a dead letter queue.
There may be other brands of middleware that do this just as well for free. WMQ is just the one I'm most familiar with (I don't work for IBM).
I don't really see the revolution here - it's a small headless server. A bit like an NSLU2 only a lot faster. They're pretty cool.
They also seem to suffer from dodgy NAND memory, which is a shame, and booting from SDHC is not yet very well supported. That said, they come with Ubuntu server pre-installed and it was trivial to turn it into a media server.
I hope they don't have the NSLU2 disadvantage of not powering on automatically after a power failure.
This annoyance makes the NSLU2 unsuitable for remote monitoring where the electricity supply is unreliable.
The NSLU2 software distributions are also crippled (stripped down versions of utilities that break things like CPAN). Hopefully this one is more standardized and less unique.
UN doesn't enter into it. Japan is still essentially a protectorate of the United States of America -- nuking Japan would be legally equivalent to nuking Hawaii in international law, and the response would be just as swift.
The UN does play a role, historically. The US and other countries fought the war under UN Resolution 84. Among the often forgotten participants were UK, Canada, and Australia.
I don't care to take up for the iPhone, but they can do video. It requires jailbreaking (not the same as unlocking), which is fairly easy to do.
The fact that it is hardware capable of video but restricted by Apple will probably not win any fans, but just sayin', if you want to record video on the iPhone you can.
I use the free Violet UML editor to make decision tree drawings for support personnel. It runs without configuration on any platform and is simple.
I'm reminded of a coworker's story about documentation. He was asked for an SQL query by a QA engineer. Instead of sending the query in email (as usual), he IM'd it.
QA sent a reply stating that the query failed. They had pasted the entire IM entry as the query like so: "foo@bar says: select from..."
Not to nitpick (actually, yes - this is complete nitpicking), but Jailbreaking relates to running unsigned code on the phone (and giving full access to the filesystem). Unlocking is what allows people to use other carriers and SIMs.
Jailbreak apps are indeed signed, they are just not signed by Apple. A jailbroken phone does not eliminate the need to sign applications entirely.
Slashdot Mirror
From TFA:
With this weapon system, we take away cover from [enemy targets] forever," Lehner told FoxNews.com on Wednesday. "Tactics are going to have to be rewritten. The only thing we can see [enemies] being able to do is run away.
This advertisement could stand a bit of healthy skepticism. Right now, I can think of an easy way to defeat this weapon: use some kind of overhead cover. That's right, a simple roof covered with sand bags, or a bunker, would be enough.
The spokesperson for this company seems to lack a crucial sense of imagination.
I'm all for frustrating TSA agents. Those people are traitors to the cause of liberty. 200 years ago, they would have all been hanged. I think frustrating them is a little less extreme, don't you?
Yes, and subscribing to the wisdom of 200 years ago sets an excellent standard. Slavery, no rights for women, lethal working conditions. I'm glad we're moving back to these core values.
Psst,
" | sort | uniq -c "
Will sort and then count repetitive lines and output count, line. You can pipe the result back through sort -n if you want a frequency sort or sort -k 2 for item sorting.
The problem was not figuring out how to count the unique items. It's the part before the pipe that was difficult. The poster needed to combine the results of two different commands and then compute the unique items. The solution would have to be, logically, "command1 + command2 | sort | uniq -c".
Unless you can find a way to pass the output from command1 through command2, you will lose command1's data. The solution he/she found was elegant: (command1):(command2) | someKindOfSort. My syntax is probably wrong. If you were simply pointing out a better way to sort, then please disregard.
You're still working up to 40 hours per week extra with the commute and getting paid less for it.
No, I said it was comp time, I get paid the same year round, excepting quarterly bonuses, and I drive only 2-3 days a week during the slow times.
I guess we account for time in different ways. I consider commute time as being work time. If I'm commuting I'm not doing something I would choose to do in my free time. Though being salaried does not technically affect how you are paid for the number of hours you put in, the net result is that you're working extra time for no extra money.
During the busy time of year, it is only 10 hours per week or less, during the slow, only 4 or 5. The time I quoted included both to and from.
That is fine, but if you could do the same comp schedule if you lived in the city then you have still lost time (and essentially money) through the hours you've burned commuting.
Biking/walking to work becomes out of the question
99% of people would never consider those two options except at the point of a gun, or out of poverty.
That's their loss, but at least you have the option should you decide to use it to better your health. I've lived in Dallas, the Piedmont Triad, and now I live out west in a bike friendly town. I've biked in all these places. Dallas was the worst, but it was doable. Many others I know have regularly biked more hostile routes.
You're still working up to 40 hours per week extra with the commute and getting paid less for it. The weekend is 48 hours long for those of us who live in the city too (don't tell anyone).
There are health drawbacks associated with extra driving. Biking/walking to work becomes out of the question, and you're sitting on a couch for 2 hours extra per day. Don't forget about the increased risk to your health from MVA's.
If you can handle the 12 hour days for 1/3 of the year and this lifestyle suits you, great. I think it would really stress things if you had a family. Would your employer forbid your working 20 hours per week if you lived closer to town?
I'm not knocking the exurb thing -- to each his/her own. Just pointing out it that it has some unique drawbacks that aren't immediately apparent.
Having worked on a project from conception through production, written in JRules, I'd have to agree that the marketing examples for rules engines are way oversimplified.
You're right, they present simple if/then logic as being applicable to every problem. As you demonstrate with the "compute average age" example, this can quickly break down. The problem is that it's hard or impossible to maintain context on an object from rule to rule. BREs expect each rule to be independently applicable to an object. This works in some domains, but many business rule flows require that context be maintained throughout the flow.
Another problem is database access. BREs expect that the object will be pulled completely from the database at the start of execution, and no further database interaction is required until the object is finalized and persisted. Again, this is way too simple for many business requirements.
To extend your insurance example, ask how you would calculate a driver's premium based on a code associated with the object. There can be millions of codes for which the premiums may change at any time, so they must be pulled from a database at execution time.
Extend this to similar db transactions on nearly every decision in the tree, and execution quickly bogs down. Yes, you can cache a certain amount of this data, but with a large enough set, the model breaks. Multithreading and parallel processing will buy some speed, but only so much. If database transactions are dependent on path of execution in the tree, the BRE model will have problems.
Perhaps the reason rules authors are so well paid (if this is true) is perhaps because they're often required to use the wrong tool for the job. If I were required to use a sledgehammer to chop down trees I would expect better pay.
Don't they know they can just download it for free?
SUVs were a fad, started by marketing departments. In fact it was 100% marketing that led to the suburban drivers buying them. ...Clearly you don't know anyone that lives down a gravel road, or someplace that regularly gets feet of snow, or where roads wash out. Or anyone who actually does use the payload and passenger space at the same time...
Unless your gravel road is full of boulders and mud pits, you don't need a truck. A front wheel drive car can handle any city snow and any reasonably maintained dirt road. Few city SUV drivers exceed these demands
Cargo capacity is another thing, if you regularly need it. Most people don't
Whatever the substantive motives for the delay in publication are - that's probably also a nice publicity stunt; viral marketing is...old again?
This isn't viral marketing any more than selling 30 year old Scotch whiskey is. Not everything is an internet meme
Anyone with knowledge of how hardware sales works knows that's not the fault of the sales reps. Management sets sales quotas and promotions, as well as the sales goals for each item.
If you expect sales reps to give you an unbiased recommendation, then you are an ideal customer. Sales reps will pursue the strategy that retires the most quota
I sold my Sun workstation on CraigsList before this news hit
"War is cruelty. There's no use trying to reform it. The crueler it is, the sooner it will be over."
~William Tecumseh Sherman
More quotes...
Thank you. This explains the conspicuous lack of long, resource-draining wars throughout the past 100% of history
Any laser that can melt mirrors very quickly would self-destruct even faster unless its own mirrors were constantly changed. Well, I s'pose you'd only have to change the surface rather than the entire mirror. Either operation would be tricky to do precisely in field conditions. Also remember, the atmosphere itself is gonna tend to scatter that beam, so if you want to melt mirrors from a distance, your own are gonna have to get considerably hotter.
Why not use a spinning mirror disc instead of many small disposable mirrors? The laser would burn a spiral groove in the targeting mirror as it fired, sort of like a reverse compact disc.
To continue the party theme, just make it a mirror sphere. Then you have a free mirror ball to use at the Number 6 dance later that evening.
Say you are in New Orleans, and a big storm knocks out your power. You want to get a message to your mom in Chicago that you are OK (so she doesn't worry and have a stroke or something). So your friendly neighborhood Ham will fire up his rig on battery or generator, relay a message to another Ham in Huntsville, who picks up a phone and calls your mom in Chicago. Only problem is if BPL is deployed in Huntsville, that message ain't getting through to the Ham operator there. Or to any other Ham who's area has deployed spectrum polluting technologies.
The way to work around this is to relay using VHF and UHF. A 50 watt VHF signal with a good antenna can easily radiate 50 miles in one direction. Couple that with other operators on the same band in different locations spaced apart, and you can relay out of a dead zone without needing HF. VHF and UHF are much less affected by BPL interference, and are way more reliable and available in general.
I've never seen any real cost savings by setting it up to run less often during the day when nobody's home. (Once the walls and floors and ceilings warm up (or cool down in the winter) to a certain point, then the A/C or furnace has to work a lot harder to move the temperature back to the comfort zone for your return home.
Your AC uses more energy when you leave it on during the day vs. letting the house heat up. There are 3 reasons:
When you run it all day, it cycles on and off multiple times. An air conditioner reaches peak efficiency after about 30 minutes of operation
Running during the day causes you to pull hot air from your attic ducts into your house. This increases the heating load. Running in the evening when the ducts are cooler will be more efficient.
Finally, whether you leave it on all day or turn it on in the evening, it doesn't change the net amount of heat entering your home
I have collected about two years of temperature data on my AC and these are the results I've found. This graph shows that the longer the AC continuously runs, the colder the air output is:
http://www.flickr.com/photos/schramroyal/3735622175/
Also, the AC output temperature is warmer during the hottest part of the day (when you are probably at work) because it must pull the return air through hot duct work. The most efficient way to run an air conditioner is to leave it off during the day and then turn it on in the evening and have it run for a long time (at peak efficiency) to cool your house.
I think you missed the part about the government being involved
If you need guaranteed, fault tolerant, one-time message delivery you could use IBM's Websphere MQ. It is expensive bloaty, but it gets the job done and will tolerate intermittent connectivity problems. It runs on every platform and there are client API's for many languages.
Place an MQ server at each end, then have the client enqueue the message at one end and a listener dequeue at the other end. If the link or other host is down, the clients can still send messages which are stored and delivered when the comm. link comes back up. Transactions and rollback are supported, and large files are automatically segmented and reconstructed by the system.
You can configure it to send message receipts, prioritize messages, and report any failures to a dead letter queue.
There may be other brands of middleware that do this just as well for free. WMQ is just the one I'm most familiar with (I don't work for IBM).
Yep, real men use ADA.
I'd drink a lot less using Ada than C++. Ada has nice features aimed at keeping dumb asses from shooting themselves in the foot
C++ is a set of boots with land mines for soles
I don't really see the revolution here - it's a small headless server. A bit like an NSLU2 only a lot faster. They're pretty cool.
They also seem to suffer from dodgy NAND memory, which is a shame, and booting from SDHC is not yet very well supported. That said, they come with Ubuntu server pre-installed and it was trivial to turn it into a media server.
I hope they don't have the NSLU2 disadvantage of not powering on automatically after a power failure.
This annoyance makes the NSLU2 unsuitable for remote monitoring where the electricity supply is unreliable.
The NSLU2 software distributions are also crippled (stripped down versions of utilities that break things like CPAN). Hopefully this one is more standardized and less unique.
The next most obvious accessories include things like:
You could accomplish temperature monitoring using 1-wire temp/humidity sensors connected to the USB bus with this interface.
Thankfully, I have GNU macchanger installed
You can also use /etc/network/interfaces:
iface bond0 inet dhcp
hwaddress ether de:ca:fb:ad:d0:0d
For extra fun, send messages to Starbucks in your MAC.
You can do this at McD's too:
fe:ed:de:ad:be:ef
You have more faith in the UN than I do.
UN doesn't enter into it. Japan is still essentially a protectorate of the United States of America -- nuking Japan would be legally equivalent to nuking Hawaii in international law, and the response would be just as swift.
The UN does play a role, historically. The US and other countries fought the war under UN Resolution 84. Among the often forgotten participants were UK, Canada, and Australia.
...The summary alone says it all - no video?
I don't care to take up for the iPhone, but they can do video. It requires jailbreaking (not the same as unlocking), which is fairly easy to do.
The fact that it is hardware capable of video but restricted by Apple will probably not win any fans, but just sayin', if you want to record video on the iPhone you can.
I use the free Violet UML editor to make decision tree drawings for support personnel. It runs without configuration on any platform and is simple.
I'm reminded of a coworker's story about documentation. He was asked for an SQL query by a QA engineer. Instead of sending the query in email (as usual), he IM'd it.
QA sent a reply stating that the query failed. They had pasted the entire IM entry as the query like so: "foo@bar says: select from ..."
Not to nitpick (actually, yes - this is complete nitpicking), but Jailbreaking relates to running unsigned code on the phone (and giving full access to the filesystem). Unlocking is what allows people to use other carriers and SIMs.
Jailbreak apps are indeed signed, they are just not signed by Apple. A jailbroken phone does not eliminate the need to sign applications entirely.