RMS's idea predates the latest bank bailout era with many many years. his idea was not inspired by 'too big to fail' at all. his idea is simple a mechanism to make sure there are fewer big companies - and only in cases where a larger size is indeed increasingly profitable, so that it's still worth to have the larger organization which has to pay more taxes because of its size.
RMS's experience is simply that 'large entities' don't behave in a 'good' manner, and thus there is a clear advantage to society of having fewer of them.
it's not how MIT acted, but the copyright law, that's what they should investigate. like how come someone can be threatened with 35 years in prison and a $1m fine for making state-funded research papers accessible to people at large?
for killing a person, you only get 4 years.
yeah, for killing Micheal Jackson, you get less than for distributing one song of his 'illegaly'
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
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.
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)
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.
Only the pilot in command should have his hand on the stick; so linking the two together wouldn't have any of the problems you raise. It would, though, give valuable visual (and tactile if both pilots are trying to control the stick) information to the co-pilot.
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.
There is one reason and one reason alone Airbus didn't link the sticks - and that's cost (both in higher building costs and extra weight).
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.:(
while the co-pilots behaviour of pulling on the stick for minutes, and not recognizing the very simple stall-recovery process of pushing & gaining speed is, well, astonishing - there is a reason for his behaviour.
the reason is that such planes usually encounter stall-warnings on approach, when in a landing configuration, close to ground, and having a lot of excess power. in such occasions, the usual procedure is not to lower the nose & convert altitude to speed, but to simply 'power yourself out' of the stall situation - apply a lot of (available excess) power, and your speed will pick up, and you're not close to stalling anymore.
the fact that the co-pilot in question referred to TOGA (the Take-Off-Go-Around procedure) in the transcript, and the fact that they were using maximum thrust for most of the falling time also suggest that his idea of stall recovery was to power himself out of the stall.
this is quite unfortunate indeed, as any small-plane pilots instinct would have been simply to dip the plane's nose & recover easily.
the thing with the Airbus control system is that you issue 'change' commands to the plane. you issue a 'roll command' when you push the stick to the side, and you issue a 'G command' when you push it forward or back. the plane will remain in the new commanded state until commanded otherwise.
(now read the last sentence again, and chew on it, make sure you understand it thoroughly)
thus, the usual way to fly the plane is to issue small, well-intentioned commands, not to pull on a stick for minutes, as one of the pilots here did. and the plane will stay in the new situation. 'will stay' means that it will issue corrections on its own to maintain the commanded attitude. for example, after having been issued a roll command for a few degrees, the plane will stay in that attitude even of there are disturbing factors - say, turbulence. (as a result, in such a case it is an error for a pilot to try to manually compensate for turbulence-induced attitude changes, as the plane does it on its own anyway, and he will end up over-compensating)
all-in-all, this is a big change in the philosophy on how to fly a plane, even when flying alone, when compared to a 'legacy' system of direct physical coupling of control instruments to control surfaces.
as for simultaneous inputs: actually, one of the pilots can 'take over' command of the plane, and shut out the other one, if he so chooses. none of the pilots did this on this occasion. when having multiple inputs, the plane does signal that the other person is entering inputs as well (at least visually, maybe there is also an aural indication). although, as pointed out, there is no physical feedback on the stick that would signal the other pilots inputs. when both are entering commands, their commands are 'added together'. thus a full pull & a full push on the stick will cancel each other out. two 'small' pushes will results a 'big' push. this makes sense, so that either pilot can 'adjust' the planes behaviour in addition to what is already happening.
the point of not having physical feedback is to reduce strain on the pilots. this way, the stick is always centered, and when moving off center, the pilot knows he's issuing commands to the plane. if it was not so, the pilot wouldn't be sure in which state of the stick is it in a 'neutral' position.
I hope the above gives some background to the story.
Slashdot Mirror
why isn't the SWAT team in jail as well? they killed an unarmed man for no reason.
without any substantiation of the main claim
wonder how this got through the /. content selection process
access to unfiltered information will make people THINK!
who would have thought? :)
starting with a full pardon, medals, Nobel peace prize et al
he should be appointed to oversee the NSA & the like, so that they stop overreaching as they do now
at least we know Snowden is a person how won't step aside on these issues
and they are still making computers...
other then the slug exited the barrel, I wonder if they could aim this thing over any usable distance, and hit the target with it?
http://www.alaveteli.org/ is an open source FOIA tool, that can be localized for any country. it's operating on an EU level, and in many EU countries, including UK, Hungary, etc. for an English language adaptation, see: http://www.whatdotheyknow.com/ or http://www.asktheeu.org/
RMS's idea predates the latest bank bailout era with many many years. his idea was not inspired by 'too big to fail' at all. his idea is simple a mechanism to make sure there are fewer big companies - and only in cases where a larger size is indeed increasingly profitable, so that it's still worth to have the larger organization which has to pay more taxes because of its size.
RMS's experience is simply that 'large entities' don't behave in a 'good' manner, and thus there is a clear advantage to society of having fewer of them.
it's not how MIT acted, but the copyright law, that's what they should investigate. like how come someone can be threatened with 35 years in prison and a $1m fine for making state-funded research papers accessible to people at large?
for killing a person, you only get 4 years.
yeah, for killing Micheal Jackson, you get less than for distributing one song of his 'illegaly'
this has to stop.
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 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.
Only the pilot in command should have his hand on the stick; so linking the two together wouldn't have any of the problems you raise. It would, though, give valuable visual (and tactile if both pilots are trying to control the stick) information to the co-pilot.
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.
There is one reason and one reason alone Airbus didn't link the sticks - and that's cost (both in higher building costs and extra weight).
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. :(
while the co-pilots behaviour of pulling on the stick for minutes, and not recognizing the very simple stall-recovery process of pushing & gaining speed is, well, astonishing - there is a reason for his behaviour.
the reason is that such planes usually encounter stall-warnings on approach, when in a landing configuration, close to ground, and having a lot of excess power. in such occasions, the usual procedure is not to lower the nose & convert altitude to speed, but to simply 'power yourself out' of the stall situation - apply a lot of (available excess) power, and your speed will pick up, and you're not close to stalling anymore.
the fact that the co-pilot in question referred to TOGA (the Take-Off-Go-Around procedure) in the transcript, and the fact that they were using maximum thrust for most of the falling time also suggest that his idea of stall recovery was to power himself out of the stall.
this is quite unfortunate indeed, as any small-plane pilots instinct would have been simply to dip the plane's nose & recover easily.
the thing with the Airbus control system is that you issue 'change' commands to the plane. you issue a 'roll command' when you push the stick to the side, and you issue a 'G command' when you push it forward or back. the plane will remain in the new commanded state until commanded otherwise.
(now read the last sentence again, and chew on it, make sure you understand it thoroughly)
thus, the usual way to fly the plane is to issue small, well-intentioned commands, not to pull on a stick for minutes, as one of the pilots here did. and the plane will stay in the new situation. 'will stay' means that it will issue corrections on its own to maintain the commanded attitude. for example, after having been issued a roll command for a few degrees, the plane will stay in that attitude even of there are disturbing factors - say, turbulence. (as a result, in such a case it is an error for a pilot to try to manually compensate for turbulence-induced attitude changes, as the plane does it on its own anyway, and he will end up over-compensating)
all-in-all, this is a big change in the philosophy on how to fly a plane, even when flying alone, when compared to a 'legacy' system of direct physical coupling of control instruments to control surfaces.
as for simultaneous inputs: actually, one of the pilots can 'take over' command of the plane, and shut out the other one, if he so chooses. none of the pilots did this on this occasion. when having multiple inputs, the plane does signal that the other person is entering inputs as well (at least visually, maybe there is also an aural indication). although, as pointed out, there is no physical feedback on the stick that would signal the other pilots inputs. when both are entering commands, their commands are 'added together'. thus a full pull & a full push on the stick will cancel each other out. two 'small' pushes will results a 'big' push. this makes sense, so that either pilot can 'adjust' the planes behaviour in addition to what is already happening.
the point of not having physical feedback is to reduce strain on the pilots. this way, the stick is always centered, and when moving off center, the pilot knows he's issuing commands to the plane. if it was not so, the pilot wouldn't be sure in which state of the stick is it in a 'neutral' position.
I hope the above gives some background to the story.