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.
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.