From TFA:

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.

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.

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.

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.

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.

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?

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

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

Thank you. This explains the conspicuous lack of long, resource-draining wars throughout the past 100% of history

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.