Step 2: Put the following in the config file:

[Media Players]
; Previous
^~Z=Msg|iTunes|793|0|786432
=Msg|WMPlayerApp|793|0|786432
=Msg|WMP Skin Host|793|0|786432
=Msg|Winamp v1.x|273|40044
=Msg|ApolloRuntimeContentWindow|256|37|917504
=Msg|ApolloRuntimeContentWindow|257|37|917504

; Pandora - Thumb Down
~34=Msg|ApolloRuntimeContentWindow|256|109|917504
=Msg|ApolloRuntimeContentWindow|257|109|917504


Step 3: There is no step three

Further harming the issue is so-called “learning” sites like Purplemath which have incorrect information on them, and refuse to change in spite of the mistake being contrary to all basic rules of math, and not agreeing with the answers that Google and Wolfram Alpha generate.

Even more, some older graphing calculators are incorrectly programmed, and generate an answer of 1, which many proponents of the 1 answer take as proof that they’re right, even though far more advanced tools as linked above say otherwise. (Not to mention, yet again, the basic rules of mathematics)

The recent problem in question is the following: 6/2(1+2), or 6÷2(1+2), depending on your symbol choice.

The correct answer is 9. Not 1, not 7, not anything else anyone comes up with when they make mistakes.

There are several sources of confusion with this problem – some teachers taught the order of operations incorrectly, while some students simply remember it wrong. Others try to distribute the 2 inside the parentheses, thinking back to algebra, while others assume that implied multiplication is somehow stronger than regular multiplication¹.

I was taught PEMDAS, which stands for Parentheses, Exponents, Multiplication & Division, Addition & Subtraction. However, some have taught or remember it as Multiplication and THEN Division, and Addition THEN Subtraction, which is wrong. You do the M/D and A/S left to right, whichever comes first.

Wrong way:

6/2(1+2)
6/2*3
6/6
1

The distributing crowd is actually similar to the previous error as well. They try to distribute, but they take only the 2, instead of the entire 6/2, or resulting 3.

Wrong way:

6/2(1+2)
6/(2+4)
6/6
1

The final group start off fine, doing the parentheses first, but then leave it as 2(3), which is the same as 2*3, and assume that somehow makes it stronger, when in fact they are identical.

Wrong way:

6/2(1+2)
6/2(3)
6/6
1

If you fix all these issues, you get only one possible answer, 9.

Right way:

6/2(1+2)
6/2*(1+2) Remember, implied multiplication is still just multiplication!
6/2*3
3*3
9

If you distribute correctly, you can do this:

6/2(1+2)
3(1+2)
3*1 + 3*2
3 + 6
9

No matter how you do it, if you actually follow the rules correctly, you get 9.

Random related images that have come up during discussions of this:

http://i.imgur.com/qiK3V.jpg
http://i.imgur.com/STMJT.jpg
http://i.imgur.com/zrxGL.jpg
http://i.imgur.com/Xvf6s.jpg

Update the 2nd: now that they finally got to my ticket, they seem to have taken care of it very quickly; the issue has not happened since they tweaked something last night!

For the past few weeks I’ve been having constant disconnects between me and a server I’m often connected to. (Up to 20 disconnects a day, often grouped together, getting very annoying)

My debugging leads me to believe it’s an issue with some of nLayer’s routers, but so far their support department has completely ignored my messages…

Here’s my tests:

Dead:

traceroute to [redacted] ([redacted]), 30 hops max, 40 byte packets
1 [redacted] ([redacted]) 1.449 ms 2.548 ms 3.519 ms
2 wsip-24-234-89-129.lv.lv.cox.net (24.234.89.129) 29.241 ms 32.358 ms 33.054 ms
3 24-234-8-141.ptp.lvcm.net (24.234.8.141) 31.627 ms 34.132 ms 34.787 ms
4 24-234-6-245.ptp.lvcm.net (24.234.6.245) 36.012 ms 37.387 ms 38.146 ms
5 langbprj01-ae3.0.rd.la.cox.net (68.1.0.94) 39.451 ms 46.503 ms 45.684 ms
6 ae0-60g.cr1.lax1.us.nlayer.net (69.31.127.137) 47.103 ms
ae0-60g.cr1.lax1.us.nlayer.net (69.31.127.141) 49.818 ms 50.397 ms
7 * * *

traceroute to [redacted] ([redacted]), 30 hops max, 60 byte packets
1 router (192.168.1.1) 0.653 ms 1.602 ms 1.889 ms
2 ip70-173-25-1.lv.lv.cox.net (70.173.25.1) 25.800 ms 25.999 ms 25.965 ms
3 24-234-8-189.ptp.lvcm.net (24.234.8.189) 30.181 ms 30.387 ms 30.464 ms
4 24-234-6-57.ptp.lvcm.net (24.234.6.57) 32.115 ms
24-234-6-49.ptp.lvcm.net (24.234.6.49) 30.804 ms
24-234-6-57.ptp.lvcm.net (24.234.6.57) 32.139 ms
5 langbprj01-ae3.0.rd.la.cox.net (68.1.0.94) 36.867 ms 37.032 ms 37.786 ms
6 ae0-60g.cr1.lax1.us.nlayer.net (69.31.127.141) 37.284 ms 37.163ms
ae0-60g.cr1.lax1.us.nlayer.net (69.31.127.137) 36.291 ms
7 * * *

