Winamp was the first player that could handle massive playlists. I could drag a network folder with over 80 GB of music and it would populate the playlist in seconds. I could then randomize and walk through that list without repeats for days. It also played skipless so that live albums didn't have annoying breaks. New players today still can't do that. Sigh. Their android app is pretty good too. I guess I will jump to amazon now. Their cloud playing is great.
We use openwrt as a base OS. It works pretty well. It has a lot of packages and many single board computer vendors support it. It is pretty hackable and has lots of embedded patches that would never make it into mainline linux but you really need on embedded platforms.
Graphing calculators are an amazingly powerful way to understand functions visually. The ability to instantly draw functions at various scales and trace along them can really help visual learners understand the math.
I wish there was more discussion on the interconnect and routing challenge of these systems. I used to work on an InfiniBand SubnetManager. Exascale will require more complex topologies and more complex routing. Does anyone think today's systems are up to the task?
VBA within excel does not consider 1900 a leap year...getting the two to work together is fun.
You can have excel load dll functions. I wrote financial add-ins using this technique with all the real code in c++ with c wrapper exports. The vba was just a bit of glue code.
My thought is what if a LAN client, C, is sending UDP traffic through the AP to A. As long it blasts, B can barely speak. It would be interesting if they were dynamically altering the multi-rate retry algorithm to decrease retries as the queue filled and to even turn on ack requests when the queue was all the way filled. That can help at the cost of reliability. Send it and forget it.
I wonder if they experimented with traditional router methods of dealing with queuing issues. Things like Random early drop may help as well.
While the AP is sending faster and more often, clients will suffer. If the AP is blasting to client A, client B will struggle to upload. This may cause client B to disconnect or reassociate. It isn't clear how they prevent starvation at the client transmit side.
As their txqueue fills up they are just shifting packets from the best effort queue to the video queue and then to the voice queue (highest priority). These queues use more air time and have less space between packets. I am curious how it performs under a variety of traffic conditions (upload vs. download vs. mix). It would seem that if uploads and downloads are done at the same time, the downloads will block the uploads. What if the clients do the same thing?
I think enjoying programming is some kind of genetic mutation. No matter who good the software jobs market is, few people get CS degrees or otherwise want to be software engineers or programmers. It isn't quite a mono-culture but programmers and software engineers have so much in common that one can almost forget about how the rest of the world thinks. As you move out to other engineering disciplines, there are still an amazing number of personality traits and interests in common.
This is all good for those of us who enjoy programming and would like to be paid well to do it but it is strange to me. I often see IEEE and ACM articles about how to "fix" this issue but I don't think it can be fixed. Most folks would not like what we do even if they were totally capable of doing it.
It sounds like advice to other folks to hire people without a degree in the field so that they will be more loyal to you and less expensive. Without a lot of experience this is true. Folks with a year or two of experience with a degree will earn more than folks with a year or two of experience without a degree. That said, after a few more years it events out.
In the end, you have to judge the individual, what they learned, and how they learned it. I have met idiots who had a degree (even multiple degrees!) and idiots who had no formal education. They come in all shapes and sizes. Anyone who thinks in blanket statements like, "All college graduates in CS are worse than self taught" is proving my point.
I found my programs at West Chester (CS undergrad) and Villanova (master computer engineering) to be very useful and improved my abilities at work. I learned a lot in both and I had been programming since I was 7 or so on my TRS-80 Model III. They also made me more marketable. I feel it was totally worth it.
The military is using meshing products from the company I work at, Rajant, http://www.rajant.com/. They are secure enough for their use. As for reliable, we are used in open pit mining operations with 100s of mobile nodes in vehicles that are like multistory buildings on wheels. These folks loose tons of money if they are down for just the smallest amount of time and they rely on our meshing networks for their fleet control.
I work at http://www.rajant.com/ so I may be a bit biased but our BreadCrumb line will work great for rugged meshing. We support 4.9 GHz radios that are reserved for emergency responders. We are in use by the military and large mining operations that require 24/7/365 networks with 100s of nodes and lives on the line.
They used 10 GigE with a very advanced set of switches that support OpenFlow so that they could get the full bisectional bandwidth. They could have use InfiniBand and probably done much better with FDR adapters capable of 56 gigabit per second. Even "old" IB adapters were faster. Most of the IB switches supported full bisectional bandwidth right out of the box. MS should look at the High Performance Computing world. They need to do handle large amounts of data with low latency.