Fork me on Github
Fork me on Github

Joe Dog Software

Proudly serving the Internets since 1999

Select and Timeouts and Poll, Oh My!

By jdfulmer | Published May 16, 2015 | Leave a comment

Hanging ChadsBack in 1999-ish, Your JoeDog made a decision! Once he makes a decision, he doesn’t look back. “That’s over, Doggers. It’s time to move on.” And move on we did. Since 1999 we’ve been using select to check if our socket descriptor is ready for input. This is an important test because siege pounds your web server until it calls him “Daddy.” If the socket doesn’t get ready, then the request must time out or siege will hang.

We don’t want more hanging chads!

There were two mechanisms we could have used to accomplish this: poll and select. We chose select because it was more flexible and more readily available. At the time, we supported a great many platforms: Solaris, HP-UX, AIX, SCO, BSD, Linux, etc. The downside to select was its capacity. The fd_set couldn’t handle numbers higher than 1024. Well back in 1999, Yahoo! might have been doing 1024 concurrent connections but mere mortals didn’t need that capacity.

Recently we told you that siege crashes when large pools of simultaneous users are created. We finally got to the bottom of that problem and it dates back to that 1999 decision. Siege aborts when socket descriptors larger than 1024 are passed to FD_SET. We will fix this problem but there’s currently no ETA. It will require extensive testing and more of those difficult 1999-ish decisions.

For example, should we just stone-cold switch to poll or should we support both mechanisms? The latter will create a macro soup; does anyone have a stomach for that? Another option is create an array of fd_sets and place them on each thread. That would allow us to continue using select. (Your JoeDog kinda likes this option). And finally we could just say “Fsck it.” If you really have that many users, then you can afford Load Runner.

NOTE: To give you some perspective on traffic, this site is ranked 155,295 in the US. We almost never exceed 50 hits a second. Your JoeDog professionally webmasters a site ranked under 8000 and it almost never exceeds 100 hits a second. You must have a really large audience to generate 1024 hits a second. The vast majority of you should be fine with 255 threads or less.



RTFM!!

By jdfulmer | Published May 15, 2015 | Leave a comment

Over at OpenSource.com, Rich Bowen has a fine article about software documentation.

Have you noticed that the more frequently a particular open source community tells you to RTFM, the worse the FM is likely to be? I’ve been contemplating this for years, and have concluded that this is because patience and empathy are the basis of good documentation, much as they are the basis for being a decent person.

Empathy is the ability to understand needs of others so it’s a particularly good trait for someone who’s writing software instructions. This week Your JoeDog was installing a vendor’s code and he ran into a snag with one of the modules. It couldn’t connect to the database and its port listeners were walking on those of another module.

Your JoeDog took the time to detail theses issues so the vendor would have an easy time with his diagnosis. If you construct your prose with the recipient in mind, then you can convey a more meaningful message. That thoughtfulness did make it easy for the vendor to diagnose the problem. Your JoeDog sent him over 1000 words and he replied with a single sentence. That sentence solved his problem while it boiled his blood. And what did the vendor say that caused such a reaction?

“You don’t need to install that.”

“WTMF?” Your JoeDog thought. He omitted MFs from his reply and simply asked the vendor this: “Then why does your documentation tell me to install that?”

“That’s just generic documentation we send to all customers,” he said.

A more empathetic man would have pruned and tailored his documentation to meet the needs of the target audience. Does Your JoeDog consider this man empathetic? No. He thinks he’s kind of a dick.



Siege 3.1.0 Release Candidate 1

By jdfulmer | Published May 14, 2015 | Leave a comment

We received messages about core dumps that occur when siege is run with more than 700 threads. That’s a lot of threads, you guys! First things first — and this can’t be stressed enough — if you run siege with -c700, make sure your web server is configured with a pool of 700 threads. If you hit a pool of 256 threads with 700 users, all you’re gonna do is make a mess, mmmkay?

Now back to those core dumps. Here’s the thing: we’ve been unable to reproduce the problem but some diligent siegers have worked with us to get stack traces. As a result, we’ve added improved error handling and integrity checks in the problematic region. Your JoeDog would greatly appreciate if you could test version 3.1.0 release candidate 1. You can provide feedback here or by email, whichever you prefer.

http://download.joedog.org/siege/beta/siege-3.1.0-rc1.tar.gz



Millions of Cookies, Cookies For Me

By jdfulmer | Published May 10, 2015 | Leave a comment

cookiemonsterA couple weeks ago, a reader notified Your JoeDog of a problem with siege’s cookie handling. When the server sets a cookie that’s already stored, siege won’t update its expiration time. A JoeDog Fellow told him, “That’s a paddlin’.” The last cookie in, is the next cookie out.