Working:

traceroute to [redacted] ([redacted]), 30 hops max, 60 byte packets
1 router (192.168.1.1) 0.638 ms 1.553 ms 1.854 ms
2 ip70-173-25-1.lv.lv.cox.net (70.173.25.1) 9.765 ms 9.964 ms 9.956 ms
3 24-234-8-189.ptp.lvcm.net (24.234.8.189) 63.833 ms 64.043 ms 64.132 ms
4 24-234-6-49.ptp.lvcm.net (24.234.6.49) 13.944 ms
24-234-6-57.ptp.lvcm.net (24.234.6.57) 14.713 ms
24-234-6-49.ptp.lvcm.net (24.234.6.49) 14.126 ms
5 langbprj01-ae3.0.rd.la.cox.net (68.1.0.94) 21.099 ms 21.265 ms 20.757 ms
6 ae0-60g.cr1.lax1.us.nlayer.net (69.31.127.137) 21.014 ms 20.608ms 20.562 ms
7 xe-0-2-0.cr1.dfw1.us.nlayer.net (69.22.142.22) 47.992 ms 42.931ms 43.098 ms
8 xe-2-2-0.cr2.ord1.us.nlayer.net (69.22.142.2) 63.567 ms 62.564ms 62.664 ms
9 po6.ar2.ord1.us.scnet.net (69.31.111.6) 63.004 ms 63.956 ms 62.470 ms
10 * * *

Tracepath:

Dead:

$ tracepath [redacted]
1: [redacted] ([redacted]) 0.163ms pmtu 1500
1: [redacted] ([redacted]) 1.809ms
2: wsip-24-234-89-129.lv.lv.cox.net (24.234.89.129) 46.246ms
3: 24-234-8-141.ptp.lvcm.net (24.234.8.141) asymm 4 35.816ms
4: 24-234-6-245.ptp.lvcm.net (24.234.6.245) 14.302ms
5: langbprj01-ae3.0.rd.la.cox.net (68.1.0.94) asymm 6 20.633ms
6: ae0-60g.cr1.lax1.us.nlayer.net (69.31.127.141) asymm 7 19.775ms
7: no reply

Working:

$ tracepath [redacted]
1: [redacted] ([redacted]01) 0.204ms pmtu 1500
1: [redacted] ([redacted]) 1.792ms
2: wsip-24-234-89-129.lv.lv.cox.net (24.234.89.129) 59.494ms
3: 24-234-8-141.ptp.lvcm.net (24.234.8.141) asymm 4 14.367ms
4: 24-234-6-241.ptp.lvcm.net (24.234.6.241) 16.196ms
5: langbprj01-ae3.0.rd.la.cox.net (68.1.0.94) asymm 6 24.259ms
6: ae0-60g.cr1.lax1.us.nlayer.net (69.31.127.137) 18.718ms
7: no reply
8: no reply
9: po6.ar2.ord1.us.scnet.net (69.31.111.6) asymm 8 65.385ms
10: no reply

As you can see, the connection always breaks off at xe-0-2-0.cr1.dfw1.us.nlayer.net (69.22.142.22) and xe-2-2-0.cr2.ord1.us.nlayer.net (69.22.142.2)

Why they can’t fix/replace it is beyond me, or at the very least respond to even say it’s been passed on to the actual network guys – its been weeks since the issue started, and almost a week since I opened the support ticket…

Bleh, just wanted to rant a little – if anyone knows more than I do about networking, am I wrong about what the info indicates? Could an issue outside of nLayer’s network trigger such a consistent disconnect in traceroute/tracepath?

As someone who has been digging through a lot of job listings, I have a suggestion for those writing them:

Please, stop posting what you don’t want, and limit it to what you do.

I’ve been looking mostly for telecommute jobs, but when I search for telecommute along with other keywords, I find posting after posting saying “NO TELECOMMUTE” or similar – you’re only going to attract people looking for that keyword by posting it

If they just left it at “ON-SITE ONLY” it would not show up in a search for telecommute positions

Well, it’s only been a day so far, but the results have been very promising. Our memory usage was cut in half, and load bottomed out.

Edit: this is daemon mode with threads=1

Initial testing showed more drastic improvements, so for anyone else testing, take initial results with a grain of salt

With that said, here are the actual results:

Just after switching:

A day after switching:

Too early to be absolutely sure that everything is working well, but it’s all looking good so far