jamess

Read K&R, a large part of the book is given over to writing a simple allocator. There really isn't an awful lot to understand if you're treating the hardware as a black box.

Wouldn't they just pay some Chinese sweat shop a dollar a throw or something? If they're saving money on registration fees, I don't see how making it a little awkward will deter them.

Very good idea, I'd sooner give away a domain name to someone who was going to use it than let some blasted domain parking business get hold of it.

On the other hand, I have no idea how you'd stop domain parkers from actually using the service to get domains for free. With freecycle itself, it's probably quite hard to hide that you're abusing it to make cash on ebay or something, but I don't know how you'd prevent that with non-physical goods.

I have an eeepc, but you couldn't do any serious amount of work on it. I'm not so concerned about the horsepower (if your software is so bloated it doesn't run at speed on an eeepc, which is way faster than my main development machine was only 4-5 years ago, you're doing it wrong.)

The main problem is the screen real estate and keyboard size. I just can't type at speed on the eee, I keep hitting all the wrong keys and it gets very frustrating. It's fine for the odd email, but no way could I crank out the code on it. The screen is also too small. My main laptop has a nice widescreen where I typically have 2/3rds IDE and 1/3rd documentation/consoles. Not possible on 7-8" screens.

Yep. Worse still, he's wrong even on that small point.

I'm working on Delay Tolerant Networking for mobile phones, mostly for deployment in isolated communities in the developed world. Mobile phones are everything OLPC strives to be, cheap, portable, power optimised, connected and hackable. Better still, they do all this now. They're already available in any country in the world, manufactured in extreme volume, we don't have to wait for some philanthropist's wet dream to bear fruit.

Any of the software I write could be trivially repurposed to suit the needs of the third world. Then people could get the benefit of access to modern information networks without necessarily having to have all the modern infrastructure in place first.

Hey, I've got a crazy idea. Instead of a completely unsupported, fantasy standard "smart link" you could instead offer a link to a vcal file, or vcard file, or a location XML file. Then every damn computer and mobile device in the world would be able to do something useful with the data, right now not in some magical fantasy future.