The investigation took Your JoeDog into cookie.c, a file he hasn’t touched in years. “This code is awful,” he said. “Who wrote this shit? … Hmm, some guy named Jeff Fulmer, et al. If I ever meet that guy, I’ll tell him a thing or two.”

As an ethnic German with a tendency to over engineer — well, um — everything,  Your JoeDog decided to completely overhaul cookie handling. Why change two lines when you can rewrite everything, amirite? The file cookie.c now contains a COOKIE object with getters and setters, cookies.c is a cookie list object which houses all cookies in memory. Cookies will persist in $HOME/.cookies but the details are still being considered.

Here’s the thing. Siege isn’t a browser, it’s many browsers. We store cookies at the thread level. Each thread gets its own list of cookies. To distinguish them, we used pthread_self(), which is a long long int like 140018384393984 or something. Technically it’s not a long long int, it’s a pthread_t, but you get the point. The next time you fire up siege, its threads will have different IDs so we need a convenient way to associate stored cookies with new thread IDs.

Furthermore, there’s no guarantee that your next run will have the same number of simulated users. We need to consider how to handle that situation. If you have 50 stored cookies and you run 60 new users, should we stop assigning cookies at 50 or do we start repeating them starting with cookie 1 to user 51? Inquiring minds want to know. I want to know.

The new code is not yet in version control. If you want a copy, let us know. We can create a beta branch or send you a tar ball. Happy hacking.

NOTE: Your JoeDog refers to cookie and cookies as objects because they are. Yes, siege is written in C rather than C++ but you can write objects in C just fine thankyouverymuch. An object is simply a thing which references itself. To achieve this in C, you just pass a reference to the object as an argument.



Nice Computer – Shame If Something Happened To It

By jdfulmer | Published May 8, 2015 | Leave a comment

LabMD is a cancer testing center in Atlanta, GA.  In 2010, someone compromised its security and pulled its medical records. Soon after the break-in, LabMD was contacted by Tiversa, a cyber security firm who offered to sell them emergency incident response services. LabMD refused. Tiversa told the firm they’d notify the FTC unless the company hired its services. Again, LabMD refused.

Tiversa made good on its promise and contacted the FTC. The government agency pursued the measure to its fullest. LabMd was sucked into a lengthy legal battle which eventually bankrupted the company. There’s just one problem with this story: the hack never happened.  Tiversa made the whole thing up….



Tech CEO Isn’t A Very Tech-Savvy Candidate

By jdfulmer | Published May 8, 2015 | Leave a comment

Yes, Your JoeDog said he was done with this. Yes, he said he’d never bring it up again. Sometimes he just can’t help himself. Sometimes he’s gotta beat that dead horse. This is one of those times.

You would think someone who made her fortune in technology would run a more tech-savvy campaign. You would think! And you’d be wrong….

http://carlyfiorina.org/

 



How Does Fracking Cause Earthquakes?

By jdfulmer | Published May 8, 2015 | Leave a comment

For the most part, You JoeDog doesn’t get worked up about hydraulic fracking. Quakes and contamination associated with it tend to appear in areas that support it. If you vote for politicians that green light fracking and your water turns flamable and your walls start to crack, then why should Your JoeDog get upset? Cause and effect, motherfsckers.

The epicenter of what-did-you-think-would-happen-when-you-fractured-the-earth-with-lubricants is Oklahoma. The Sooner state — as in “the sooner I get out of here the better” — has been riddled with earthquakes lately. Since the Joad Family said, “We gotta get out of this place” until 2008, the state averaged two quakes per year of magnitude three or higher. From 2013-2014, that number was ninety-two.

Now that could just be a coincidence, amirite? That’s what the energy industry wants you to think. In places like Oklahoma, polticians put their foot on the gas and never looked back. Frack first and ask questions later! Well, those questions are starting to get answered.

The Seismological Society of America sponsored a study whose findings don’t play nice with narratives told by energy companies. In Ohio, hydraulic fracturing activated a previously unknown fault and was confirmed to be the cause of increased seismic activity.

Another study by the US Geological Survey reached a similar conclusion. According to USGS, the seismicity rate changes it examined were “almost certainly manmade.”

As mentioned above, Your JoeDog doesn’t get worked up about this. If you want to wreck your state, he’ll use your cheap gas. Still, the poindexter in him can’t help but wonder, “How does fracking cause seismic activity?” He assumed fracturing triggered a shift.

