Planet Phoenix.PM

Brock's The Lack Thereof: TLT - 2008.01.02 - Events vs Actions in UI Code

Mon, 21 Apr 2008 10:21:15 +0000

Happy New Year!

I've been grappling with a concept for a long time now (years), and thought I'd put it down here to cast about for insight.

Here is one way to handle UI events:

$page->add_action(add_new => 'Add New Entry');
$page->display; # displays template, waits for input
$action = $page->get_action;
if($action eq 'add_new') {
  add_new_entry();
}

Here is another:

$page->add_action('Add New Entry' => sub {
  add_new_entry();
});
$page->display; # displays template, waits for input, runs callbacks

The first is quite imperative. Show the page. Give me the result. Examine the result. Act. The second is much more declarative. I declare that were such an action to occur, this is what you should execute.

The second is the way that Seaside handles things. I'm not quite sure why I'm reluctant to adopt this method... perhaps simply my lack of experience with this construct is to blame. I think it's some sort of voice in the back of my head that doesn't like it because it is a bit too much like desktop GUI callbacks. But why should that be a bad thing? It seems to work just fine for those applications.

I think I'm thinking about this too much.

Brock's The Lack Thereof: TLT - 2008.03.30 - Making Music

Mon, 21 Apr 2008 10:21:15 +0000

I love to create and build -- lately I've made a few songs! My friends like to play guitar and sing, and I play the harmonica and am learning guitar. So here are my recent creations (all with the help or in conjunction with friends):

Only the middle one has a recording posted so far, but I'll get recordings of the others sooner or later. More to come I hope :)

Andrew Johnson's Transformed Planet: Children of Jihad: A Young American's Travels Among the Youth of the Middle East

Mon, 21 Apr 2008 10:17:05 +0000

