sometimes I also have the feeling that these services are somewhat extortionist. I find this to be the case when they really don't help you in any way to track down the spam they think you're sending.

some of these are helpful and provide sample spam e-mails that they caught. usually the message ID is enough for me to track down the spam and spammer in question.

why such an organization would actually _not help_ fighting spam in this way is beyond me though.

if you're aim is to go for fast 3D, your range of choice is narrowed down to either ATI or nVidia. and, nVidias drivers are the better one.

yes, they are closed source, etc., but still they work.

no open source driver for these cards produces a sufficient level of performance. and, they lack a lot of features that are important for laptops. for example, the open source ATI drivers doesn't scale the GPU clock, which means your GPU will run at 100% all the time, your battery will get drained with it real fast (and your GPU fan will be spinning constantly)

then again, your goal might be different, and you're may not be focused on 3D

But obviously not the first SMS sent ever.

SMS was developed by Ericsson. Their initial use case was to be able to send out service notifications to phone users (e.g. text messages about technical issues of the phone service, billing info, etc.). the first phones that supported SMS actually couldn't *send* SMS messages - just receive & display them!

I wish slashdot would be more prudent when selecting stories.

this doesn't change anything unless the cameras are always on, and the public can see all recordings at will.

if not so, the recordings will only be used when it is favorable for the police, but not the other way around

Slackware on floppies at first, with the letter-coded floppy sets

then I went for RedHat, on CDs

then Gentoo, emerge away!

and now I use Ubuntu, though I still don't really like apt

er, wrong link, see here: http://en.wikipedia.org/wiki/Mindszenty#Confinement_at_the_US_embassy

wonder how they don't recognize it now..

for example in 1956, the US granted political asylum to cardinal Mindszenty at their embassy in Budapest, Hungary: http://www.youtube.com/watch?v=Yu1TZVX72Aw&t=4m9s

the UI from the Japanese anime Serial Experiments Lain

http://www.imdb.com/title/tt0500092/

the only way to make this work is to treat the outsourcing partner as part of your team. this means you have to develop full trust in the beginning of your working relationship. this trust will be the basis of your working together. this is the most risky part of such a relationship.

initially you can start with giving them a smaller task, which doesn't require too much internal knowledge. as you see how they progress, and how the two teams (yours and them) can productively work together, you can increase your level of commitment to them, as will they do the same. in a manner of months, you can ramp up the amount of work you give them, and they will allocate more people of their team to you. if it doesn't work out, you just cut the relationship and look for someone else.

as trust builds up, you don't have issues anymore of sharing your assets with the outsourcing team. you also don't have accountability issues, like double-checking their timesheets, etc. this also means that efficiency increases. trust really saves money for everyone.

in an ideal setup, you'll end up with a long-term partner, that is at least as good as what you could get in-house. they will also appreciate this long-term and stable relationship. the benefit will be there for both: you'll get a capable team that is cheaper than what you'd have in-house, and is at least as good. you'll also have more flexibility in the amount of load you place on them. you also don't have to worry about recruitment, training, etc. they will love the long-term and stable customer they are working for. they will enjoy the challenges you give them. and most probably they will make more money than what they could make with a local client.

also note that outsourcing is not always about price, although price is always part of the equation. but its useless to go just for price - as you pretty much get what you pay for. but, you can also aim for an external development partner that is high quality, and not 'dirt cheap', but indeed, cheaper than a comparable high quality in-house team, or a team where you live.

(disclaimer: I run such an outsourcing company in East Europe, and we work for US customers on a long-term, high-quality basis)

we have the same problem here - and this is the only reason we have to fire up a VM with a Photoshop on it when we receive such files :(

for us, this is the single biggest issue with gimp: it can't open PSD files which contain layers, properly...

I wonder if this will be added anytime soon...

the biggest obstacle for us with Gimp now is that it doesn't open PSD layers properly. whenever we receive a PSD file from a designer, which includes layers, we have to open a virtual machine with Photoshop in it to just to open it properly.

but I don't see PSD layer support in the new features list - I wonder when gimp will support this?

yes, this was how the whole thing started - that they got an incorrect airspeed indication, and thus the autopilot disengaged. after a short while, the speed indication was correct again. unfortunately, human errors added up starting from there.

although I would argue that the first mistake that they made was to fly into the storm, which every one else navigated around at that time. in aviation, you have to have at least 3 mistakes in a row to have an accident - here, flying into the storm, the frozen airspace indicator and then human error.

this is not how multi-crew cockpits (MCC) work - in these cases, both pilots have control. as said earlier, they can agree on only one of them giving direct inputs though.

this is all covered by CRM - Crew Resource Management - where the two pilots divide the tasks & responsibilities between them. both being young pilots (remember, the captain was sleeping at the time), they pretty much failed in applying proper CRM techniques. both were used to being the junior member of a multi-crew cockpit, thus neither of them took the initiative. this is quite evident from the transcript.

this is simply not true - adding feedback is neither expensive nor heavy in this case.

in my opinion the biggest issue was that the pilots weren't aware of the huge angle of attack (AOA) that they were maintaining, and AFAIK they didn't have an AOA indicator in the cockpit. it was also dark and in a big storm, thus there were no external references.

they had the plane pitched up about 10 degrees, which is not that big. they also had speed - they were close, but not below stall speed. but at the same time they were falling badly, which meant their angle of attack on the wing leading edge was at least 30 degrees if not more.

remember that the basic reason of a stall is always high AOA - not speed, not pitch, but high AOA.

of course, you 'should' be able to put it together - high pitch, large negative vertical speed -> high AOA. it seems the young co-pilot didn't. :(