Posted: September 16th, 2015 | Author: AnObfuscator | Filed under: Politics & Policy | Tags: Culture, Education, Society | No Comments »
The story of Ahmed Mohamed and his clock has exploded over the internet today. In case you’ve been hiding under a proverbial rock, here’s the short version: Ahmed built a clock. He brought the clock to school, to show one of his teachers. Panic ensues, through absolutely no fault of his own.
For the record, here is a picture of the clock:
To me, it looks like a circuit board in a protective case. But I’m a computer engineer with a minor in physics, so I’ve seen lots of circuit boards and protective cases.
The problem isn’t that ignorant people were confused at first glance. The problem is that, even after they were completely convinced that it was a clock, and even after they ascertained that there was no evidence of nefarious intent, they still punished the kid for doing absolutely nothing wrong.
Ken White performs an excellent evisceration of the absurd behavior by authority figures towards 14 year old Ahmed.
In his head, Ahmed lives in an idealized world he learned about in robotics club: a world where individuality and curiosity and initiative are appreciated. Or at least he did. But this week he found out that he actually lives in a different world, a grim real world controlled by school administrators and cops who are deeply suspicious of individuality, if not openly hostile.
Just read the statements by the police:
“We have no information that he claimed it was a bomb,” McLellan said. “He kept maintaining it was a clock, but there was no broader explanation. It could reasonably be mistaken as a device if left in a bathroom or under a car. The concern was, what was this thing built for? Do we take him into custody?”
To answer the rhetorical question “Do we take him into custody?”, simply follow this heuristic:
Did he break the law?
Yes –> Yes
No –> No
Yet building a clock requires “broader explanation”, because these school administrators, teachers, and police are simpletons. Their minds are uncomplicated with knowledge or creativity. The idea of challenging oneself intellectually for fun is simply beyond them. It reminds me of a quote from The Hacker’s Manifesto:
“My crime is that of outsmarting you, something that you will never forgive me for.”
However, it goes beyond that. Authorities are perpetually looking for a way to assert their control over us. The inconvenient truth is that we are not usually in any real, imminent danger. With the limited availability of actual threats, authorities look for more and more innocuous actions to punish, reminding us THEY ARE PROTECTING US FROM THREATS AND WE NEED THEM! The fact that he was Muslim (and looks Arab) was simply the excuse they needed — an easy way to prey on prejudice. LOOK! THEY ARE PROTECTING US FROM TERRORISTS!
If there was no prejudice against Muslims, they would suspend 7 year olds for chewing a pop tart into the vague outline of a gun. They would suspend 8 year olds for playing cops & robbers with finger guns. They would suspend 7th graders for twirling pencils. LOOK! THEY ARE PROTECTING US FROM VIOLENCE!
Or, perhaps, they would strip search a 13 year old girl for suspicion of possession of ibuprofen. Maybe they would suspend and prosecute an 11 year old for possessing a Japanese maple leaf. LOOK! THEY ARE PROTECTING US FROM DRUGS!
Of course, this extends to all levels of authority.
The NSA taps our communications. LOOK! THEY ARE PROTECTING US FROM TERRORISTS!
The FBI wants to back-door all our encryption. LOOK! THEY ARE PROTECTING US FROM CHILD MOLESTERS!
Local police wants to stop-and-frisk. LOOK! THEY ARE PROTECTING US FROM CRIMINALS!
The DEA bulk collects phone, license plate, and who knows what else data on American citizens, en masse. LOOK! THEY ARE PROTECTING US FROM DRUGS!
I hope Ahmed receives justice from this. I hope he launches a successful STEM career. I also hope he takes to heart the very important lesson, “Authority is not your friend.”
Posted: June 12th, 2015 | Author: AnObfuscator | Filed under: MultiLinks | No Comments »
What Is Code?
If you don’t understand computer programming or how computers work, this is absolutely the best explanation I have ever seen. It’s accurate, simple, and clear. If you’ve ever wanted to understand computers and computer programming, read this.
The Vagus Nerve: A Back Door for Brain Hacking
I am extremely skeptical of this. Lots of promises, but we’ll see. I’m suspicious that this is going to turn into the next pop-med cure.
High Frequency Trading Model
It’s rare to see an actual, functional algorithm for HFT methodologies. This is a simple example of statistical arbitrage. In the coming weeks, I’m hoping to port this to QuantConnect’s Lean Engine in a few weeks.
Is Russia’s space program in crisis?
So Russia’s program is corrupt and falling apart. Still better than the US, since the US program cannot currently put people into orbit.
Airbus unveils Adeline, its clever answer to SpaceX’s reusable rockets
Speaking of space: Airbus now has a plan to reuse lower stages, and reduce launch costs. Thanks, SpaceX. Unlike the UAL’s insane-sounding mid-air recovery plan, Airbus’ plan actually sounds like it might work.
Posted: June 12th, 2015 | Author: AnObfuscator | Filed under: Programming | Tags: Apple, Swift | No Comments »
As expected, Swift’s adoption is picking up quickly. It’s a nice language, with the modern look and feel that defines current languages:
- Simplified method declarations
- No semicolons on end of line
- Functions as first class citizens
- Some sort of memory management (ARC in Swift’s case)
- Implicit typing
It’s going through growing pains, as the language spec and tools are still immature. However, it’s a language with all the buzzwords and behaviors programmers currently want. Plus, if Apple follows through with it’s plan to open source Swift 2.0, a major hurdle to adapting Swift on other platforms will be removed.
As far as general non-Apple programming goes, Swift has some serious competition for mindshare in Google’s Go and Mozilla’s Rust. Go has a serious head start, and is solving real problems at Google and everywhere else these days; unfortunately, Google has a bad habit of abandoning projects. Rust looks like an absolutely amazing language, and I think it is the best-designed of the three (better type system than Go, better memory management than Swift). I’ll be curious to see if anyone actually uses it.
Swift, on the other hand, is Apple’s “language of the future.” Apple and Swift are in a similar position to Microsoft and C#. With a large development community eager to/forced to lap up whatever Apple brings down the pipe, I suspect Swift will continue to gain popularity.
Posted: June 5th, 2015 | Author: AnObfuscator | Filed under: MultiLinks | No Comments »
Intel will acquire FPGA maker Altera for $16.7 billion
Whoa. This is a huge deal. I’ll be very interested in seeing what Intel does with this.
Kubernetes – The Future of Deployment
This is an incredible technology. While Docker has slowly tried to add orchestration features like Machine, Swarm, and Compose, they are still somewhat immature and don’t fully work together well. You can read more about Kubernetes here and here. This is still immature and ambitious, but with Google’s experience behind it, I think it will develop quickly — assuming they don’t get bored. 😉
Majority of websites have serious, unfixed vulnerabilities
I’m shocked, shocked I tell you!
Play 2.4.0 “Damiya” released, adds new DI support and test APIs
Play 2.4 FINALLY adds built in DI — using Guice, my favorite Java DI container. They also look like they’ve added some useful methods for adding mock dependencies to FakeApplications when unit testing.
The U.S. Navy’s Big Mistake — Building Tons of Supercarriers
Super carriers are great for power projection — as long as you aren’t fighting a technologically even foe.
Posted: June 4th, 2015 | Author: AnObfuscator | Filed under: Science | Tags: Culture, Science | No Comments »
Going through some old links, I rediscovered this old testimony. This is the most beautiful defense of scientific research I have ever seen:
SENATOR PASTORE. Is there anything connected in the hopes of this accelerator that in any way involves the security of the country?
DR. WILSON. No, sir; I do not believe so.
SENATOR PASTORE. Nothing at all?
DR. WILSON. Nothing at all.
SENATOR PASTORE. It has no value in that respect?
DR. WILSON. It only has to do with the respect with which we regard one another, the dignity of men, our love of culture. It has to do with those things.
It has nothing to do with the military. I am sorry.
SENATOR PASTORE. Don’t be sorry for it.
DR. WILSON. I am not, but I cannot in honesty say it has any such application.
SENATOR PASTORE. Is there anything here that projects us in a position of being competitive with the Russians, with regard to this race?
DR. WILSON. Only from a long-range point of view, of a developing technology. Otherwise, it has to do with: Are we good painters, good sculptors, great poets? I mean all the things that we really venerate and honor in our country and are patriotic about.
In that sense, this new knowledge has all to do with honor and country but it has nothing to do directly with defending our country except to help make it worth defending.
Posted: May 29th, 2015 | Author: AnObfuscator | Filed under: MultiLinks | No Comments »
In College and Hiding From Scary Ideas
This is the best thing I’ve read this week, possibly the best thing I’ve read this year. I couldn’t find a single point of disagreement.
I Fooled Millions Into Thinking Chocolate Helps Weight Loss. Here’s How.
This is the 2nd best thing I’ve read this week. Journalists who don’t understand how science works mislead people who also don’t understand how science works, in pursuit of readership.
Arms control treaty could land security researchers like me in jail
Once again, software is being subjected to arms trade regulations. We did this in the 90’s, and it lead to SSL downgrade attacks like POODLE and FREAK, which hurt everyone — including the government responsible for forcing their adoption. This foolishness will bite us, hard.
Higgs Machine Learning Challenge
Crowdsourced data science and ML algorithms being used to solve problems in high energy physics? Oh be still, my beating heart!
10 Books Every Programmer Should Read
I really love everything Javin Paul writes about Java. I haven’t read all of these, but I can highly recomment GOF Design Patterns, The Mythical Man Month, Martin Fowler’s Refactoring, and Joshua Bloch’s Effective Java.
I really don’t think this would work well for production development. However, this could be an amazing system for training new developers in TDD.
How can we Build Better Complex Systems? Containers, Microservices, and Continuous Delivery.
Long title, and an extremely long article, summarizing a talk (which I didn’t watch). It has a great summary of principles for developing microservices. I strongly agree with this point:
While microservices certainly lower friction they also increase risk from wiring hell and bad partitioning.
I’ve experienced wiring hell and bad partitioning (particularly, wiring hell from bad partitioning). It’s a real problem, and a good example of why, as the article says:
Microservices usually grow successfully from monoliths. In creating a monolith developers learn how to properly partition a system.
I love microservice architectures, but they must be approached correctly.
8 Questions You Need to Ask About Microservices, Containers & Docker in 2015
I love Docker and containers. However, they raise some very salient issues. Points 2 and 3, in particular, have been challenging me lately. Point 6, however, is the elephant in the Docker room, and leads directly into the next link…
Over 30% of Official Images in Docker Hub Contain High Priority Security Vulnerabilities
… Yeah. We need to get on top of this. For deployment, —no–cache is your friend…
Harvard’s Asian-American Quota Turns Diversity on Its Head
Apparently, it’s ok to be racist against successful minorities.
Posted: May 26th, 2015 | Author: AnObfuscator | Filed under: Personal | No Comments »
Maybe I should write more here. I am paying for hosting, after all…
I’m going to try one lengthy post a month, and a weekly link roundup. We’ll see how this goes.
Posted: July 31st, 2014 | Author: AnObfuscator | Filed under: Programming | Tags: Multithreading | No Comments »
All through the 90’s, the performance of CPUs grew at a breakneck pace. Each generation added more and more hardware features to make code run faster and faster. As transistor technology continued to advance, CPU manufacturers pushed exotic and complex tricks and logic into their CPUs. They added advanced logic to predict the next instruction, to dynamically reordering code instructions, to merge and break apart groups of instructions. This is an attempt to cram yet more work into each fraction of a second. However, in recent years CPU makers have found it increasingly harder to make meaningful performance gains in simple execution speed.
To make use of the extra transistors, CPU makers have glued together many CPU backends into a single CPU unit. Instead of building a bigger, more powerful engine in a car, we cram several engines into the car, and make them work together.
We call each of these engines “cores”. This has given us in the software world a bonanza of resources to work with. Unfortunately, taking use of those resources is a significant challenge.
What is a thread?
To take advantage of CPUs and CPU cores, we have a software concept called a “thread”. On a simple level, a thread is a container for a sequence of instructions, that an operating system can put on one core. We can have many threads running on one core, or many cores, or have only one thread running on one core with the other cores idle.
This is a lot to digest, so let’s look at some examples, using some real world analogies.
Several threads, one core
Let’s imagine a TA is grading student assignments. In this analogy, the TA is a core, and he treats each paper as a single thread. So he starts grading paper one, works on it for a minute, then stops. He starts grading paper two for a minute, then stops, and so on. When he has worked on all the papers for one minute, he goes back to the first one.
Several threads, several cores
So, as you can imagine, this poor TA is taking a really long time to finish. So the professor decides to speed it up by adding a second core, another TA.
Now, TA1 takes a paper, starts working on it for one minute. TA2 takes another paper, and starts working on it for one minute. Each then does the same pattern as before, grabbing a paper from the top of the pile, working on it, and putting it on the bottom.
Now, as you have probably noticed, this is not very efficient. It would probably be faster for each TA to start a paper, grade it all the way through, then start the next paper. It takes time to put a paper back, pick up a new paper, read the paper, figure out how far along the paper has been graded, and start working on it again. This is, however, the way computers work; this is a very real performance cost, called “context switching”. So why do we do work like this on computers? Because usually, the tasks each thread needs to run don’t all take the same amount of time. Some tasks take a really long time to complete (such as burning to a CD). Some tasks are very fast, like scrolling down a document or webpage. Sure, if we didn’t switch threads, burning a CD might complete a few seconds sooner; but would you really want your entire computer to lock up for several minutes while that task completed?
As you can see, using multiple threads can speed up completing a task, but at a cost of context switching. There are many ways we can use threads to speed up tasks, but they come with many other pitfalls, as well. Let’s look at ways to use multiple threads to speed up tasks.
For this example, we will look at cashiers ringing up groceries at a store. Let’s ignore the problem of context switching; lets pretend we have infinite cores.
Let’s take a case of one cashier (thread). There is only one line. The one cashier rings up the groceries, bags them, and assists taking the groceries to the car. Obviously, this does not scale well, as the line gets longer. So how do we use two cashiers?
First, we can use them in parallel. Each cashier gets a line, and assist shoppers at the same time. Another way to use them is to create a pipeline. One cashier rings up shoppers, while the second bags the groceries and assists shoppers to the car.
Note that these can be done together. If we have four cashiers, we can create two pipelines, and assist two lines of shoppers at the same time. Also note that while this can improve throughput, it also increases cost. However, it doesn’t always increase throughput; if there aren’t enough shoppers, most of the cashier threads are going to be idle, waiting for a job to do. Another issue is that, when using a pipeline, the work can be stalled if one task, such as taking groceries to a car, takes much longer than other tasks, such as ringing up, or bagging groceries.
How can we use threads more efficiently? Instead of tying each person to a specific task, we let each of them take whatever task is available. We have three tasks (ringing up, bagging, assisting to car), and a group of three cashiers. This group of cashiers are called a thread pool.
Each cashier then takes whatever task is available. If the cashier who assists to the car is not back when the cashier finishes bagging, that cashier then assists to the car, and so on. Of course, this can lead to issues, as well. If assisting to the car takes a very long time, it’s possible that all three cashiers are busy assisting, and no one is ringing up customers. So we need to prioritize the tasks. We assign ringing up as a high priority, bagging as a medium priority, and assisting to the car as a low priority. Now, a cashier will only take the highest priority task that is available. The cashier bagging groceries will only assist someone to the car if there are no more groceries to bag. This is called priority scheduling.
So, how do we use two cashiers in parallel? Well, let’s try having them both check out people on the same register. That doesn’t work at all, because one person’s grocery bill is getting mixed in with another, and leaving the bill in an entirely incoherent state. So we need to manage access to the register. In programming terms, the first cashier will “lock” the thread while ringing up groceries, then “unlock” it when finished. Then the next cashier can take control and start ringing up the next customer. Now, we have fixed the data integrity issue, but introduced a very serious performance bottleneck. This is called resource contention.
There is also another potential issue this has introduced. Imagine the cashier who has locked the register gets a call, to handle an emergency. The cashier then goes on break to handle the emergency, but forgets to unlock the register. Now the other cashier and all the customers have to wait. If the first cashier never comes back, the customers and other cashier will be waiting forever. This is called deadlocking.
Solving Resource Contention
The easiest way to solve this issue with resource contention is to not share resources. In our grocery store, we solve the issue by installing a 2nd cash register. Now, both clerks can process customers at the same time, without interfering with each other. But this came with some cost, the cost of buying a cash register; in computers this comes with cost too; more memory, and more time spent building the resources. Additionally, we now have two sets sales records that now have to be rectified.
Sometimes, we simply have to share resources. In this example, let’s add a manager. We want there to be only one manager, as only one person should have the accountability and responsibility for certain problems. Now, only one clerk can use the manager at a time. Imagine a clerk calls the manager over, and says, “hey, I might have a problem, so stay here just in case.” Now, that manager is “in use”, and any other clerk who needs manager assistance has to wait. This is another bottleneck. To alleviate this, we instruct our clerks to only call the manager when needed, and let the manager leave when the problem is resolved. Minimizing the time a shared resource is locked can significantly improve performance, and minimize the chance of deadlocking.
There are many more possible problems when dealing with multithreading: Live locking, false sharing, and race conditions to name a few. Even when we write correct multithreaded code, it can be hard to extract serious performance benefits. CPU makers continue to give us more and more raw power, but using that power to actually benefit the user is a significant challenge for programmers to overcome.
Posted: February 24th, 2014 | Author: AnObfuscator | Filed under: Personal | Tags: Toastmasters, Travels | No Comments »
There are places in the world so remote, so obscure, so isolated, that they were never graced with a name. No explorer or cartographer, no colonial leader or military governor deemed them worthy to claim. Yet these obscure regions often contain some of the most breathtaking settings on Earth.
The beauty of River No 2 is enhanced by its seclusion. It is only 15 miles south of Freetown, Sierra Leone, and only 6 miles south of the beautiful Lakka resort; yet even now the road conditions are so poor that it takes nearly a half hour to drive from Lakka.
The drive was its own adventure. In late 2001, the UN, supported by the UK, was still enforcing a cease-fire between the provisional government and the rebel factions. A decade of civil war left much of the infrastructure in ruins, and the economy in shambles. With per capita income measured in the hundreds of dollars a year, any vehicle is considered a luxury. When cars in the US and Europe are considered far too old and decrepit for our streets, we ship them en masse to the third world. There they are driven until they literally fall to pieces, then are repaired and driven some more.
We loaded luggage into a taxi, an ancient Mercedes (much prized for its durability) painted in a bemusing number of yellow shades. Eventually the engine started, and we made our way along the shell-shocked road. The fantasy of shock absorbers was swiftly dispelled by the remains of the asphalt. We snaked from one side of the road to the other, winding around shell craters as large as the car. Progress was slow. The African sun was unforgiving, and the dust smothering.
We were suddenly startled by a bang. What was that? What was that terrible roaring noise? The driver stood on his brake, a full panic stop — from maybe 15 miles an hour. We exited the car, and surveyed the damage. The entire exhaust system from the Y-pipe to the tail pipe, has simply fallen from the car.
The driver was horrified. He grasped his head with both hands, and surveyed the damage to his most prized possession and source of livelihood. Another passenger opened a pack of cigarettes, and offered one to the driver. “I don’t smoke”, he declared — then took one anyway. I took one as well, as I didn’t have any better ideas.
After a few minutes, the driver regained his composure. He smiled at us and exclaimed, “TIA (this is Africa)!”. He lifted the pipe and muffler, partially wedged it into the trunk, and on we went. TIA indeed.
The rest of the trip was comparatively uneventful, as we made our way down the coast of Sierra Leone’s Western Area. The road cut through dense jungles that ran from the tops of the mountains down to the coast. We arrived at the “parking lot” for the beach, nothing more than a large clearing. We exited the shadows of the short jungle trail, into the dazzling brightness.
The equitorial sun was reflected by the brilliant white sand, sand that crunched beneath our feet like snow. The river flowed through the mangroves into a small estuary, and had built a white sand delta.
The giant waves of the deep blue ocean crashed on the outer sand barrier, then rippled through a shallow turquoise lagoon and lapped onto the shore. The rush of the river mixed with the crash of the waves. A little further out, fishermen cast nets for fish sheltering outside of the barrier. We let the majesty of the scene sink in, then began to explore.
As we explored, local children would run up with fresh coconuts for sale. For only a few leone — fractions of a US penny — they would cut the tops, and let us drink the milk. They then took the husk, cut it open, and gouged out the meat for us.
After rehydrating, we rented canoes and paddled up the estuary. African guides lead us through the mangroves, showing us flights of birds and uncomfortably close crocodilians. The estuary transitioned to river, which lead us to the nearby waterfalls.
The falls were the gathering place for the small nearby village. Women washed clothes on the rocks while children played in the shallows. We pulled onto the shore to rest and eat, and began the short journey back.
Whump whump whump… the unmistakable sound of a helicopter. We rounded the bend of the river, and the main beach came back into view. The beach was now garnished with an ancient Russian helicopter disgorging Dutch tourists. The Russian (actually Ukrainian, but that’s another story) pilots headed for a nearby hut that served as the bar, and began drinking the lukewarm beers. Not the most comforting sight for a potential passenger.
The new flood of people, and the relative lateness of the day, prompted us to finally leave this shard of paradise. We returned to our taxis, and eventually to the din and bustle of Freetown.
I have seen many beautiful places, but I think none quite rivals this little known beach. While I have yet to return, I know in my heart I will see it again someday.
Posted: May 20th, 2013 | Author: AnObfuscator | Filed under: Personal | Tags: Adventure, Toastmasters | No Comments »
Sweltering under Florida’s summer sun, wearing wetsuits necessary for a prolonged dive in the 72 degree water, we assemble and test our diving gear and review our dive plan. 100 feet below us is one of the spring-fed caverns that has made northern Florida a diving mecca for cave divers all over the world.
Though excited, we buddy check each other’s gear with the utmost care; a rapid surface ascent would be far too dangerous from such depths. First, the air pressure gauge; 3000 psi, a full tank. Next the primary and backup regulators; both flow easily. Next tested is the inflatable vest known as a buoyancy compensator, or “BC”. All is secure and functional. The diver’s weight belt is verified, and the dive computers have fresh batteries. We are ready to dive.
As we slip below the waves, the senses change. The sounds of the surface world are immediately muted; the rustle of the breeze, the chirping of birds and clucking of squirrels, the everyday sounds to which we are accustomed are immediately quenched and replaced with the sound and sensation of one’s own breath. First the sharp hiss of the intake, followed by the exhale, a slow gurgling rumble. Each breath is intensely cold and dry, yet soothing as it fills the lungs. Thus encased in a sensory cocoon surrounding us with self awareness, we sink further below the still surface.
The waters are clear as glass, but the sun’s light becomes ever more attenuated. In our monochrome world, the soft turquoise of the shallows has given way to a dark navy blue at the opening of the cave. We activate our waterproofed torches and continue into a different world.
The floor of the cave is soft silt sand, but the walls and roof are limestone pockmarked from years of erosion. The ceiling shimmers with pockets of air, trapped and unable to flow back to the surface. We follow the lead of our guide; we remove our fins and rotate upside down. We inflate our BCs, and float until our feet touch the ceiling.
After a moment of vertigo, the world rotates; the change of perspective is a breathtaking transformation. The ceiling is our floor, cratered like the surface of the moon. The air pockets are a silver liquid that pools at our feet. We cup it in our hands; it flows through our fingertips and falls back to the ground. With buoyancy as our gravity, we bounce with each step, slowly returning to the surface like an Apollo astronaut. Some distance away, the circular opening of the cave hangs in our sky like a blue marble. We are no longer on anything recognizable as Earth.
We explore for a minute or a day; time no longer passes in a comprehensible way. The sound of breathing is finally punctuated by high pitched beeps; our dive computers are signaling it is time to leave. The chill of the water is taking its toll, but we moderate our ascent. Rising too quickly risks the bends, or a pulmonary embolism.
Our alien landscape sinks away below us, and we return to the bright, clear waters just below the surface. 15 feet away, we stop; our computers don’t advise a decompression stop, but our tables do, and we are risk-averse divers. 5 minutes later we break surface, and the senses return: the sounds of nature, the warmth of the sun, the smell of the breeze and the plethora of colors. To an alien world and back again, in under a half hour.