In a general survey of hydraulic fracturing by the Financial Times, we gain insight from a clear and concise explanation:

Despite a common misconception, the quakes are not triggered by fracking itself, which involves shattering rocks deep underground with a high-pressure cocktail of water, sand and chemicals. Instead, they result from what bursts out of the rock alongside oil and gas: vast amounts of ancient seawater. The water is worthless, so the industry injects it back underground via disposal wells. The problem is that the liquid has unlocked previously stable faults, creating the slippage that triggers a “shalequake”. Such tremors have also been felt in Texas, Colorado, Arkansas, Ohio and Kansas.

There’s nothing about this process that makes Your JoeDog say, “That sounds like a good idea.” Yet it continues because humans aren’t good at long view and there’s a lot of money on the side of fracking to ensure it remains that way. Good luck, Oklahoma. You’re gonna need it.



I Am What I Am

By jdfulmer | Published May 7, 2015 | Leave a comment

#include <stdio.h>
int main(){int a[]={74,117,115,116,32,97,110,111,116,104,101,114,32,67,
32,104,97,99,107,101,114,10};int *b=a;for(;*b>0;printf(“%c“,*(b++)));}



Why Did Linux Become So Successful?

By jdfulmer | Published May 6, 2015 | Leave a comment

Over at the Var Guy, Christopher Tozzi asks an interesting question:

Why did Linux succeed so spectacularly, whereas similar attempts to build a free or open source, Unix-like operating system kernel met with considerably less success?

Tozzi doesn’t claim to know the answer but he examines several theories.

  1. Linux had a decentralized development model.
  2. Torvalds was pragmatic whereas Stallman was ideological.
  3. The Linux kernel was better designed.
  4. The open source community threw its weight behind Linux.

Your JoeDog is not particularly fond of any of these notions. With the exception of number three, most of what is attributed to Linux could also be said of GNU. Yet the GNU kernel never took off while Linux did. But keep in mind, Linux would be nothing without GNU.

Stallman’s team provided the compiler, the debugger, the shell all the command line utilities. Most of what you think of as ‘Linux’ is actually GNU interface utilities. When you type ‘ls’, you’re executing code that Richard Stallman personally wrote. GNU’s only real failure was its kernel but given all its other success, it’s hard to fault its development model. And they were certainly not without community support.

It’s often said that timing is everything and I think that applies to Linux. Torvalds’ kernel arrived at the right time, with the right license, with the right amount of complexity to satisfy the hobbyist. You could do things with Linux. You could breathe new life into an old 386. So maybe there’s some truth to the third bullet but it depends on the definition of “better.” By computer science standards, Linux was primitive compared with GNU’s kernel yet that simple design help align its timing with the stars.



Tattoo You: Apple iWatch and Ink

By jdfulmer | Published May 6, 2015 | Leave a comment

Second World War tattooYour JoeDog hasn’t been to the public pool in years but as a child, he was there almost every day of the summer. It was great. He could get a sugar high off Italian ices and chase sexy girls in bikinis. Your JoeDog wasn’t very old back then and his girl chasin’ skills needed refinement. When he saw a one he liked, he’d try dunk her in the water.

This was the 1970s. when the World War II generation was entering its leisure years. The pool was filled with young and old, Boomer school kids on summer break and old people entering retirement. Those little old ladies didn’t wear bikinis but they sure as hell rocked the one piece. Those old guys were covered with dark blotches up and down their arms and torsos. When you got behind an one in the Italian ice line you could see the blotch was actually a Navy anchor or some shit.

The World War II generation was heavily tatted.

Your JoeDog’s generation doesn’t have much ink. If you see a Boomer or an Xer with a tattoo, you can bet they got it late in life. We grew up surrounded by blotchy smears at the public pool. Those Second World War era tattoos may have been hip during the Big Band Era but they looked like a bad case of melanoma by the time of the Oil Embargo. We saw those things and said, “No thanks.”

Old soldiers may never die but at some point they stop going to the public pool. Gen Y and the Millennials never had a chance to see ol’ CPO Miller’s blotched out Navy anchors on a hot summer day. With no reference images of aging tattoos, a new generation was free to cover itself in ink.

Now Your JoeDog doesn’t pass judgement. The girl at the coffee shop has Keith Haring images tattooed on her arms. He thinks they’re neat; they’re just not for him. But as it happens, our generational revulsion toward tattoos has culminated in an unforeseen benefit. The image of aging tattoos at the public pool, set us on a course toward technological advantage. The Apple iWatch works just fine on members of your JoeDog’s generation.

An Apple support document notes that tattoos can also impact heart rate sensor performance.