My bookshelf has been all fiction for about 6 years now. Technical books are more or less obsolete, the only ones I can remember buying in all that time is the Samba administrators guide from O'Reilly (useless.) and Stuart Cheshire's Zeroconf book (delightfully written, I could read it for pleasure but no help at all in really getting to grips with Zeroconf from an implementer's point of view.)

I still have some classics which I refer to from time to time. The camel book in particular, since there exists no better reference to Perl's core APIs. However, for anything else the web is a far better reference library.

Is this one of the ways you're looking to "monetise the internet", begging? Shameless. Even assuming this isn't pure scam, three words: Get a job. Flagged.

Ew! They use the timestamp parameter for that? That's both sick and wrong. Requiring people who access your webservice to have an accurate clock is the most braindead thing I've heard this month, at least. Oh boy, network congestion and clock skew could combine to produce some wonderful heisenbugs for developers. And for what? The want of nonce? Some ridiculous design principle of making your API totally state free. sigh

Sorry, but you aren't thinking like a security professional here. Consider the case, e.g., where you create a domain, delete it and recreate it. An attacker monitoring the deletion can with impunity wipe out your data at a later date.

Does it worry anyone else that there seems to be no protection provided against replaying any particular authenticated request? If I were using this service, I'd heavily recommend restricting non-https requests to read-only operations. Any updates or deletes should be done using a security protocol proofed against replay attacks, like HTTPS.

Hah, blast. Just when you think you have an interesting new idea... Certainly not using google gears would be a good idea, though.

Personally, I think Objective C is a horrid and butcherous hack that really ought to have died when C++ was standardised. Trying to make C in to some kind of bastard and retarded cousin of smalltalk was never a good idea.

Well, from a personal perspective, trade shows are a great place to meet people. If you go to niche trade shows year after year, you get to know the other people who go. I've made some good friends in the trade press who have really helped me out in the past.

You can. XServe is essentially a vanity purchase, and no company in their right mind would buy them. They're about twice as expensive as the same box from Dell.

Generally, this sort of thing isn't worthwhile unless the liabilities you're exposed to by being broken are in excess of about $10M. Anything less than that, and it's a job for a butch insurance policy.

If you're reasonably confident that you've got a decent security model, and you've coded it defensively you're probably OK. I wouldn't stress about it too much at this point.

Oh, OK. The number I was looking for something close to had a couple more zeros on the end of it, I'm afraid. A decent code audit will take about a quarter of the time it took to write the code and its accompanying tests, and is an extremely specialised job. I'm not sure I can recommend anything in that sort of price range.

What is it you're actually wanting audited, and what is at stake if it turns out to be broken?

What sort of price are you looking to pay? I've written a lot of secure software in the past, and I may well be able to recommend a couple of firms who have done a similar job for me but I'm afraid they don't come terribly cheap.

Ha! A wonderful example of why we have laws regarding unfair contract terms. I can't believe they found a lawyer either ignorant or optimistic enough to put this in. The remedy is out of all proportion with the injury (which, as far as I can tell is non-existent) so the contract is unenforceable.

Being involved somewhat in DTN, I'm here to tell you that the RFC 5050 bundle protocol is a steaming pile of crap. It desperately needs updating to stop trading off minuscule numbers of bytes saved in transmission for ridiculous pain in actually parsing and storing bundles. Oh, and the security drafts. Don't get me started on the security drafts. DTN is nowhere near a mature and well formed technology yet.

So, if you're not sure how you feel about unions what have you done as an individual to improve your pay and how has it worked out? If they're saying no to the union, I'm guessing either you've done nothing or if you did ask for more money yourself, they simply laughed at you.

Given that, if you choose to cross the picket line, what you're saying to your employer is that you're happy with your pay which you say is not the case. You're also making the statement that you either think your co-workers who will be striking are either malcontents or greedy, unless you know they're getting significantly less money that you for the same job.

Your decision is simply whether or not you believe your and co-worker's current compensation is fair, or if the deal the union is proposing better represents your market value.

Not this Britisher. The only way I can stand to drink tea is the Indian way, stewed and with half a ton of sugar in.

Does it annoy anyone else when people say operating system, when they mean user interface or window manager? You'd think after a year or so covering the industry, they'd get their terminology straight.

By having a landing page that isn't just a giant map. You need to explain what your site does. As it is, I suspect most of your visitors will arrive and depart almost immediately.

Not precisely a web app per se, but a product I'd really like to see someone produce. It seems to me that the BBC's iPlayer sets the standard for TV stations broadcasting their content over the internet. They have flash streaming at reasonable quality, plus various species of download for different platforms including portable devices, and they don't discriminate a huge amount by operating system.

What I think would be wonderful would be if someone would produce a similar system packaged up and ready to be installed at any TV station. Just add a few racks of machines for encoding. Hell, if you were going for real shiny-shiny, you might even do the encoding "in the cloud" on EC2 or somesuch.

I'm not entirely sure how much money you could make doing this, but its certainly an idea.

There is one and only one such mechanism that exists, reverse-billed SMS. Even then, the fees payable will often amount to some 25% of the total. What are you going to be selling? If its something you are expecting lots of repeat custom, then you could do as all the music vendors do and aggregate bills over some period of time. Or, if that is a bit too risky sounding for you, have customers charge their accounts up with credit first before shopping.

I was going to go with 99% of the time they never generate enough revenue to cover their costs, but each to their own I suppose.

Yes, I'm afraid you are. SOAP is out of control. You can tell how bad it is getting since it was originally named "Simple" which even back in the day was a misnomer. The fact that all mention or pretence of it being simple has gone out the window is symptom.

Here's a particularly egregious example of a SOAP structure I'm familiar with but I must stress I did not design:

<?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <MarkLastPhotoInRollResponse xmlns="http://localhost/api/soap/eyefilm" /> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

That's what? More than a hundred bytes of data to encode what can only be described as one byte of payload? Insanity.

REST has some good points to make. There's a lot of importance in not trying to impose excess state in applications that are primarily going to be used over HTTP talking to traditional web servers. However, the best thing about REST is that it doesn't say _anything_ about how the data ought to be encoded.

Of course people can abuse this by using pointless and stupid formats like JSON, but hey if you don't want your application to have reasonable performance, it isn't my problem.

Those of us who still have to worry about CPU cycles and RAM and the cost bandwidth realise that you can define data formats that have useful properties like streamability, that is to say you can define parsers with the semantics /Either read this structure now if you have enough data, or call me back when you do have enough so I can parse it then./ A property I consider paramount in any asynchronous application that uses the network, but is completely lacking in XML. That also gives you the option to skip structures without parsing them, which is helpful. Then there are issues like widths of integers, which people are inclined to forget about when using modern scripting languages. Of course, this all comes back to bite people when they try to use a horrid language like PHP which secretly actually has a fixed width for its integers, but neglects to tell you what it is and has no syntax that lets you choose to be signed or unsigned. sigh

Click to focus is not (historically, at least) the only focus model nor necessarily even the best. It used to be the case that most environment used focus follows mouse. My personal preference for focus scheme is focus follows mouse, click to raise since raising the window under the mouse can get irritating.

If you use various linux window managers you get to customise your focus model.

I use the same password (OK, two passwords, one high strengh, one disposable) and have a bookmarklet that hashes the password with the site's base URL. Works well for me.