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.
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.
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.
Well it'd be up to the user then. They'll get to see the questionnaire of each person who wants the domain...So if the user wants to give his domain to Landing Pages, INC instead of Blind Hungry Crippled Orphans Charity that's up to them.
+ You can let the user make their own questionnaire ...so they can make their questions be as relevant as they want. i.e. lets say you own something like newyorkjetsftw.com, you'd ask some questions that only a true Jets fan would know or someone who'd want to spend the 10 minutes hunting down the information
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.
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.
At least in the case of SimpleDB, replaying requests is usually not a problem -- if you Put or Delete an attribute which has already been Put or Deleted, it has no effect.
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.
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
State-free protocols are useful when the server side is distributed and potentially disconnected. :-)
As for "wonderful heisenbugs" -- the AWS services return a clear "hey, your clock is broken" error, so it wouldn't be very hard to developers to figure out what was going on.
Plenty of well-regarded crypto protocols use timestamps to prevent replay. The nonce isn't a panacea; you have any number of design pitfalls to deal with when trying to secure a message with a random number, too.
It would still be an interesting project. Especially if it were a generic MapReduce type thing.
It's crazy to think how much power a major site like Google could harness if they actually did this. If I were them I'd do it, but make it opt-in, of course.
If it weren't for the same origin policy they could make a distributed web crawler that loads web pages, parses them, and returns a nice clean list of words and links for the real heavy duty processing. They would need some assurances that clients didn't tamper with the data. Perhaps several clients could process the same pages, and they could ensure they match before accepting the data.
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.
I would have said the exact contrary oppinion... C++ is a horrid and butcherous hack that should have died and let objective C take over the world...
Of course I'm exagerating a bit... but objective c feels a lot cleaner to me than C++
Well, I think the real issue is that C++, C, and Objective C are all bad.
If you want OOP, slapping it on top of assembly language isn't a great idea. Use CL or Smalltalk instead; or any of the dynamic languages. Those are much closer to being good than anything in the C family.
Check out MacRuby, which is Ruby implemented on top of the Objective-C runtime: http://www.macruby.org/
The key difference between this and other "bridges" is Ruby classes are implemented as Objective-C classes. This couldn't have been done if Objective-C weren't as dynamic as it is. Objective-C is basically Ruby in C's clothing (which leads to a very different "feel", but in terms of "dynamicism" they're approximately the same).
And "slapping it on top of assembly language"? I'm not sure what that has to do with anything. C compilers are usually written in C. V8 (Chrome's JavaScript engine) generates machine code. What exactly is your argument?
You consider those three languages bad compared to Lisp/Smalltalk, without asking why C and C++ were vastly more popular.
I see your point about OOP, by the way: I don't think I really got C until I learned assembly language, and then it all fell into place.
Looking only at language aesthetics, Lisp/Smalltalk are excellent at OOP. We now have the benefit of computers that are insanely fast by the standards of the history of computing.
Go back a decade, and you want to get the best performance for a system by taking that awareness of the underlying assembly code. If you're dealing with pointers and structs then you can write sections of your program that you know will convert to a handful of assembly instructions.
You do have a point: trying to do OOP in a fancy version of assembly language is not going to be as seamless as a language with different core concepts. There are some ugly weld marks in C++ and ObjC, although I have come to appreciate the ObjC design approach after some time with it.
I just think it is meaningless to talk about good or bad languages without reference to the goals of the programmer.
I rather like it. The problem is this: make a language that is a strict extension of C and has Smalltalk-style OO.
It's not a bad problem to solve and Objective-C does a nice job. The syntax is odd, but it's to clearly separate the Objective-C parts from the C parts.
C++ on the other hand mushes the syntax together. It might look more C-esque, but it's less dynamic and more difficult to maintain as your project grows, IMO.
Obj-C, unlike C++, is a strict superset of C. All C code works in Obj-C (bar the new keywords), unlike with C++. I really think you're missing the point here. Apart from the controversial syntax, Objective-C's elegance sets it apart from C++ more than anything else. Objects and classes are really C structs. It's all introspectable, and it's all admirably simple (2.0 additions aside).
C++ is a convoluted, over-wrought solution to a problem which Objective-C solved with minimal additions to C. And Cocoa is leagues ahead of anything you have in C++.