I normally don't write a review of a book until I've finished it (which means I hardly ever write book reviews, because I've been so bad at finishing books lately), but I really wanted to post about how much I am enjoying Jared Cohen's Children of Jihad. While its subtitle, A Young American's Travels Among the Youth of the Middle East, sums up the book's subject nicely, it doesn't convey how truly insightful the book is. Cohen gained this insight by doing a seemingly simple thing: he listened to people. He sat with them, ate with them, and listened as they told him about their lives, their dreams, their aspirations, their problems. By doing this, he gained a much more complete, coherent picture of the Middle East than any of number of "political analysts" or cultural experts. This is a great book if you want to understand more about the true plight of people in the Muslim world. I'll write a more complete review when I finish the book.

Update: I've finished Children of Jihad, and I have to say my opinion hasn't changed; it's excellent. If you've ever asked yourself how millions of people in the Middle East can hate the entire Western world, this book reveals the truth: they don't. Cohen knows this because he went to the Middle East and talked to them. Even when some groups have grievances with America, they most often were with the US government and US policy than with Americans themselves. (Let's face it: who doesn't have a beef with the US government right now?) Based on Cohen's travels, the problem mostly lies with that small minority of people that do hate the West as a collective, for various reasons. Unfortunately, in several countries those hardline "Death to America" people are in control of their governments, keeping a stranglehold on power and thus being the most visible people in the news media. Not that "the media" is the sole reason for the distorted view that the Middle East and the West have of each other, but doesn't seem to have helped matters much. Reading Children of Jihad definitely gave me a better perspective on the Middle East and its people. Most importantly, it gave me this perspective by using the best source of all: the people themselves.

Andrew Johnson's Transformed Planet: Resolutions

Mon, 21 Apr 2008 10:17:05 +0000

I originally planned to post a list of my new year's resolutions, but especially now that January is mostly over, I think the following is a more healthy attitude to resolutions:

Scott Walters and friends on Twitter: scrottie: @tweetscan Please add search of tweet plus tweeter's location, w/ feeds. Eg, Perl in Phoenix, for http://phoenix.pm.org/planet/index.html

Mon, 21 Apr 2008 08:50:31 +0000

scrottie: @tweetscan Please add search of tweet plus tweeter's location, w/ feeds. Eg, Perl in Phoenix, for http://phoenix.pm.org/planet/index.html

Scott Walters and friends on Twitter: scrottie: NG: bug doesn't seem to be in wincheck. Diffed new vs antique. Now to check rest of slots logic. Argh.

Sun, 20 Apr 2008 20:09:05 +0000

scrottie: NG: bug doesn't seem to be in wincheck. Diffed new vs antique. Now to check rest of slots logic. Argh.

Phoenix Ruby User's Group: [ANN] April 23: Refactor Phoenix Meeting

james.br...@gmail.com (James Britt) — Sun, 20 Apr 2008 03:29:13 +0000

[ANN] April Refactor Phoenix Meeting
April Refactor Phoenix Meeting
Time: Social stuff: 6:15pm
We're at Boulders on B'way!
Presentation stuff: 7:00pm
(We'll be bringing our video projector)
Place: Boulders on Broadway
530 W Broadway Road
Tempe, AZ 85282

Perl Community News: PAUSE gets a CAcert signed certificate tomorrow

Fri, 18 Apr 2008 14:37:00 +0000

The Perl Authors Upload Server (PAUSE) has had a self signed cert for it's SSL stuff. Tomorrow Andreas is installing a cert signed by CAcert, a certificate authority. You might need to install the CAcert root certificate so your browser recognizes the authority and you don't get a warning, but you don't strictly need it to access PAUSE.

Read more of this story at use Perl.

Perl Community News: Perl 6 Design Minutes for 16 April 2008

Fri, 18 Apr 2008 13:24:00 +0000

The Perl 6 design team met by phone on 16 April 2008. Larry, Allison, Jerry, Will, Nicholas, Jesse, and chromatic attended.

Read more of this story at use Perl.

Perl Community News: mod_perl-2.0.4 finally, it's here.

Thu, 17 Apr 2008 15:10:00 +0000

frankie_guasch writes "Finally, it's here and it works with Perl 5.10! http://apache.org/dist/perl/mod_perl-2.0.4.tar.gz"

Read more of this story at use Perl.

Perl Community News: YAPC::SA::2008, April 17-19 in Porto Alegre

Thu, 17 Apr 2008 14:10:00 +0000

worm writes "Brasil-PM and SPB are organizing the Yet Another Perl Conference South America (YAPC::SA::2008), in April 17 thru April 19, 2008. The meeting will take place during the 9th International Free Software Forum (FISL 9.0) @ Porto Alegre (RS) — Brazil, which is coordinated by Free Software Association, and will take place at PUC-RS (Catholic University) Exposition Center. Randal Schwartz will be a keynote speaker. Some live video streamming will be availiable at http://tv.softwarelivre.org/ (pt_BR). Centro de Exposições PUC-RSAv. Ipiranga, 6681Bairro PartenonPorto Alegre — RSBrazil YAPC::SA::2008 webpage http://yapcsa.perl.org.br/2008/ (pt_BR)FISL 9.0 webpage http://fisl.org.br/ (pt_BR, es, en)"

Read more of this story at use Perl.

Perl Community News: YAPC::NA 2008 Registration Open

Thu, 17 Apr 2008 12:12:00 +0000

With exactly two months remaining until YAPC::NA 2008, we are officially opening the payment system for registration to the conference. From now through the end of April, an early-bird price of $85 USD is available for attendees. After that, the registration cost goes up to $100 USD, so if you are looking to save some money on registration, book now! Of course, we are also making the full-price registration available for those who are feeling generous. Some things to note: If you are a speaker, DO NOT pay for the conference unless you really really want to. We will be passing out a coupon code sometime in the next few weeks so that you can properly register. Also, if you are wanting to book on-campus accommodations you'll have to wait a week or so to reserve those; however, you can register and pay for the conference now to take advantage of early bird pricing. The housing registration system will be available very soon. The maintainers of ACT (the system we use to manage the conference) are working hard to create a more robust purchasing component of ACT that will make booking housing easier this year. A lot of this work will be done at next week's ACT hack-a-thon. Please join all of the ACT Hackers in making ACT an even better system for managing YAPC's around the world. And finally, be sure to get the word out. We want to make this one of the best YAPC::NA's to date and to do that we need attendees! Tell your friends. Tell your boss. Tell your local PM group or LUG. YAPC::NA 2008 is almost here!

Read more of this story at use Perl.

Perl Community News: LA.pm Tech Meeting @ Oversee.net, this Thursday!

Thu, 17 Apr 2008 12:10:00 +0000

naterajj writes "LA.pm will be having a technical meeting this Thursday the 17th of April at the Oversee.net offices in downtown Los Angeles. Theron Stanford will be presenting Module Versioning with Apache 1 and mod_perl 1, AKA how to load and use different versions of the same module. For details please visit LA.pm"

Read more of this story at use Perl.

Perl Community News: YAPC::NA 2008 Registration Open

Thu, 17 Apr 2008 02:28:00 +0000

Read more of this story at use Perl.

Perl Community News: Act Hackathon planned next week

Wed, 16 Apr 2008 13:29:00 +0000

YAPC::Asia 2008 organizers would like to thank Eric Cholet, the author of ACT for the great conference organizing software that powers most of YAPCs and Perl Workshops. To show the appreciation in the hacker's way, I'm flying to Paris, France next weekend (April 24-28) funded by YAPC::Asia possible profit, to work on Act feature enhancement. We plan to work on these things because we want them for YAPC::Asia: * OpenID provider support* Better Japanese names display (i18n)* Embed videos and slides (YouTube, Google Video etc.) in talks* Personal Scheduling (Who is attending to which talks)* Online check-in API (Who actually showed up when)* Promotional code / coupon for discounted payments We (at least, I) prioritize implementing these because the trip is funded by YAPC::Asia but if there's anything you think is missing for Act, I'd love to hear. Remote participation (#act on irc.perl.org during the weekend) would be welcome too!

Read more of this story at use Perl.

Perl Community News: Parrot 0.6.1 "Bird of Paradise" Released

Wed, 16 Apr 2008 10:13:00 +0000

particle writes "Aloha! On behalf of the Parrot team, I'm proud to announce Parrot 0.6.1 "Bird of Paradise." Parrot (http://parrotcode.org/) is a virtual machine aimed at running all dynamic languages. Parrot 0.6.1 can be obtained via CPAN (soon), or follow the download instructions at http://parrotcode.org/source.html. For those who would like to develop on Parrot, or help develop Parrot itself, we recommend using Subversion or SVK on the source code repository to get the latest and best Parrot code.

Read more of this story at use Perl.

Perl Community News: NPW 2008 - Website online and registration is open

Tue, 15 Apr 2008 23:04:00 +0000

The ACT website for Nordic Perl Workshop 2008 is now online and registration is open. You need an ACT account to register but if you've been to any YAPC or local workshop the past few years chances are good that you already have one. If not, signing up for one is easy peasy. Oh, and don't forget to submit talk proposals if you want to give a presentation! Hope to see you in Stockholm,Claes Jakobsson and the NPW2008 organizer team

Read more of this story at use Perl.

Phoenix Ruby User's Group: April Phoenix Rails Meeting

de...@integrumtech.com (Derek Neighbors) — Tue, 15 Apr 2008 21:19:37 +0000

Late notice as it has kind of snuck up on me with all travel and
madness that has been going on.
Tuesday, April 15, 2008 7:00 PM (TODAY)
Integrum Technologies
290 East El Prado Court
Chandler, Arizona 85225
33.3389, -111.835
Description
Overview of Mountain West Ruby. Potential presentation by Chris

Scott Walters on use.perl.org: To maintences programmers, all languages are the same

Sat, 12 Apr 2008 07:05:33 +0000

Yeah, it's a bold assertion because it flies in the face of so many gripes from so many people for so long. Take the dailywtf. "I'm maintaining this horrible ASP programming" or "the guy who worked here wrote this in Perl". I wrote earlier about about the rot of Phoenix.PM as the entire congregation defected leaving only maintenance programmers.

These are programs that have been driven into the ground. Fear of refactoring, having the wrong people calling the shots, and the wrong priorities turned them into dung. This can happy in any language. Java has now been around long enough that programmers written in Java have descent into chaos. I've seen them. I've been hired to hire Indian programmers and I insisted on reviewing code before hiring a firm. All of them had terrible voodoo chicken bones code that in 100 lines foreshadowed million line voodoo code projects. And it was all in Java.

A program in any language in a historically badly run project evolves to somewhere past point of insanity. No self respecting programmer will try to continue adding features at this point, accelerating the descent when companies hire novices to try to extend the dung heap. The good programmers are put on maintenance; they won't do anything else, and keeping the thing running is a challenge.

But you know this. What matters is that the economics completely change when the project goes to hell.

The expectations for a maintenance programmer are calibrated to the difficulty of the project. None of the schedules, deadlines, SLOC, milestones, or other productivity metrics apply. There are easy bugs and hard bugs and sometimes the hard bugs live for a very long time time. Doesn't matter if it's COBOL, Perl, Java, ASP, or what. The maintenance programmer proved himself over and over again to his employer, so the lack of metrics don't matter. He's woken up at insane hours, worked late, and traced down insanely involved problems keeping the whole thing wedge. But... the language doesn't matter. The difficulty of fixing problems doesn't vary. It's a matter of definition: the project grew in whatever language until its unmaintainable, where ever that is for the language, and then the good programmers are just keeping the boat afloat.

Phoenix.PM is almost entirely composed of maintenance programmers. Programmers who like to write new code left a long time ago. And that was in other languages, for the most part: Java, C++, Python, Ruby...

But as a maintenance programmer, you're not writing code. And if you're proficient in a language, you can read the code. The idiom doesn't matter. The idiom doesn't make you more or less efficient at hunting action-at-a-distance problems. The hard bugs aren't in the expressions, they're in the interactions between parts of the system... or the lack of parts of the system. The fact that Perl's syntax can be confusing is completely irrelevant to maintenance programmers. Those are the easiest bugs they encounter in their job.

So, the conclusion that could easily be drawn from reading the dailywtf... that Perl is horrible, because there's so much horrible Perl out there... is a fallacy. Or that ASP is horrible because there's so much bad ASP out there... in both cases, I suspect the real problem is that programs overgrew their design, weren't redesigned and refactored, and the good programmers were forced into maintenance by business need.

If you're a good programmer who likes writing code, you're forced away from entire languages. You're suddenly unable to touch Perl, as an employee, because the only jobs are maintenance or else adding features to a completely fucked system, which you won't do. A few dozen companies mismanaging projects ruined the market for you.

And, conversely, PR won't do any good for Perl. The only thing to do is... start new projects. CPAN modules are good, but "Web 2.0", or "dot com" or whatever businesses. Make stuff in it that people care about. Create new projects that'll require maintenance, perhaps, and might be easy to maintain, but regardless *aren't* maintenance gigs right now.

-scott

Scott Walters on use.perl.org: what twitter-land is saying about Perl

Sun, 06 Apr 2008 08:34:40 +0000

I use Twitter. I like being able to tell my 1.5 friends where I'm at and having him maybe drop in on me. (God, I suck.) I found http://www.tweetscan.com and decided to search for mention of Perl, possibly to follow Perl users in the area, if I could find them. Here's a sample of what I got:

ceri : remembering why I hate Perl

PoBK : *Scream* This is why I HATE perl. There are no less, that 17 modules on CPAN to query domain Whois data! Seventeen!!!1oneeleven

ironsoap : We now come to the part of the show where I sing a little song about how much I hate Perl and its evil sibling Unicode.

calico : @mrballistic - re: DB-backed sites -yep, I worked with a company doing it with PERL backends and an Access DB back then - painful

neilfws : think the perl love affair might be over

jonsagara : I can't believe there are Web applications still written in Perl.

baseonmars : i want to stab perl in the head and make it's eyes bleed.

ba78 : "No one working on ES4 wants it to be like Perl 6." :)

chastell : ‘Perl style guide’. ahahaha *snort*.

neilfws : enough perl horror for today; need to go home and calm down

acdha : replacing hackish Perl with half as much better Python feels *so* good

etherjammer : @fadeaccompli, deep sympathy. - just occurred to me - are you going to have to learn Perl?

eosadler : @amndw2 Why perl? Consider trying ruby. "Learn to Program" by Chris Pine is a great intro book that I've been teaching from.

SlexAxton : Both of these return true in Perl: "Perl" eq "Perl" and "Perl" == "Dumb"

fortunetweet : There are worse things than Perl....ASP comes to mind

breathoffire : The whole "theres more than one way to do it" concept of perl can be tedious.

noahk17 : @bluesharpie5 So far everyone has said job #2. Perl is dead anyways. I'll be sure to tweet as soon as I hear something!!

mpstaton : @dweekly perl? isn't that so 2004?

offwhitemke : Primary experience example of less code is not better, Perl. ... to be fair, there were some positives mixed in, but the overwhelming negativity caught me be surprise. I'm trying not to be in denial about my language choices. This can't go without comment. Well, it could. My reply:

Perl haters: shut the hell up until you learn awk and sed, understand what they do that other languages don't, and why Perl took from them.

I know; boring old topic. Image changes like adding strong typing (typesafety.pm), publishing Best Practices, CPANTS, aren't going to change perceptions. How do we tell a whole generation of people first learning to program on purely procedural/OO languages what the *point* of Perl's existence is?

-scott

PhxBSD User's Group: PhxBUG April Fool's Meeting

Mon, 31 Mar 2008 20:36:18 +0000

Start: 2008/04/01 - 7:00pm

End: 2008/04/01 - 9:00pm

Start: 2008/04/01 - 7:00pm

End: 2008/04/01 - 9:00pm

Location: ASU GIOS [map]

Details:

This month's presentation will be Firewalling with PF, from Basics to Bastion Host. The packet filter PF is available on OpenBSD, FreeBSD and NetBSD and features a simple, clean syntax which makes it accessible to home users, though it's powerful enough for enterprise applications.

Location Details:

GIOS is on the southwest corner of University Drive and College Avenue, directly across from the Newman Center and next to a Methodist church parking lot. There is free parking on 7th Street a block north of our location but they charge you to park in the Methodist church lot. It is similar to before where the entry doors are locked at 5pm and the conference room #308 is in sight of the door. You must take the elevator to the third floor.

Scott Walters on use.perl.org: How to be productive at work, not yer papa's version

Sat, 29 Mar 2008 02:27:34 +0000

I spent a few years at web shops and watched new programmers come in. They fancied themselves great programmers; being young, they had a lot to prove. They didn't like how we did things. It was so stodgy and dated. But rather than show us how it's done, they... did nothing. Overwhelmingly, they crawled into a shell, where they maintained at least the imagined possibility that they're a great programmer trapped in a terrible company. My take on this is that they're afraid that if they ever tried to spread their wings, they might fall, then they'd be really embarrassed. Or it would take a few tries to get it right. Or it would be more difficult than they imagined. Or they'd get unlucky and be judged by their one failure.

Advice: get over yourself. Good programmers know what it's like starting out, and we're not keeping score. We don't force you into a strict regiment because we have faith that you'll eventually grow into the role, trial and error included. If you don't like the company you signed on to, then do this: really spread your wings and risk making mistakes, getting in over your head, breaking things, failing to implement designs, and so on. Make your mistakes there, learn your limits, and grow, and do it before you find yourself in another company, in a position of having to prove yourself. Were you defeated by some small, backwards, ASP using company? Why? Try to conquer them. Even if you fail, you'll learn countless valuable lessons in trying to take over companies -- and by take over, I mean steering technology in a positive direction, one of your own choosing.

Work boring you out of your mind? Selling widgets not engaging? Don't pretend. Ignore the hype about agile... widget selling. They probably have a lot of turn over from unmotivated programmers. Rather than trying to strike a compromise with their programmers making staying worth their while, they treat the programmers like they're stupid and try to convince them that selling widgets is the coolest thing out there. Rebel. If you're really good, you can spend half of your time working on fun projects and still your employer will still be far better off than if they hired some twit who didn't have a good work ethic anyway. Spend your time improving Perl. Releasing code as open source used internally. Generalizing processes so your competition can use the code. Make Perl faster so your employer can buy less hardware, and share the wealth with everyone. Re-interpret your own job title. Yes, companies hate this, but it's a fallacy for them to imagine that a brilliant programmer could be tricked or coerced into spending that same energy and passion... selling widgets.

Learn what all of the other groups do. Learn the reasons they don't like your group, which almost certainly exist even though programmers are shy about admitting them. Be a judas. Make connections there. Connections are good.

Spend a certain amount of time trying absolutely crazy schemes. Write code to heuristically identify in-lineable method calls, cross reference it with DProf output of which are frequently called, and inline them with B::Generate or Code::Splice (created for that purpose). It might not work. It might be absolutely terrible. But doing something hard the wrong way will almost certainly illuminate you as to the (or a more) correct way to think about the problem. And if you get stuck in the mindset that all attempts must be successful, you'll only go after the low hanging fruit, and the project will slowly collapse under its own weight. None of the hard refactors will be done. No serious overhauls will be made. No really new ideas will be incorporated. I've worked in Perl shops that were downright xenophobic about ideas from other camps -- and I attribute it to this "all programmer time must be accounted for, all projects must succeed" induced shell shock. Under a fascist regime, all new ideas look like bad ideas.

After you fail at something hard, or something crazy, you'll have motivation -- saving face -- to work on the boring stuff.

Working on the boring stuff isn't all bad either. That's often when the patterns with a general solution appear.

A general pattern to this blog post is companies who hire programmers at one level and expect them to work at exactly that level and stay at that level, like a cog. That's not good for you or them.

Here's a fun crazy thing: write parts of the system in a completely different language. People whine entirely too much about splatterings of different languages. If the Google programmers are so fucking smart, how come they can only cope with having Python, Java, and C++ around, and nothing else? Pussies.

Work other places than in your cube. To get the juices flowing, you have to break the routine. Sure, they don't let you on the 802.11, and if you put an AP under your desk, they'd hunt it down and destroy it and you with it. But they're probably not sniffing for Ricochet. Get some old STAR modems and set up your own wireless network. Or packet radio. Or any number of other technologies. Work in the company cafeteria. Pretend it's a coffee shop.

Get your work done in a marathon session at the start of the week then take the rest of the week off. Stop in on Friday to catch up on email and get a jump on planning the next week. I don't mean work really hard from 9-5 -- I mean pull allnighters.

Make friends with people who work for your competition. Your employer will hate this too, but it's very useful to break out of the "We The Company" mindset. I'm not sure why they pump that stuff on everyone as it's fundamentally destructive. Having some perspective on it all will help keep the stupidity from bogging you down. Perspective wards off depression.

Every now and then, get your coworkers involved in a little fragfest.

When your CTO does something stupid, blog publically (but anonymously if necessary) about how stupid the thing he/she did was. Don't think that just because they report directly to the share holders, they're immune from responsibility to the shareholders (fuck all why anyone would take that leap of logic anyway).

Find people you like there. The job will end for one of you and before you leave or he/she leaves, get to know them. Your future is far more wrapped up in good people than some mythical, imagined "good job".

-scott

Scott Walters on use.perl.org: Offtopic: Women.

Wed, 26 Mar 2008 02:41:55 +0000

Okay, guys. Letting things go and trying to smooth things over doesn't work. It's destructive. Counter-productive. No, don't snap the first time the women does something you don't like or stats nagging or bitching. And this isn't women vs. men. Here's the crux of the problem: when one gender starts pretending like bullshit isn't bullshit, they've sent an open invitation for more bullshit. They'll find that they're *always* wrong because the other gender is making the rules. It seriously sucked to be a women in the 1950's. Men made the rules, and the rules were arbitrary, set after the fact or made up on the spot (like Calvin Ball), and interpreted according to whim and agenda. If the 1950s male felt the female was being ditzy, absent, irresponsible, imprudent, or otherwise "unladylike", he'd become angry, solemn, reproachful, or some combination. There was no arguing it. The female simply had to wait for the wrath to pass and some figurative second chance to be extended.

Then we had women's lib, equality in the workplace, the divorce revolution, female sexual revolution, and so on. This is not all bad, no question. But some myths were created as waste during the process. Here's the king of them: that if a women feels injured, that the male did something wrong. No. Bullshit. People get hurt feelings for bad reasons perfectly often. Children have episodes where they act as if adults have some conspiracy against them and that's why they don't get the cookie they want or the toy they want. With a stern hand (not giving in at the threat of a tantrum), children eventually learn that them not getting the toy or food has to do with far more complicated affairs -- money, health, and just general education in emotional maturity, especially in not being manipulative and demanding. Of course, not all children have the benefit of this education. Some go through highschool or college without anyone every saying "no" to them. And for some bizarre reason, probably also a waste product of change in the past 50 years, the conceited, manipulative, self-important, obnoxious, demanding, pouting, crying, whining, spoiled female is currently in demand. What the hell? There are countless shades of grey aside from the extreme case and it would be impossible to enumerate all of them.

Now, men's desires are treated as illogical and childish -- the desire to own motorsports equipment, to hang out with their friends (play poker, or SJG Illuminati, or just drink beer). It's indulged with condescension. The state of the house is dictated by the female, with which furniture and decoration is desplayed vetted by them, and any evidence of a male presence virtually removed. The whole house is girlified. Video games are hidden. Behavior, action, and decision making is run by the female -- at least in the last several relationships I've seen -- with a few notable exceptions. All all, with the few exceptions, were extremely unhappy. The female was insecure because she had no way of knowing that the male's love was genuine or it was a duty/act, since it's largely forced and extracted. The male can't behave as he pleases in cases where it just doesn't fucking matter, but instead has to justify everything and get permission from a gender that can't understand male stuff (just as men can't be expected to understand make up, barbie dolls, and the elaborate social system of women). And everyone is unhappy.

I'm not encouraging a revolt, or a reversal. It comes down to this: say "no" sometimes, as it *makes sense*, not to push weight around. If the women loves you, she'll deal with it. If she starts pulling crap, call her on it. Don't pretend like bullshit isn't bullshit. If she just can't express her case, give her all of the chances to explain it and give her indulgence for strange behavior in the interium. But when she's bitching at you for something stupid, say no. Leave. Let her stew. Let *her* decide if *she's* willing to love you and *herself* look past behavior she can't understand. When she demonizes behavior she doesn't understand, explain as best as you reasonably can, but don't let her inability to understand dominate your behavior. It's possible to be loving, not do that bitch-ho crap, but not be a complete pussy either. Stand up for yourself. The women are doing it and the men haven't walked away. Each relationship is still going to have a leader, but it should be a kind, and not insecure, leader.

I write this because people I'm close to are suffering.

-scott

Scott Walters on use.perl.org: Still pondering hosting: open SSILinux cluster?

Sat, 15 Mar 2008 09:27:03 +0000

Still pondering hosting. There's a colo in town that charges less than DSL, at $45/mo and I want to have some fun with it. So here's my latest...

Colocate one SSILinux x86 machine there, and through a re-seller deal or something, encourage others to send x86 machines to me to get
installed with SSILinux and added to the cluster.

If you're not familiar with SSILinux, it's a hacked up kernel that makes a bunch of machines on a LAN look like one big machine lots of RAM, CPUs, and storage. See also OpenMOSIX.

For your $50/month (or whatever), your machine gets added to the cluster, and you get a permissive account on the cluster (probably with some restricted sudo access). So, rather than just having a lame machine colocated somewhere, you have the shared resources of a supercomputer! (Exclamation point, exclamation point, exclamation point.)

I was toying with doing yet another free shells service, but I can't break away from the fundamental problems of not wanting to lock it way down (dissallow CGI, etc) but not having enough CPU resources in one machine to give out permissive shells.

Groups of users fearful of "the slashdot effect" (also known as the reddit effect, and so on) could band together. Not everyone's site could be hit at the same time, but the spare capacity could see one or two people through the storm.

And it's anti-isolationist. Sure, it's nice being root, but it's also nice having users (which I currently lack, almost entirely). They put mp3s of little local bands in their folders and you can swipe copies. You can help them with their code, and they can easily help you with yours, and everyone just generally checks out what everyone else is doing. Life is a beach =)

Some "community policy" stuff would have to be put into place. If anyone is using more than their fair share and doing so consistently (trying to crack passwords, whatever), they get booted off the cluster after a warning. If they're merely using more resources than they're contributing, perhaps they can be asked to add another machine or upgrade their existing one.

Unlike existing shared hosts, daemons would be allowed and expected. Enough IPs could be bought and the public interface aliased such that everyone who wanted to run a stupid IRC server could.

I got this 1.6ghz Celeron machine here to colocate running FreeBSD (having given up on the stability of free Unices on RISC hardware and having given up for the time being on Solaris and IRIX), but maybe I'll really slide back that way I don't want to go and run Linux on x86 (yech, yeck) just because clusters are cool.

Thoughts? Would *you* give up (most) root privileges to have your dedicated host be part of a growing supercomputer?

-scott

Scott Walters on use.perl.org: scrottie's guide to Phoenix

Sat, 15 Mar 2008 06:37:52 +0000

In Phoenix for about ten years, I keep thinking I should do a review site. Phoenix is mostly a wasteland of endlessly repeating chain stores, but after long, hard, careful searching, a few gems have emerged. I'm cranky, and my annoyance at the sucky drives me to find the good, and this is the result of my effort. http://placestoseeinarizona.com/ is another excellent list (hey, I've done almost all of those things!) that focuses more on adventure and living life in AZ to the fullest. In no particular order:

Doctor: Your Neighborhood Doctor, Dr. Garcia, 6345 E. Bell Rd. Walk-in. I hate the whole "doctor's office" deal. Waiting an hour for a minute of someone's time who doesn't listen and then abruptly vanishes without warning is pointless and humiliating. I really can't explain the Your Neighborhood Doctor other than to say that they just don't do that, pointedly so. It's like the story where you walk into the executive office to have a confrontation with the CEO, find yourself confronted with an intelligent, sympathetic, thoughtful person, who turns out to be the janitor -- except in this case, he isn't the janitor.

Optometrist: Horowitz Vision Center. East of the Fiesta Mall in Mesa in the same complex as a chain optometrist. Got that small town business feel. Again, she loves her work enough that she broke out of the existing system so she could do it right.

Pubs with Good Beer: Popago Brewing: Laid back, local, 20 good beers on tap, great selection in the (large) cooler including Belgian styles, a local specialty. Four Peaks, north or south location: Good atmosphere, pretty good microbrew beer. The Hopknot is probably the most exceptional of the lineup. Bandersnatch was on the top of this list except the Tempe goons ran them off in their quest to McDonands-ize downtown Tempe. Fuckers. The Roosevelt: Seriously dig their Rogue fetish. Casey Moore's, just for it's college alternative vibe.

Food: Indian, just SE of University and Rural (aka Scottsdale). Also, the Copper Kettle. Aladan's for lunch, SE corner of 92th and Via Linda. Four Peaks has fantastic bar food too, bordering on gourmet but staying in the pub genre. Que Bueno in Fountain Hills has the best salsa and damn fine margaritas. Sakura Inn in FH is cute and the sushi chef sweet and genuine, but the new owner is extremely obnoxious and pushy. Sushi Ko on 92nd and Shea rocks for authentic and is better than the overpriced "experience" places. Nello's, two locations. Some good beers (used to have a lot more) and good pizza pies -- specialty stuff.

Internet: FastQ. Grew out of the local Apple user's group, but is a Linux, Solaris shop mostly. Everyone answers the phone there, and everyone you talk to knows their shit. Dedicated IPs are cheap and the ToS is permissive, and they don't screw with your traffic or bandwidth.

Coffee: This is a real flash point with me. Current set is Mill's End Cafe (on Mill), Three Roots (also on Mill but further down) for working, but the extremely boisterous and bizarrely ignorant college students frequent Three Roots and families with screaming kids and organizations composed entirely of fat old men frequent Mill's End. Inza Coffee NW corner of the 101 and Shea in Scottsdale: every "for here" latte order gets you coffee art! Open mics, music, art exhibits, free dance lessons, homemade food, outlets everywhere. Also, loud, obnoxious, shouting sales men on cell phones during the day. Bleah.

I'm sure I'll think of more later (and edit them in)...

-scott

Scott Walters on use.perl.org: Go save your half.com wishlist now before they delete it

Fri, 14 Mar 2008 10:26:07 +0000

Two emails came in, back to back, while I was out on errands: that half.com was going to delete items from my wishlist unless I updated it; and that they deleted "old" items from my wishlist, and in the future, I should "keep it up to date". FUCK!!!

Looking at it, sure enough, it's down a few pages from what it was.

Every book in there, I seriously intended to *probably* buy, and even though I had twelve pages of books on the wishlist, I'd already bought on the order of 30 or 40 books from them. Every few months I go on a bender and drop $100 there. It wasn't as if part of my wishlist was "old"... what I bought off my wishlist when I went on a spending spree there had nothing to do with when I added the book to the wishlist.

So, now, things expire off your wishlist, and they have little clocks that run down, and you can add more time to them, manually. If you don't ask for more time every few months, it gets deleted. They implemented this feature and didn't warn me until after some of the timers already went off. Again, FUCK!

It's really my own fault for trusting a site with data, but half.com was my master list of books to buy. Along time ago, I dabbled with a proxy service that would show you your entire half.com wishlist on one page by scraping their site, but they changed their interface so that you can't view other people's wishlists, so it got scrapped. I had output from it so I had a snapshot of a very early wishlist. I spent the last three hours piecing together what I could of what was missing, printing out the raw wishlist pages (in fear that more timers would go off in the next few minutes), opening each page, and cutting and pasting book titles and URLs into a text file, and then finally, deleting the entire wish list so I wouldn't be getting these horrific emails that my data is being deleted.

Another reason they cited for deleting from my wishlist: their preference engine does a better job finding things for me when the wishlist has fewer things on it. So, wait, they want me to buy more stuff, but stuff that they suggest, rather than the stuff that I actually *wanted* to buy, so badly that they'll delete my wishlist items to better find things to spam me with? Bloody hell. Morons!

Maybe most of their customers add vast amounts of things to their wishlists and never look at them and they're losing tons of money buying storage space, but honestly, that's hard to imagine. Each thing in my wishlist is one record in a hinge table: it references the item, and it references me. That's two 32 bit integers. Maybe a datestamp too. So my whole wishlist was a few K, even though it was 12 pages long. Is risking pissing off their hard-core customers worth reclaiming these few K from their deadbeat customers? Wouldn't it have been nearly as effective to send people an email asking them if they really want their wishlist, giving them 30 days notice, rather than ten minutes?

eBay (the owner of half.com) is a great big monopoly and it treats its customers like shit. So, I'm now in the market for another online used book store/market. Suggestions?

-scott

Scott Walters on use.perl.org: MCS (certain chemicals make me stupid) update

Sat, 08 Mar 2008 01:41:29 +0000

An MCS Yahoo! group stumbled across an old post in here where I talked mostly about my earlier experience being extremely sensitive to certain common pesticides (so sensitive that my autoimmune system invades my brain -- google "MCS brainfog" if you want some color of what this looks like).

Here's a quick update, meant for other people with this problem (and it happens with environmentally persistent chemicals that build up in your body and in animal fat in your food other than pesticide) and for people who are just hoping I'm doing better now days.

I'm not suffering day by day, which is *huge*. I can't tell you. But I'm still in a precarious place. I'm basically dependent on telecommute work, and I have too much debt from too much time out of work to be comfortable and not enough backup plan in place (if I suddenly have to move to escape this problem, if the job goes away, etc). So anxiety still runs very high. I cope with it in various productive and non-productive ways -- often it just overcomes me. I'm worse the wear, pretty burnt out on humanity and generally war tattered. But, again, day by day, it's been good lately. I had a neighbor for a long time who didn't consider spraying for the ants eating the grease on his BBQ every day to actually be spraying and wouldn't stop because he wasn't really spraying (I'm not sure what he considered spraying). And sometimes a neighbor would try to kill all of their weeds (so I spent a lot of time pulling everyone's weeds for them, which made me feel like an ass, as well as feel bullied). And sometimes they'd go on a termite scare and have a company in with a large truck and a 5hp gas pump to dump hundreds of gallons of pesticide on their yard just down the road, triggering an emergency multi-week trip to visit a friend, the first few days of which, I was pretty boring. I often cope with pesticide exposure by drinking heavily. It's diuretic, causing my liver to just pee out a bunch of liquid, flushing the system that way (assuming I'm also adding lots of water), it takes the edge off, people expect drunk people to be/act stupid so it's camouflage, it gets me out of the house or away, and heck, I might as well.

Advice to anyone with this problem: GET OUT. Put your stuff in storage with a family member or friend, tell them you're not feeling well, you don't think it's mental, but you can't explain it yet but you need fresh air. Get a tent. Go camping for a week to clear your head. Make a plan. Ask for help. People *will* help you -- not all or many of them, but don't be shy about asking craigslist for a pesticide free place to live. Don't be shy about telling people who are willing to rent you a room that because even the actions of neighbors affect you, it still might not work out, and you're very sorry and hope it does, and very grateful. If it doesn't work out, repeat: camp again, do something else. Don't camp around other people. Find the state parks in your area where you can camp. Find a laundromat and wash your clothes and everything of yours you can before you go. Don't try to bring things with you that are covered in pesticide or perfume or whatever your trigger is. Don't be ashamed to be a "bum" while that's what you have to do. There are lots of people who, for various reasons, just loaf for a while. Maybe they went through something traumatic, like a war, or just have emotional stuff they need to sort out. Don't be afraid to share their company. Use hostels. Use the strange resources out there. Don't be shy. You *have to* so you might as well stop dragging your feet. If you do what you have to do, you'll get out of the brainfog and be able to think clearly. Let your family and person obligations go if you have to. People will understand, and you'll get your life back when you get your living and working situation going again. If you have to beg, ask people to feed you, not give you money. Don't be shy about that either. Hitchhike. Ride Greyhound. You can always get off Greyhound. Use couchsurfing.com. Tour Mexico. Get away from the problem.

-scott

Scott Walters on use.perl.org: Catalyst Book Review... that I need to write

Fri, 07 Mar 2008 02:38:59 +0000

I promised Packet Publishing (http://www.packtpub.com/) I'd do a review of jrockway's _Catalyst Web Framework_.

Packet seems to be sort of a boutique publisher who writes about whatever topic they have available passionate, knowledgeable authors. I wanted to do this review because the company that published me, APress!, has a similar mojo going and I believe in it. Its the opposite of the "everyone and their dog" approach.

And I recognize the name. I even met jrockway once, at YAPC. All in all, people who already have a name tend to write better books.

I had an ulterior motive too: I wanted to force myself to sit down and actually learn this Web framework stuff that's all the rage. Like a movie that gets played on TV over and over, I keep seeing bits and pieces of it, and wanted the whole story once all the way through.

I'm having a hard time writing the review. I read the introduction and was ready to write exuberant praise. The rest isn't exactly bad -- in fact it's probably also great -- but it really served to reinforce the bias I went in with.

The writing was great, and the production was solid. It's pragmatic; it briefly (one paragraph) lists advantages of over CGI and then doesn't touch that horse again. Talking about the "over 190 plugins" for common tasks like "config file parsers, logging tools, email, caching, user authentication and authorization, crypto, internationalization, localization, browser detection, even virus scanning", giving examples of building sites in a modular fashion, and so on. Lesser books walk you through; this one guides you. He stops to explain what the various files in the distro are and generally answers the question, "what's that?".

But when the XML, Perl, TT, DDL, XHTML, and configuration for the ORM all got spilled all over the pages, I cringed. As someone wrote, "an ill-assorted collection of poorly matching parts, forming a distressing whole". Granted, he holds off on the DDL/ORM till the second or so example. He talks about how everything is pluggable and you can use whichever modules you want, but it's clear that no matter how you slice it, but in the end, you get a fire truck. Sure, it's powerful, but it's awkward, bulky, difficult to manage, and complex. And while versatile, well suited to very few actual tasks. Yeah, it does a bunch of things for you, but it adds just as many tasks. The "ORMs are Vietnam" essay comes to mind. Seemingly, web frameworks are also Vietnam -- appealing at first, promising at the onset, increasingly difficult to complete the task, but far too complex to take to conclusion.

Don't get me wrong. I'm a fan of domain specific languages. Imagine HTML didn't exist. The Web would work like existing GUI toolkits: under software control, by long series of method calls setting values and building containers and adding things to containers, code would manually create the hierarchical structure of the display document. The code to construct the document would be twenty times larger than the document itself. It would suck.

I just have to imagine that DSLs would combine a lot more effectively. Web::Scraper combined HTML::TreeBuilder, some XPath module, and a few things in a stroke of brilliance such that you need to use none of the modules to leverage most of the effect of all of them. In Catalyst, you have to learn all of the modules to leverage the utility of any of them.

Through the introduction, the bearing on each thing on every other thing was clear. By the time we got into actually modifying the generated code, I was struggling to keep up with the web of relationships of what calls what and what identified is used by what to reference what in what scope. What matches? What depends on what? If I were writing this book, I'd have made a hairy ass diagram to illustrate the inter dependencies. Glossing over it, over simplifying it, sweeping it under the rug... makes it seem easier than it is... until you try to do it yourself.

As it is, things have not changed considerably since Zope.

This reminds me of when I was trying to figure out the combination to a padlock that I had lost the combo for. I was watching a video because I couldn't find text. I didn't know if the whole video was instructions or if he gave a demo at the end so I had no idea how involved the instructions were. You find where it sticks, write down those numbers, then find those that are all multiples of certain other numbers, divide, multiple, pick several from the list fitting something, do some combinations based on the first and second, and so on. I'd have been a lot more prepared for the process -- and a lot more careful -- if I'd known the actual level of complexity of the whole process at the onset rather than a continuous stream one-more-thing.

All the Web framework has to do is take requests from somewhere, figure out what generates the content for them, calls them, let them (none of your business at this point) call whatever they need to generate themselves, and let them have an area to dump temp variables into so the parts of the page can communicate with each other. So, here's my challenge to you: next time you go to use a Web framework, write your own instead. I bet you can do it in 10-20 lines. 100 tops. At a certain point, you have to shift focus from the end users to the developers. I think someone should write the book, _Writing Web Frameworks_.

-scott

PhxBSD User's Group: PhxBUG Meeting - Beer & BSD

Wed, 05 Mar 2008 02:00:00 +0000

Start: 2008/03/04 - 7:00pm

End: 2008/03/04 - 10:00pm

Start: 2008/03/04 - 7:00pm

End: 2008/03/04 - 10:00pm

Location: Casey Moore's Oyster House Map

Details:

This month will be Beer & BSD! Last month was our final meeting at the old location, and next meeting should be our first meeting at the new location. In the meantime the people at Casey Moore's have promised not to run out of our favorite beverages, so let's hold up our end and keep the BSD chat flowing.

Scott Walters on use.perl.org: Programming Perl, except s/P/6, s/e/5/, s/r/0/, s/l/2/.

Thu, 07 Feb 2008 10:50:46 +0000

Perl can do anything. That's kind of boring, in a certain way [Footnote 1].

Because Perl is so powerful, it's that much harder to impress people with any particular thing you do. There are multiple reasons to want to impress people; perhaps you're vain. Perhaps I'm vain. But I also just enjoy code as a highly formalized system of, basically, poetry [Footnote 2].

So maybe that's why I'm writing 6502 code for the Atari 2600 right now. Or maybe I just always wanted to. Or maybe I miss writing 6502 for the Atari 800/XL/XE computer, but I'm enjoying the better development tools (vi, dasm, cc65 on a fast host, generating tables from Perl). But that's not why I started this article.

I had a thought. It requires some background. It's not interesting outside the scope of Atari 2600 programming, but if I pulled it off, which I'm not even going to try to do, I'd impress. The 2600 has no frame buffer. To display an image on the screen, the processor has to spend all of its time basically copying data to the screen by way of hardware registers. For the most part, the code looks like LDA #$xx, STA $reg, with some table lookups off of the X and Y registers too. If you have a RAM based cartridge, like the Starpath, you can write self-modifying code that generates code to do nothing but LDA #$xx, STA $reg, over and over. That's as close to optimal as you can currently get. There isn't enough time each scan line to update all of the registers. You can position a sprite or two, update the sprite colors, but then you don't have the cycles to update the 40 bit wide background, or vise versa.

But a cartridge could be even *better* than RAM based. What if the code did nothing but LDA #$00, then STA to registers over and over while another chip actually drove the data bus? The 6502 would be sending low signal on all pins, but if there were some Xilinix style programmable logic on there too that knew how to just blitter data from a buffer straight to the data bus, every third cycle (with the other cycles being STA instructions read from ROM and then the one byte page zero address to write to)? You could *double* data throughput to the screen. Rather than screens being little programs, with lots of index registers and lookup tables, screens would be pure data -- what to write to the player and missile position registers, the background data registers (which must be updated *twice* a scan line if you don't want the right side of the screen to mirror or copy the left side), player color registers, background color registers, etc, etc.

The 2600 doesn't export many pins to the cartridge, so the ROM can't bus master. But with this scheme, it could be faked badly. Some register could be written to to tell it to wait to start asserting the data lines every time it sees a page zero STA. Then the register could be banged again to make it stop copying data. It would need its own little ROM or RAM or something. STA zero page takes three cycles. There are 76 cycles per scan line. One STA should be done to the CPU sync register, and to keep the size of this routine from being completely unrolled, a branch should be done, which leaves enough cycles for 22 register bangs -- unheard of.

Oh, even better, if the code does one LDA #$00 then STA $00 over and over, then the PLA could assert both the data and the address, and then each line would be even more free form for things like updating player position to make players appear in multiple locations on the same line on some lines while changing colors on others, etc.

Footnote 1:

You do something hard or clever, and people say, thanks, you saved me the work (even if they're half serious, or if they really wanted it). Marc did Coro, which is mind blowing, and no one really... well, no one's mind was really blown.

Screw you all. You're spoiled rotten with all of this great CPAN stuff.

Footnote 2:

Sometimes people write Perl where the source code is literally poetry, but more often, it's beautiful for other reasons. Poetry makes clever use of words. Code makes clever use of interfaces, glue, algorithms, etc. Good poetry, like code, inspires awe and makes us feel like the world is a little less desolate of stupidity and coldness.

Someone wrote how about they considered code to be a specific kind of art -- a performance art. I don't remember their original argument, but I remember it jiving with me. It's more of a skill than a specific accomplishment, each work has very limited scope, it doesn't age well (except as archaeological relics).

-scott

Scott Walters on use.perl.org: Databases as a message passing back end

Thu, 31 Jan 2008 00:05:27 +0000

Beating this same horse some more. It isn't dead yet and I want it to die.

In the late 60's or so, MUD was created -- multiplayer computed text based adventure game. Brits dialed in, paying by the minute (some getting addicted, running up huge bills, and going to jail) to play live with other players. I don't remember what technology it was built on, but it's still the gold standard today -- the richest world, most dynamic environment, most complex play, best grammar parser, etc, etc.

It's popularity gave rise to a number of free clones, written essentially as free software (MUD and MUD II were not and are not free). One of the first ran on a GE mid-frame running GECOS. GECOS had no provision for IPC or for server processes, so each player got their own executable spawned. To communicate with other people's processes (and thus be multi-player), each process had to write out a file log of what that player was doing, and another program would read all of those files and write out files for each player of what the results of their commands were. It was IPC not through pipes but through files. It sucked. It was a terrible kludge.

Now we have Unix, and we have pretty solid IPC -- for programs running on one machine. If you make an app that runs on one machine, you can have great multi-user or multi-player capabilities. But that isn't "scalable". And in the late 1990s, we re-invented scalability. It now means that you have a database backend, and message passing is done over the database backend. Just like the MUD clone, the processes can't talk to each other except through this explicit read and write message passing system. It's so necessary that it actually feels good. Just like people adapting to Pascal's useless type system, successfully adhering to the discipline gives a rewarding feeling of accomplishment, and after a while, we forget that the discipline is ultimately pointless.

The irony is real scalability -- not the kind that novices learning to program during the dot com boom invented -- was largely created as a way of supporting extremely large databases that wouldn't fit on a mere two or four processor computer, or even all of the processors you could ram in one physical cabinet and be able to move the cabinet. So we're using database technology to scale applications, but we're not using the _real_ scalability technology that enabled databases themselves to scale, so our "scaled" applications only scale as far as a database on a dual processor, 8 core machine will scale.

Okay, a few places run Oracle or SQLServer for their database for web apps and do have database servers with hundreds of processors. That's another kicker. Microsoft get it right on this one but we web app programmers can't.

Here's the upshot. A good database server running on a good operating system will run the same application spread across hundreds of processors -- or even thousands. This technology exists. It's called "single image". OpenSSI is one implementation. It's been hacked onto Linux. Go use it. Write apps that store transient user information in RAM in a very large distributed machine and put persistent data in the database. Cache in RAM. Don't re-adapt your software architecture yet again to use memcached or other sorts of caching. Don't cache data locally on the server and have each server redundantly caching the same garbage. Cache it once on one large computer built out of all the smaller computers. OpenSSI is memcached -- for Linux.

-scott

Scott Walters on use.perl.org: My Perl Wishlist (Hint: Not Your Wishlist)

Fri, 25 Jan 2008 10:04:48 +0000

Perl 6 (as specified) exists as the sum of other people's wishes. Some of them are quite awesome. But here's what *I* want in Perl.

* I want to see the Perl grammar written in Perl. The optimizer has already been rewritten in Perl along with a means of plugging in additional optimizations (for fixing up the code to change it's semantics, inspect it for correctness, etc). Having the grammar in Perl will allow it too to be extensible.

* I want to see the various ops in the pp_*.c source files implemented in Perl. Educated readers will see where I'm going with this.

* I want to see a B::CC counterpart that works very, very well. Ops that store state in their own op structures will have to be modified to stop frickin' doing that in the spirit of ROMable code. That's .. and ..., at least.

At this point, Perl 5 is self hosting. Perl is written in Perl, and Perl compiles Perl down to machine code. This is important for a bunch of reasons. It's easier to modify and extend the language. Working in C is a PITA. Computers can do a better job optimizing large programs than humans have time or energy to. The interpreter would be retained, so programs can be run immediately or compiled and then run as a binary.

* Good static analysis done on the parse tree (which is the same as the bytecode tree) so that optimizations can be proved safe for the compiler. For example, a scalar could be proven to never hold anything but numbers, eliminating a lot of calls to pOK. Variables could be proven, in many cases, never to be tied, or having various other magic on them, eliminating large numbers of checks that are done on the variable before and during their uses in the present interpreter. Rather than inlining the contents of the pp_*.c definitions, a *subset* of the contents of the pp_*.c op definition could be inlined. There's no real win on compiling or JIT-ing until this kind of static analysis is done and it can be proven that large amounts of code can be omitted from the op definitions in specific cases.

* More and more Perl 6 is implemented on the magical, mythical self-hosting Perl 5. Perl 5 should slowly morph into a reasonable subset of Perl 6. XS back compat should be broken for cases where the macros can't be adapted to work, which is about any time magic or anything severe is used. Modules that depend heavily on the core do important things and would be moved to core -- autobox, Coro, Padwalker, etc.

-scott

Scott Walters on use.perl.org: What Perl is missing from AtariBASIC and LPC

Wed, 16 Jan 2008 05:27:06 +0000

I can't remember if I've talked about this already. If so, sorry.

In AtariBASIC, and probably other 8-bit BASICs, if the program encountered a fatal error (yes, there are fatal errors in BASIC, don't be daft), the program would stop, but it wouldn't abort. The code could be modified (by re-entering the code with the line number before it, thereby replacing the existing line) and then the program told to 'CONT'. And it would continue where it stopped. While it's stopped, you can do the usual REPL (read eval parse, whatever) stuff and print out variables and otherwise inspect or alter program state. And you can hit the 'BREAK' key, something like Control-C, at any time to interrupt it. This is a fantastic way to learn and experiment with algorithms, as well as to debug algorithmic code.

AtariBASIC was my first. 6502 assembly my next. Then LPC. LPC was the interpreted C language used by LPMud (Multi User Dungeon). A whole bunch of players would be running around, killing things, healing up, selling loot, trading stuff, stalking each other, etc, etc, while at the same time, other players who happened to be wizards were developing the game from the inside. They could call methods on objects to query or alter their state, and edit the code of the game. Quite often people would be standing around in a wizard's workroom gabbing while one or more were editing code, saving it, reloading the corresponding object, testing it, editing some more, etc. Editing in ed/ex (text mode, what came before vi) while people are gabbing, with code and prose mixed, was a challenge.

Both of these things are missing from Perl development.

I did a bunch of work on a zombie game (slowass.net is not stable despite my efforts and so the additional efforts there are sapping my strength). I can't just work a project through. I have to keep making it harder and harder for myself until I finally can't manage. I seem to be doing that with slowass.net. But I also did it with my zombie game, which I haven't touched in months, probably half of a year. I'm trying to bring the better parts of these elements to it.

I guess from the onset of the minizombies, I wanted to be able to teach people Perl like how I was taught LPC -- interactively, live, inside of a game. People looking at my code as I save it, talking to me, and having the code, upon command, reloaded into a live game for players to experience immediately. Code should be a social thing. It should also be an entertainment thing -- the wizards provide entertainment through their creations. It should foster creativity. People should be able to learn by example, modifying each other's code in simple ways at first. Programmers should take a 1st person role in an object universe, themselves represented by an object, their player body, with methods and mutators and accessors. They should be able to call methods in themselves and their friends (and enemies).

As for tech, there's a JavaScript implemented of vi stolen off the 'net, a file browser, and a button to reload code from disc. There's an eval box for immediately, directly manipulating the universe through method calls or reporting on its state. The whole universe gets serialized with Storable and written out to disc and reloaded upon server start. And of course, there's chat built in. It's Web based -- did I mention? No, I forgot that part. That'll never be as quick as a straight telnet connection, but oh well. As for stopping, atlering, and restarting code, I have Code::Splice and there's Cont. Gluing those two together should prove interesting...

-scott

Scott Walters on use.perl.org: Electronic Gaming (Gambling) perspective on E.Voting

Thu, 10 Jan 2008 21:48:42 +0000

Backstory: Years ago, Vegas gaming, or gambling, was run by the mob. They reported profits to the state, and the state taxed them, but not until they heavily skimmed off of the top. There was no transparency, only a set of nicely doctored books. Everyone knew this was happening but no one could prove it.

Eventually, the state got fed up. Gaming was big business, and they wanted their cut. Enough was enough.

There are a lot of places "gaming" is legal, especially electronic gaming. Vegas is only one of them. Almost all of them are regulated but none as heavily as Vegas. This has not put the industry of electronic game machine makers out of business. In fact, people continued to make games for outside of Vegas, but being certified for Vegas is a massive vote of confidence and that helps reassure your customer, whether he's Indian Gaming, in China, Central American, or off shore.

Now, let's talk about the regulations themselves.

Source code auditing:

E-Voting: Source code is not audited. Vegas: Source code is heavily audited and the device manufacturer pays for lab time for the state technicians. If you they're ever not satisfied with the security of some implementation, they have unlimited authority to make you jump through arbitrary hoops in the code to satisfy them.

Anti-tamper:

E-Voting: Inexpensive locks that can be defeated by bic pen cases are used with stickers. Vendors promise not to alter the code on the machines (that was never audited in the first place). Vegas: The code approved at the labs gets hashed and the size and hash of every file on the filesystem is recorded at the lab. Machines in the field are inspected to make sure that the size and hashes of the files have not changed. Any attempt to alter the code of a game on the casino floor carries a strong risk of detection.

Certification:

E-Voting: Vendors can make excuses to worm their way out. Multiple screw-ups are tolerated with nothing more than a vague promise to keep it from happening again through unspecified means. Time constraints are a valid excuse. Vegas: Swift, vengeful, kiss of death for any below board behavior. Time, money, and other excuses are meaningless.

Auditing:

E-Voting: Software written by the manufacturer prints off a total. This is taken as gosphel. Gaming: Every coin in, every pay out, every random number generated, periodicly, the seeds are logged so that Gaming can reconstruct the state of the random number generator through every step of game play should anything seem dubious. Data is not only accounted but examined statistically in spot checks.

Regulations in general:

E-Voting: fluffy. Vegas; Every time a machine is comprimised in any way, regulations are revised with multiple provisions in earnest effort to keep it from happening again. Through years and years of this, the regulations have become voluminous. It's extremely important to note that many times, Vegas gaming machines have been compromised, usually by inside jobs, but sometimes by well organized outside parties. PRNG prediction attacks have been mounted, extremely sophisticated timing attacks successfully executed, tiny probes with cameras and serial ports stuck through vents, and so on and so forth. Without thorough auditing and transparency, many of these attacks would have gone undetected and improvements to security never made. The unwillingness of the Federal Election Commission to audit is telling.

Computer security:

E-Voting: Removable flash storage that can contain autoexec.bats or otherwise automatically executed code. No encryption. No digital signing. Re-used passwords. Public ftp sites on the Internet where data is uploaded. Vendor personal are considered absolutely trusted. Vegas: Nothing in player is ever connected to the Internet at any point for even a moment. Physical separation is maintained, meaning sneakernets of flash dongles and CD-Rs are used during development (I assure you, this is a bigger pain than it sounds like). At numerous points, cryptographic singing, public/private key encryption, and other mechanisms are used. All openings of the cabinet are logged, along with the floor manager responsible and other data. Control systems have separate logging systems, required by law to be in separate rooms. Should the logging system go off line, the control system must boot all users and end all game related tasks within seconds. Both systems must be monitored by camera at all times with video footage archived indefinitely. In general, the requirements are designed such that no single personal would have any means available to them of tampering with the system. Multiple parties (the casino, the Gaming Commission, floor managers) are all able to independently validate the integrity of the systems.

Paper:

E-Voting: Paper vouchers are "too expensive". Gaming: Most casinos make heavy use of "paper in paper out", where rather than dispensing bills, the machines print coupons that can be inserted into another machine or cashed out at the pit. In the course of an evening, large numbers of these tickets might be generated for each player.

I'm sure I'll think of more later, or feel free to ask me about area of possible difference. I'll probably have something to say about it.

In short, though, it's disgusting to a dozen odd gaming companies get so many things so thoroughly right (and a few less than perfect, in my opinion, of course) while the two or three companies making electronic voting machines consistently get them wrong, and no one is held to count for it. The hubris is amazing. I don't think anything short of everyone taking up torches and pitchforks would motivate congress and the e-voting industry to raise their standards. Like so many broken things in government, they seem entirely too eager to keep things broken. Anyway, nothing that people have proposed -- cryptographic papertrail, auditing of votes, auditing of source code by trusted agencies, strong cryptography, physical tamper resistance, network isolation, logical tamper resistance, and so on and so forth -- can't be done and hasn't been done over and over. Someone with experience in the banking industry probably could make an equally scathing comparison. This is just disgusting. We've traded democracy away for some weak excuses from people who can't get security right but still somehow manage to claim to be experts.

-scott

Scott Walters on use.perl.org: CF-R1 drive crashed; should I buy a P1120 or fix the CF-28?

Wed, 02 Jan 2008 03:32:17 +0000

Appealing to group think, something that sometimes works here. I love my Panasonic Toughbook CF-R1. It's old enough that APM works, zippy at 800mhz, and tiny at two pounds. Plus it's kind of tough. No fan to clog, keys pop off and right back on for easy seaseme seed removal. But parts are a bitch, as are repairs. Replacement LCD panels cost $500, if you can find them, and I spent a week calling and requesting quotes to find that. It takes a funky 3.3volt only HD (with no 5volt connection required) but a lot of drives can be shoehorned in reportedly. This is the only machine that's survived being toted everywhere for more than a year. I have some that look like hell, with parts falling off all over and keys worn through. After years and years of use, it's little 20gig drive died. Yeah, I have most of the data backed up mostly recently. Never as good as it could be. Anyway...

I also have a CF-28 fully rugged Toughbook (like you often see in police cruisers) that needs a new backlight. It's easy to upgrade as parts are accessible. It also has two PCMCIA card slots (plus an extra hidden one) plus two mini-PCI slots. Battery life is pretty rotten even with the big battery. It's heavy. You could fit a Trojan army in its expansion bay and I'm not used to even having a CD-ROM drive so I don't see it as a real selling point. Of course, when I got this machine, I really wanted it, and my CF-R1 was laid up with a broken screen and I wanted something that wouldn't have that problem, but I missed my tiny CF-R1 and got it fixed anyway and abandoned the CF-28.

Or I could get a Fujitsu P1120 on eBay pretty inexpensively. Someone has them for $250. I should pick up one just to have it around. It's also two pounds, but at 2.5 pounds with the extended life battery, it'll run for a solid six hours, which is better than twice as good as the CF-R1. It's also 800mhz but it's a slower 800mhz with the Transmeta. Screen is smaller and less likely to break even if the CF-R1 does have paper thin magnesiam on the back of its screen. It takes normal drives. It has WiFi built in, freeying up the PCMCIA slot. Taking normal drives, I could easily adapt it to take solid state drives with an IDECF adapter. Someone even has a dual CF adapter that makes one the master and the other the slave (sorry, don't have the link, HD crashed). I could run software RAID on solid state drives -- w00t! And though it weighs as much as the CF-R1, it's physically smaller, making it more pocketable. I've been carrying an external battery for the CF-R1 to get more run-time. I'd carry another internal battery except that software suspend would lose my state.

So I could fix up the CF-28 Toughbook, fix up the CF-R1 (perhaps even with a larger drive), or I could buy the P1120. But I'm very low on funds.

Gah. I also need to put the money into a machine that I'm going to be happy with as my development environment, as it takes time I don't have to move everything, and I have quite a lot of software that isn't in any apt or rpm repository.

Thoughts?
-scott

Scott Walters on use.perl.org: All about blessed stash objects: better living through evil

Wed, 26 Dec 2007 01:34:47 +0000

Typically, when you write an object in Perl, you combine two disjunct things: data, as stored in a hash, and methods (code), stored in a package. bless makes this association. Any reference type can be blessed, but these references may only be blessed into a package. Here's the trick: packages are data types in Perl, one of the 15 odd types, and you can take a reference to them: \ %{"foo::}. This means that packages can be blessed into packages. This trick involves resurrecting some of the oldest datastructures in Perl, globs and stashes, for modern, OO purposes. A whole lot of fun ensues.

Okay, I'm going to stop calling packages packages; they're created with the package statement, but they're better known as a stash, or symbol table hash.

Like hashes, stashes contain data of various types, indexed by name. When you don't use my to declare your variables, variables are also stored in the package, as was the way in the olden days. Functions declared like sub foo { ... }, the common way, also get stored in the stash. Normal function calls and normal method calls (like foo() and $ob->foo, and unlike $hash{value}->()) all operate on stashes.

Newly constructed blessed stash objects are empty of methods. Code references get copied in, initializing them as a copy of another object's code. This is a "prototype based object system", as is JavaScript's. JavaScript objects are hashes, with the key being the method name and the value being code. Since each object has (indeed, is) it's very own stash, we can use define our methods in terms of closures.

Here's some code to create one of these puppies, and to create a method function that will neatly stick closures into the stash for you. This is old code I've posted before; sorry for the dup. I'm trying to turn this into a more accessible article.

sub new { # object setup (evil, run) my $type = shift; my %opts = @_; my $package = $type . sprintf '::X%09d', our $counter++; do { no strict 'refs'; push @{$package.'::ISA'}, $type; }; my $self = bless \%{$package.'::'}, $package; sub method ($&); do { no warnings 'redefine'; *method = sub ($&) { my $name = shift; *{"$package\::$name"} = shift; }; }; ... }

Then inside there, you can write methods like so:

my $arg; method foo => sub { my $self = shift; $arg++; $self->avast_ye(); };

$arg is a lexical variable that the method foo closes over. Each time new gets called, a new stash is created, and a new $arg gets created, and a new coderef attached to that new $arg gets created and rammed into that new stash. New everything, each go -- that's the trick.

When you write "package" in your code, you're defining a new stash. They also autovivicate (spontaneously spring into existence by their mere mention). That looks like %{"foo::"}. Yes, that's similar to a computed hash name (and also requires no strict 'refs') but the name ends in a double colon.

my $package = $type . sprintf '::X%09d', our $counter++; -- this computes a new package name based on the existing one plus a serial number.

do { no strict 'refs'; push @{$package.'::ISA'}, $type; }; -- this forces the new package to inherit from the base one, so that it in turn inherits what it inherits.

my $self = bless \%{$package.'::'}, $package; -- this creates the object as this new stash blessed into itself.

sub method ($&); do { no warnings 'redefine'; *method = sub ($&) { my $name = shift; *{"$package\::$name"} = shift; }; };

-- prototype the method function to take as args a scalar and code and define it was stuffing that code into the stash under the given name. That's the glob syntax. Stashes contain globs. Only references may be assigned into globs, and by assigning in a code reference, a new method is created.

Stashes a derivative of hashes, but rather than containing arbitrary types, they only contain typeglobs, which may in turn contain any other type. This way, you can both a $foo and a @foo, as a stash in turn can hold one of every other type.

Instance data is then hidden away in lexical variables where subclasses can't see it. That's not always what's desired. In a blessed hash, you could write $self->{foo} to get at a data item. Since stashes only contain globs, you'd have to instead write ${ $self->{foo} }. To access an array stored in a normal blessed hash, you'd write @{ $self->{foo} }, which is the same for blessed stashes. Everything is stored by reference, including scalars, in blessed stashes. Data::Alias can make this a lot easier:

use Data::Alias; method foo => sub { my $self = shift; alias my @foo = @{ $self->{foo} }; push @foo, @_; };

alias gives you fully read-write variables that are aliases to data stored in the object.

Data stored in $self is actually stored the same way that local data is stored. Only the syntax is different.

Before you get started, a few caveats: methods built out of closures (which access instance data simply as $foo rather than $self->{foo}) take a lot more memory than normal methods. Stashes don't get garbage collected at all; data stored in them is considered "global", and this data includes references to the closures and references to lexical variables. It probably contains circular references. You may think about writing a

DESTROY routine to tear everything down.

 

-scott

Scott Walters on use.perl.org: How I mismanaged Phoenix.PM into the ground

Thu, 20 Dec 2007 01:24:10 +0000

I've been writing for a while about the state of Phoenix.PM. This is the latest chapter. I wanted to give a talk on new stuff in Perl 5.10 as well as just have a general meeting. Some back story is near the end.

At one point, we had a lot of people just getting into Perl, people who were doing fun stuff with Perl on their own; people interested in what was going on in the community and in any techie Perl stuff even if they couldn't use it themselves; people who saw whole Perl careers ahead of themselves.

Then we stopped getting new Perl programmers, except for a light trickle. Then we only had people who wanted techniques they could apply to their daily work, which was mostly them being in over their heads trying to do some work in Perl or else accomplished Perl programmers doing uninteresting maintenance work who don't program for fun; now, thanks to my bumbling mismanagement, all that's left of the group is three guys that don't even actively use Perl and never really did that much anyway plus one who does actually work in it.

Granted, I didn't give much notice and it's the holiday season, but I actually caved and offered to give a presentation.

The current state isn't all my fault; a lot of Perl programmers were lost to C++ and whatnot when things got tight and the older, more stodgy industries were all that were left. When Python broke, a lot of Perl programmers decided that it suited their personality better, and they really wanted a break away from all of the not-so-clean they had been working on. A chance to write new code, from scratch, in a language whose culture valued cleanliness more than Perl's was a welcome change for them. Then PHP broke, and the snotty little brats that didn't think they should ever have to learn anything, just call routines from a library (nevermind algorithms, complexity management, security, or any of that), all pissed off and stopped coming to Phoenix.PM looking all glassy eyed all the complex (OMG!) things people were doing in Perl. Then Ruby struck, and their culture was filled with a hackish spirit that valued neat APIs, cool tricks, minimalistic design, and above all else, fun, something that we who had been doing predominately maintenance work in Perl for all too long could definitely appreciate.

So all we had left was Perl programmers who, for whatever reason, didn't defect from maintenance work in Perl, and some stragglers who attend meetings for reasons entirely unrelated to the content of the presentations or the Perl theme -- two of the three just attend a lot of technical meetings for technologies they don't actually use or use very, very little.

I tried a few things -- I wanted to virtualize the meetings, so that Perl programmers who were too busy to come to meetings or even post on the list could more easily keep in touch with each other and what other Perl programmers in Phoenix were doing, thinking that people would blog about stuff at work, their own take on technology, what they were doing, or even how their family was. Nope. Two people of the hundreds on the list had a blog and one I dug up Googling. He asked me to remove the reference to it as it was entirely off topic to programming. I ruffled a lot of feathers trying to get this idea to fly and in the end only alienated people more.

So I decided to have laser tag meetings, or try to get people out to ski, or just do something social. Again, no show.

In retrospect, the only meetings that would have gotten attendees would have been variations on "how to do small scale projects in Perl without learning very much at all" or "ways to more rapidly diagnose and troubleshoot problems in large hairy Perl programs and avoid having to do so in the future". In fact, I did one or two of those on subconscious instinct, and sure enough, that's what got people out.

Back Story:

Brock (Awwaiid) left town and left it to me. Being one of very few presenters, and presenting frequently, I've been a sort of second in command who assumed pumpkin by default. Towards the end, I was sick to death of only Brock and I giving the presentations. I like making little presentations, but it had turned into the Brock and Scott hour. So when Brock left, I started trying these various things to reinvent the group as something other than me sitting there talking to a small group of people, most of them who wouldn't be back because they didn't get anything they saw as immediately applicable to their work programming from the meeting.

No offense to the people that said they could make it; it's good that you wanted to come hang out with me and each other. But, from my point of view, not even the maintenance programmers

By the way, I'm not trying to convince anyone that Perl is dead; Phoenix is a special case. People here are apathetic and distant in general; anyone passionate about programming would be sorely tempted to move to silicon valley, Boston, or anywhere else, and those here that do have person interest all seem to be interested in moving somewhere else. Unless all you need to live is McDonalds, Home Depo, and so on, Phoenix is not for you.

-scott

Scott Walters on use.perl.org: Mini-helicopoter, bleah

Thu, 06 Dec 2007 22:05:54 +0000

There are a lot of these. This is the same that ThinkGeek seems to be selling. It has only one rotor but has a stabilizer that's slightly offset from the rotor and connected to it. For the past few days, I've been trying to learn how to fly this thing. Here's what I've learned.

Trim is essential. But don't bother with the trim. As the battery drains, which happens extremely rapidly, the trim completely changes. It'll start trying hard to spin to the right and then wind up spinning to the left. When it has juice, the main rotor has an abundance of power, but as it starts to get low, the tail rotor overpowers it. Keeping constant balance between the main rotor and tail rotor is essential to avoiding a spin. Control changes must be made slowly and gently and control made at all time or else, if it's moving, it'll start sliding back and forth or side to side on on a cousin of air, like an unstable parachutist. For about twenty seconds, it has juice and can lift off with ease (or very delicately if you want to avoid a spin), but for the entire twenty seconds, the controls and basic situation changes radically as the main rotor loses power and you move from pushing all the way right on the tail rotor to all the way left. After twenty seconds, it barely slides along the ground, not enough power left for the rotor to right it no matter how hard you push on the stick, tripping over any slight bump in the floor (forget having any rugs or the like on the ground), falling over, and gnashing its blades. So, it has enough juice for a two minute flight, as advertised, if you consider trashing around on the ground a flight.

Your heart might be glowing as you think, "wow, that must be just like a real helicopter! I want one! I want to learn how to fly a real helicopter!". No. Real helicopters do also require slow, gradual control changes, slightly disbalancing controls to affect an attitude change, then correcting them. They also have the power to do so. This thing does not. Real helicopters are capable of hovering. This thing is not. As far as pitch adjustments of the main rotors to maneuver any direction or stay in place, I don't expect that from a $30 toy, but a small amount of logic to either emit pulses to drive A/C motors or else regulate power to control the D/C motors so that the torque of the main blade and the tail rotor are balanced at all times would go far. Also, it needs more battery power, but regulated battery power. It burns like a roman candle, crazy for a brief, glorious few moments, then fizzles out. The problems of the toy so badly make it want to rotate one way or the other oblivious to control that for a while, I thought the thing was broken and the control didn't even do anything. It's own problems far outweigh the real problems of flying a helicopter. It's annoying the crap out of me. I *really* *really* want to learn to fly it. Grr! Guess I need to get a better one... oh, and it's insanely cute.

-scott

Scott Walters on use.perl.org: Sometimes I'm fine, sometimes I'm not

Wed, 05 Dec 2007 07:55:35 +0000

Strange hotels. B&Bs. Friend's apartments. It's remarkable how often I'm okay. And it's remarkable how often I'm not, even when I should be...

The poor neighborhoods aren't necessarily problematic and the rich neighborhoods aren't necessarily safe. Old places aren't necessarily bad either and new ones aren't necessarily good.

So many things can go wrong and it takes so little. And end table from a thrift store that was somewhere that was sprayed heavily, until it absorbed into the wood and now slowly off-gases. Neighbors across the street and a house over who come out with a can of RAID every day to try to chase ants away from the barbecue grease (futile; as long as there is food, there will be pests). Exterminators 30 years ago pumping the walls full of something that's extremely environmentally persistent and now banned (dozens of organophosphates have been banned, starting with DDT, yet they still keep making more, right to this present day; RAID and BlackFlag are primarily organophosphates with some others added).

So, a lot of thought goes into figuring out "where it's coming from". I do that insane-looking (and possibly insane-being) peering out the window a lot thing. If I hear a noise, I wonder if it's the exterminators and I have five minutes to run or else find myself in extreme pain. Or I wonder if the neighbors are out back spraying, and that's why I've been having problems lately. I'm not the only MCSS to struggle with trying to figure out whether I'd be better off with the windows open or closed. Airing a place out is often necessary (though as the outgasing continues, generally of temporary use), but timing it right is essential, or I'll wind up with a much stronger dose.

Then there's another tiring dilemma... when to call it quits on a place. Can I make it through the lunch I've ordered at a restaurant without making a fuss? That one truck stop that always pegs me hard, do I just refuse to go in? Should I even bother to try new coffee shops after having tried thirty and having three on my safe list? How much can I put up with in an apartment considering that breaking leases, awkward encounters, hunting, and the heartbreak of not having something work out also takes a large toll on me?

-scott

Scott Walters on use.perl.org: Moby Dick does not suck. But old media papers do.

Sat, 10 Nov 2007 05:11:59 +0000

Fountain Hills is a small burb outside of Phoenix. Scottsdale grew into it somewhat recently actually connecting it to the metro spraw. Fountain Hills Community Theather is our community theater. They're currently doing a one man version of Moby Dick. Some dumb bimbo wrote a review that seemed to entirely miss the point, that of the show being a one man Moby Dick:

http://www.azcentral.com/community/scottsdale/articles/1109sr-hoffman1109moby-ON .html

I posted a reply and duplicated it below the cut here. Let this be a lesson to dumb bimbos everywhere who think that you don't need any grasp of logic to write a theater.

---------------------------------------

The central premise seems to be that Fountain Hills Community Theater's rendidtion of Moby Dick stinks. Then the first argument to support this is, briefly, is that the book is a taxing read, and that the only situation in which it would be read is under a mixture of requirement and duress. This line of argument would suggest that any faithful performance of Moby Dick would be tedious, so it's confusing why FHCT's performance is singled out.

But I'm not just picking nits here. The basic questions I have while reading a review seem to be dodged. Another central argument against the the FHCT performance is that it lacks actor-to-actor dynamics, set changes, and so on. You're reviewing a one man play, and this performance is billed as such. There are well respected one-person plays that get good reviews, and those good reviews sometimes have the caveat of the dialogue being hammy at times, so what sets this one apart? It seems unfair to give poor marks to a one man play simply by virtue of it being a one man play. If I were a reviewer asked to review a one man play and I hated all one man plays, I'd at least disclose my bias. So, the question remains unanswered, for those of us who like a well done one man play, is this a good one?

Let me put it this way. I could look at the billboard outside of the theater and see that they're doing a one man Moby Dick and write this same review: it sucks because it's one man. It sucks because it's Moby Dick. The name of the directory and actor are published and could be referenced easily enough. If I were a little clever, I could guess that a few people couldn't stomach it for one reason or another and left at intermission. And that an old lady fell asleep at some point is a safe bet for almost any play. So, there's nothing in this review that gives me cause to think that you've actually seen the play. It seems like an amature hack job.

For the benefit of other people reading this review and associated commentary, I have seen this play, and my friends and I are passing this link around with some consternation. Here's an alternate review: the play is the story told from the perspective of Ishmael. There's one person on stage because an aged Ishmael is telling you the story as if during an encounter in a pub, but he, slowly at firsts, begins characterizing his shipmates. This is not a play where a smaller number of actors than characters attempt rapid changes to create an illusion of there being more actors, such as in Shakespear Abridged. It's simply one actor characterizing others in a story that he's acting the lead role in, and in my opinion, doing a fine job of it. The language is dense, the lighting dark, the ocean sounds hypnotic, and the tension slowly building. Regardless, the story is neither light nor cheerfully. Disney-ing it up with a fake whale and fanciful costumes would only detract from the story.

-scott

Scott Walters on use.perl.org: Unix-admin-fu Q's for the shared host/free shells business

Mon, 29 Oct 2007 21:25:29 +0000

Let's say I go the colo route and put slowass.net somewhere that costs money. After this background, there are technical questions.

I don't want to be in a position where I have a bad month and can't pay my hosting bill, as would often happen, and AdWords pays paltry amounts of dough. Tens of thousands of impressions of were coming in around a dollar -- no where near worth the annoyance to readers of the site. If I set up a free shells/shared host deal, there's potential of donations, which couldn't be any sadder than AdWords. silenceisdefeat.org has an on-line sign-up. You can mail them postal mail and get an account for the cost of the return stamp, but most people choose to PayPal a dollar on their online signup instead to get the account instantly. And of course, the little form suggests you donate and give them $5, $10, or $20 dollars instead. I gave them $10, just on a lark, but probably wouldn't have if I'd known they didn't permit CGI. They don't allow outside executables at all, either.

So, my question to the community is, how could one go about securing a machine in a similar, but more permissive arrangement?

Firewall rules could keep outgoing connections from contacting mail servers. Are there just too many things that would have to be blocked? Would I have to block all outgoing traffic like free shells often do? Most free shells prohibit IRC relays and IRC access except to small, designated IRC networks. Assuming I've collected a dollar from PayPal and therefore presumably could cooperate with the police on matters of abuse, would it be imprudent to allow these users access to IRC in general? I'm not versed in quotas -- how can CPU quotas be enforced? Duke University (no, wasn't a student) ran some AFS+Athena stuff. I'm fuzzy on this, but they were able to cap CPU usage per user in a far more useful way than ulimit's -t argument? Is there a way to cap what percent of the CPU a process uses rather than just how many CPU seconds it takes up? What else would be needed to be able to give people access to CGIs? What else needs to be done to set up shared hosting in general other than setting people's default umasks intelligently and running CGIs as the user? Would it be out of the question to allow people to run arbitrary binaries (ie, run without exec cookies)? And allow people access to gcc? What exactly would go wrong? It seems like if you're going to give people access to Perl, you might as well give them access to gcc. How are run-away processes normally handled if not through accounting -- just something that parses the output of top and kills as needed? What subtle aspects of shared hosting am I missing here?

Thanks,
-scott

Scott Walters on use.perl.org: Compute clouds are doomed, shared is dead, what's next?

Mon, 29 Oct 2007 16:58:15 +0000

kjones4 commented: "I have no answers, but I've been kicking around thoughts on hosting too. Have you considered Amazon's S3 + compute service? It looks to be reasonably cost effective and reliable, but I have no experience using it. The ISP business has changed a lot in the last 15 years. It used to be that I wouldn't hesitate to buy a couple of servers, deploy them in a data center, and manage everything myself. Now, it seems to make more sense to be a virtual ISP, where you buy services from people who know better about specific services such as backup, email, fail-over, etc. The problem is knowing if these 3rd party services are in fact more reliable and flexible enough to do the job. My brain hurts with the thought of researching all of this."

Hmm. First, nope, haven't seriously considered Amazon, or LoudCloud, or IBM's "compute as a service thing", or Sun's Grid. I guess I mentally lumped Amazon's things with the other "we have a giant computer, and we'll sell you some of it, and oh by the way, our computer is really big services".

That's what used to be imagined as the future, as far back was the late 1960s, when MULTICS was being written for just that purpose.

Oddly, I think hardware is being outsourced more (outsourced data centers, dedicated hosts, Xen slices/semi-dedicated host, etc). But the *software* is being outsourced less. People hate shared hosting. And those that don't should. The config is bizarre (SSL and plain http on different machines -- I've actually seen that), the systems aren't maintained, there are too many restrictions (can't daemonize apps, have to use a klunky GUI admin to do sysadmin tasks), etc. Shared hosting is ghetto hosting. The jobs of the sysadmin used to be keeping things secure, audited, updated, logs rotated, etc. All of those tasks have either been given up on or automated. Updates are cron job calls to apt-get. Log rotation is from cron and people stopped reading logs a long time ago. I doubt criminals even bother to cover their tracks any more when they penetrate a system, or if they do, it's just to hide themselves from automated break in audit tools. Since the sysadmin is now redundant, mostly fascilities of the operating system, people want to pick their OS. They want to the freedom to pick FreeBSD, Slackware, Ubuntu, CentOS, or whatever for their host. Things like slicehost, where you get your own Xen slice, are profilerating rapidly. There are hundreds of them now.

I don't mean to pretend I wasn't or am not seriously considering shared hosting, but the question of Amazon's and these other "compute cloud" services that came out recently is kind of interesting.

What is their market? A bunch of little guys? They don't do much in the way of support, and the setup is pretty technical.

Big guys? They hate not controlling their own datacenter, or at least racks in a datacenter. Even companies that have a whole bunch of machines at a colo will have their own little datacenter in the office, too. And it's not just for generic compute cycles: there are Windows/x86 machines for domain controllers and all too often, ExchangeServer (ewwwch). Novell servers -- NetWare, I mean. And so on. All of this could be moved to generic compute clusters, but it would require switching products, doing countless "upgrades", and homogonizing things. Hell, IBM must have an ulterior motive of trying to sell their compute cloud in just getting you locked in to AIX by making you switch to AIX software and replacing your database, CRM, etc, etc. Their TV ads are pretty adamant that everything will run there. And every few days, they issue a press release telling you how much power you can save by replacing all of your computers with a big IBM one that's faster than all of them put together. Similar for Sun. As far as I'm concerned, any restriction which keeps the idiot suits at the top from buying and running whatever stupid piece of software they want, is a doomed proposition.

-scott

Scott Walters on use.perl.org: Thinking outloud about consolidating servers and data

Thu, 25 Oct 2007 10:25:41 +0000

Sorry, this is becoming a frequent topic post by me.

I need to get off the home DSL line I'm on. That's part of another story.

I hate x86 hardware. It's nothing but fan failures, thermal failures, and blown caps. But for lack of options, I have to soften up on some hatreds. Let's just say that slowass.net has been through a dozen machines. All of the RISC hardware still runs and none of the various x86 machines, except the original 486, does.

Colo in town starts at $40/month. That's a hell of a deal.

My old RISC hardware is old and slow and takes SCSI drives, which are expensive. My largest drive is a 70 gigger, and it's a half-height drive (all of the drives you see today are third height or quarter height or God knows what, but this drive is a tank). I only have one, and it's in production. I'd rather have two.

Having only the one that's in production, I don't want to move the 32 bit OpenBSD install off, put 64 bit OpenBSD on it and put in the UltraSparc. Too much down time. On the other hand, if I got a root drive set up on a smaller drive and just shoved it in as the /home partition, it could be quick and painless. Hmm.

NetBSD completely hosed the 32 bit Sparc platform. Server processes reliably and quickly wedge in an interruptible kernel state, requiring a reboot to free up the port they're listening on. Likewise, OpenBSD on 32 bit Sparc gets very little attention and as such has serious stability problems. So a move to Ultra-Sparc (64 bit) might improve stability. Or it might not.

I also found some SCSI-IDE adapters (active logic) but since I'd be putting the concoction in the CD-ROM drive bay, I could only fit one. The SCA drive bays only fit exactly one SCA drive.

Regardless, after a lot of time and effort, I don't have a stable machine to colocate.

I have users who are already weary of moves. I'd like to keep running OpenBSD to minimize impact to them.

I have a desktop system with a larg-ish harddrive in it, a 320gigger. I'd like to go to just having the laptop and a server and lose the desktop, and combine storage. Most of the stuff on it I'd rather have online anyway -- mp3s to share with friends, video, etc.

There are these virtual server things now, based on Xen. OpenBSD doesn't yet support Xen. Work has been done, but I don't know how stable it is yet. They tend to be conservative.

Virtual servers are more affordable than colocating real servers if you don't care about storage. If you care about storage, it suddenly becomes prohibitive.

Possible solutions:

Move everyone to Slackware Linux on a shared host and just have a lot of content not be online.

Buy some cheap x86 hardware and colocate it, with some cheap, large IDE/SATA drives.

Cross my fingers and hope OpenBSD/sparc64 is a hell of a lot more stable than OpenBSD/sparc and colocate the Ultra 1 with the one big SCSI drive in it, and also hope that the drive doesn't melt down.

Give up on having users and move onto a shared host deal.

I'm singularly ineffectual at thinking, as past performance so painfully illustrates, and am badly in need of thoughts from external sources. Thoughts?

-scott

Planet Phoenix.PM

Brock's The Lack Thereof: TLT - 2008.01.02 - Events vs Actions in UI Code

Brock's The Lack Thereof: TLT - 2008.03.30 - Making Music

Andrew Johnson's Transformed Planet: Children of Jihad: A Young American's Travels Among the Youth of the Middle East

Andrew Johnson's Transformed Planet: Resolutions

Scott Walters and friends on Twitter: scrottie: @tweetscan Please add search of tweet plus tweeter's location, w/ feeds. Eg, Perl in Phoenix, for http://phoenix.pm.org/planet/index.html

Scott Walters and friends on Twitter: scrottie: NG: bug doesn't seem to be in wincheck. Diffed new vs antique. Now to check rest of slots logic. Argh.

Phoenix Ruby User's Group: [ANN] April 23: Refactor Phoenix Meeting

Perl Community News: PAUSE gets a CAcert signed certificate tomorrow

Perl Community News: Perl 6 Design Minutes for 16 April 2008

Perl Community News: mod_perl-2.0.4 finally, it's here.

Perl Community News: YAPC::SA::2008, April 17-19 in Porto Alegre

Perl Community News: YAPC::NA 2008 Registration Open

Perl Community News: LA.pm Tech Meeting @ Oversee.net, this Thursday!

Perl Community News: YAPC::NA 2008 Registration Open

Perl Community News: Act Hackathon planned next week

Perl Community News: Parrot 0.6.1 "Bird of Paradise" Released

Perl Community News: NPW 2008 - Website online and registration is open

Phoenix Ruby User's Group: April Phoenix Rails Meeting

Scott Walters on use.perl.org: To maintences programmers, all languages are the same

Scott Walters on use.perl.org: what twitter-land is saying about Perl

PhxBSD User's Group: PhxBUG April Fool's Meeting

Scott Walters on use.perl.org: How to be productive at work, not yer papa's version

Scott Walters on use.perl.org: Offtopic: Women.

Scott Walters on use.perl.org: Still pondering hosting: open SSILinux cluster?

Scott Walters on use.perl.org: scrottie's guide to Phoenix

Scott Walters on use.perl.org: Go save your half.com wishlist *now* before they delete it

Scott Walters on use.perl.org: MCS (certain chemicals make me stupid) update

Scott Walters on use.perl.org: Catalyst Book Review... that I need to write

PhxBSD User's Group: PhxBUG Meeting - Beer & BSD

Scott Walters on use.perl.org: Programming Perl, except s/P/6, s/e/5/, s/r/0/, s/l/2/.

Scott Walters on use.perl.org: Databases as a message passing back end

Scott Walters on use.perl.org: *My* Perl Wishlist (Hint: Not Your Wishlist)

Scott Walters on use.perl.org: What Perl is missing from AtariBASIC and LPC

Scott Walters on use.perl.org: Electronic Gaming (Gambling) perspective on E.Voting

Scott Walters on use.perl.org: CF-R1 drive crashed; should I buy a P1120 or fix the CF-28?

Scott Walters on use.perl.org: All about blessed stash objects: better living through evil

Scott Walters on use.perl.org: How I mismanaged Phoenix.PM into the ground

Scott Walters on use.perl.org: Mini-helicopoter, bleah

Scott Walters on use.perl.org: Sometimes I'm fine, sometimes I'm not

Scott Walters on use.perl.org: Moby Dick *does* *not* suck. But old media papers do.

Scott Walters on use.perl.org: Unix-admin-fu Q's for the shared host/free shells business

Scott Walters on use.perl.org: Compute clouds are doomed, shared is dead, what's next?

Scott Walters on use.perl.org: Thinking outloud about consolidating servers and data

Scott Walters on use.perl.org: Go save your half.com wishlist now before they delete it

Scott Walters on use.perl.org: My Perl Wishlist (Hint: Not Your Wishlist)

Scott Walters on use.perl.org: Moby Dick does not suck. But old media papers do.