Facial recognition technology at scale is what worries me. I feel most people have the same basic concern although we may disagree on the scale where the problem starts.
Deploying this technology to gate keep against people who have or have threatened to hurt/kidnap/kill/etc someone that is going to be the center of attention at an event I don't see an issue with. To me that is a focused proactive attempt to prevent a situation balanced with that persons desire to continue on as normal as possible.
Now you start throwing in everyone who has a warrant in the city/county/state/country/world I get concerned.
As you load up more and more faces it is far too easy to abuse the system. And it is far too tempting of a system to abuse.
We developers get tunnel vision. We "know" how the system works. How it is supposed to work. So we don't do the stupid things users do. Even if the QA person is just another developer tasked with QA it's better than just the single pair of eyes on it.
QA departments are usually separate because they pay QA less than full developers. That is the real business reason they are separate. We are paying X/hr for these guys to test this crap? Can't we get some people at 60% of that to test while they work on the next feature?
However you could easily treat QA like any other project. Team X does feature A. Team Y does QA for feature A. Next cycle teams swap roles for the next feature.
The problem with that is you head down a rabbit hole fast.
If a security researcher writes a proof of concept exploit code that is then incorporated into malware is the security researcher now an accomplice?
What about the old Backorifice tool? It could be used for good or evil.
What about openssl? openssl can be used to encrypt the command and control communication for malware.
Or even windows iteself. Between windows and visual studio you have everything you need to write, distribute and run malware. Therefore is everyone involved in writing windows, Visual Studio, etc an accomplice?
I know personally in my 23 years of development everywhere I have worked women have been a rather small percentage of the developer workforce. But I have not noticed any significant difference in the distribution of quality. I have met really good devs and really bad devs regardless of gender.
I would want to look at the complexity of the code in question before judging why there were more comments/changes.
More complex code will generate more comments. There will be more ideas on how to solve the problem. There will be more requests for documenting the tricky portions of the algorithm, etc.
Since the code is the secret sauce we will never get to see the CRs and comments involved to judge for ourselves why the difference was there.
Unfortunately I am not surprised. But it's not an India specific problem. I interview people from all over and end up rejecting very high percentages of them. Where they come from (school, country, degree level, etc) has so little to do with how well people do that I just ignore all that. You can either think a problem through and code up a solution or you can't.
I would really love to take their test. Knowing what they ask and how well I got graded on it would definitely help me judge if this test has any chance of accurately measuring skill.
I don't believe in God because I have never seen any evidence I will accept that he exists.
I don't believe in human caused climate change because I have never seen any evidence I will accept that humans are causing this.
In both cases the consequences if your wrong are rather unfortunate.
My biggest concern is by the time the last holdouts believe humans caused global warming we will be left with an uninhabitable desert planet with oceans devoid of any life. Putting "I told you this would happen." on your gravestone isn't very satisfying. If the conversation would turn to this is going badly, what can we do to improve the situation then we might avoid that.. Or at least delay it.
On geological time scales you are correct the planet is not doomed. Killing off the humans would probably be the best thing for the planet long term.
There isn't going to be a magic wand for this. But a multifaceted approach would help.
1) Standards body to oversee the software and protocols.
2) Standard IOT base software stacks and protocols. Ideally run as an open source style project with companies encouraged to give back to the software stacks. Maybe protection from being sued for security problems found if they are using the certified software stacks. i.e. we were using the certified software stack in a certified way is a valid legal defense. If your modifications are the problem you lose that protection. Makes getting your modifications into the base stacks very appealing to the lawyers, etc.
3) Certification program that takes completed devices and runs them through tests. Penetration tests of the completed devices. Manual and automated review of the software. Should be easy to fast track the software reviews if your building on top of one of the approved IOT base software stacks.
4) Require a way to easily update the software of the devices. The reality is forced updates are going to have to be required because most won't manually update the devices.
5) Require that a fully functional software stack be put in escrow for each device and revision of software. The company must provide support for the device or the the software base is released. Lack of support for the device is decided by standards board not the company. Fully functional means that someone can take the stack, compile it and successfully install it on the device. No hidden BS boot encryption keys that are missing, etc. If there are encryption keys like that then they have to be put in escrow with the rest of the software stack.
6) Media campaign to get people to buy only certified IOT devices.
Probably plenty more things that are good ideas/best practices. But this would be a start.
I'm surprised they can find anyone who would claim to be a Hacker to work with them.
Low pay. Poor track record sticking to the letter of the law, let alone the spirit of the law. Do illegal things and hide them behind national security.
To me it is no different than the scientists that won't work on weapons technology for the military.
We can't trust them to use that kind of power responsibly at any level (local, state, or federal law enforcement). The proper checks and balances are just not there.
No it isn't. If it was, then people would stick to discussing the code and personal insults would not be there. Telling someone they're "deepthroating microsoft" is not a comment on the quality of the code and it's not about merit or lack thereof. It's a personal attack.
Actually I would say that is calling bullshit on hidden agendas. From my reading of the situation Linus found it as offensive as when I see the RIAA/MPAA writing legislation for legislators who submit it as their own.
Now if the discussion had gone into his parentage and how many farm animals were involved that would be personal.
See how there's nothing in there about being very thick skinned? To be a long term Linux contributor you have to have merit and be very thick skinned. We know this because people with sufficient merit get fed up with the system and leave.
There is nothing there about having to coddle to the thin skinned either. Or a duty to be non offensive in the so many ways people get offended these days.
All the snide comments in the world won't make you correct.
You may consider it a snide comment but it's the truth. Why haven't all of these people with sufficient merit put their weight behind a fork of the kernel? There is nothing stopping a fork from being successful other than a lack of people with sufficient merit backing it.
LKML is only about the merits of the code you submit.. They don't care if your white, black, male, female, lesbian, bi, gay, transgendered, etc. This includes not caring if your the nicest person in the world, or an asshole.
If you want to build your own meritocracy that wants high coding standards as well as politically correct sanitized language in all discussions feel free. There is nothing standing in the way of creating your vision of Open Source Utopia.
Part of the LKML meritocracy is the ability to deal with assholes criticizing you. It doesn't make it less of a meritocracy. However it sounds like it is a meritocracy you don't want to deal with.
In the real world there are assholes that stand in your way and you have to find a way to deal with them.
Creating a walled garden and not letting the assholes in is one way to deal with it. And perhaps that is what this fork will create. Time will tell.
Yes two have fallen, others will take their place.
If your going to contribute at such a highly visible level as the LKML you better be able to defend your design decisions and code. If harsh criticism will damage your fragile ego then you shouldn't be there.
Don't worry there are plenty of smart people out there that can and will defend their design decisions and code through the harsh criticism.
Netflix paid company A to move X trucks across the road. Consumers paid company B to receive Y trucks to their house.
It is between company A and B to sort out what they will pay between each other. If the cost is too high for company A they are free to pass the increased cost onto Netflix.
Just like NetFlix is free to go to company C to get a better deal.
To put this into a more concrete absurdity.. Let's say you have a gated community with an HOA. Guard shack, the whole works. The HOA could pass a rule that in order for any packages from Amazon to be delivered Amazon must pay $10 per package to the HOA. It is their road they are using. They can't get it unless they go by the guardshack, etc. Just as absurd as Netflix paying the consumers ISP to get their internet traffic delivered.
Unfortunately this isn't a huge shock to me. Back in the 90's I remember trying to hook up a fortune 500 company to the internet. They were using public IPs on their internal network.. They complained when I told them they had to readdress their network.. I even dug up the various RFCs, who owned the public blocks they were using, etc.
There was actually a discussion along the lines of will we ever need to communicate with those companies? i.e. can we just ignore the problem.. In the end the argument that those places using public IPs wouldn't be able to communicate properly with the reset of the network got things going in the right direction..
I know where I work we have quite a few open heads for competent C++ or Java devs.
However most fail at the interview stage.. They can't describe data structures they claim to know.. They can't implement some pretty basic problems in a working manner.. They can't decompose a problem into a workable design.
It's fairly rare that we get older people on the interviews.. But the few I have interviewed they tended to fall short in data structures or coding.. They could usually decompose the problem into a workable design.
My guess is that older workers end up in psuedo manager positions.. They design and tell all the underlings what to do.. They spend so much time designing and answering questions from above and below that their dev skills get rusty. When they find themselves looking they don't brush up those rusty skills.. And of course no one ever tells you why they are saying no after the interview.
-Jerry PS: If you looking for a job Amazon in Seattle is definitely hiring:)
I don't think anyone in the Patriot Guard Riders would object to widening the scope to include kids funerals the WBC protest.
I know I have to agree with the general sentiment.. There are some lines you just don't cross. Picketing a 6yo's funeral is a few hundred miles beyond that line.
Try RTFA: >Not this phone. It sat by the cash register unclaimed all the next day. “I don’t know anything about this stuff, but I know enough to know this phone was different.”
So the phone sat in the bar for a day and then they tried to figure out who owned it. Sounds pretty reasonable to me.
Somebody made a phone call with a voice distorter and threatened someone. That phone call came from your house. Should you be arrested and thrown in jail because of that? Or do they have to prove it was you that made the phone call?
We do own the contents of deployment but not the mechanics of deployment. That means we setup software into packages the deployment system can consume. We identify what set of packages goes into an environment. We choose which environments go on which hosts. The actual deployment is kicked off via a web UI. The merchanics of the deployment then worry about copying the data over and running the deployment scripts.
If something goes wrong with the automated system it is someone elses problem. However if something goes wrong with the scripts in the package we are deploying it is the devs problem.
I've been in companies that practiced it both ways.
Company A) Developers can never ever access production no matter the reason. The end result in that situation was bugs that couldn't be reproduced on the desktop or in the QA environment. The problems went on for months until I had a lucky break of a developer moving jobs into the system admin role of the production environment. When he looked things over he discovered the previous admin had not configured things in production properly. To the point of lying about it when I had sent a previous check list of things to verify. If I had access to the systems the problem would have been resolved in a few days rather than months.
Company B) Developers own the software and hardware from end to end. In my current company we have to package the software up into a deployment system and deploy it that way. However we do have full access to all the systems. Can/do we do hacks and quick fixes? Yes, if the situation warrants it. But in the end it has to get rolled into the official distribution for it to be correct. Can it be abused? Yes. But that is why the culture of the company become very important. In the end you either trust your developers to do the right thing or you don't. If the company can't trust the developers to have ownership of their code and systems.. Well then at least for me I would say I'm working at the wrong company.
FYI, I enjoy working at company B far more than I ever did at company A. Given a choice I will never go back to an environment where developers don't have access to production.
On the C64 you had to move the ROM out of the way to get to the RAM underneath. I don't remember the exact details but you could either see the RAM or the ROM and it was controllable.
If you want to get into memory expanders the C64 had at least a 512K ram expander available. I remember having one and it worked with GEOS at least.. might have been used as a form of ram drive to speed up games as well.
The drive drive was a computer in itself that you could buy ram expanders for and run programs on. Typically used for increasing load speed or duplicating copy protected disks.
He is the Chairman of the Board and was representing the company during the annual shareholders meeting. That doesn't fit the whole he doesn't really work there anymore statement.
When he isn't on the board and isn't representing the company at the shareholders meetings I'll believe he doesn't work there anymore.
You hit the nail on the head. The primary reason for that is once you have someone hired it is exceedingly hard to get rid of them. You only have to be burned badly once before you only want excellent candidates instead of good enough candidates.
What's that? The malware/trojan/root kit installed it's own root-certs and is running a proxy listening on 127.0.0.1:80 and 127.0.0.1:443? That proxy is snarfing up all the data and shipping it off to some other server...
Just because you can't imagine how it could be abused doesn't mean it can't be abused.
Slashdot Mirror
Facial recognition technology at scale is what worries me. I feel most people have the same basic concern although we may disagree on the scale where the problem starts.
Deploying this technology to gate keep against people who have or have threatened to hurt/kidnap/kill/etc someone that is going to be the center of attention at an event I don't see an issue with. To me that is a focused proactive attempt to prevent a situation balanced with that persons desire to continue on as normal as possible.
Now you start throwing in everyone who has a warrant in the city/county/state/country/world I get concerned.
As you load up more and more faces it is far too easy to abuse the system. And it is far too tempting of a system to abuse.
Exactly right IMO.
We developers get tunnel vision. We "know" how the system works. How it is supposed to work. So we don't do the stupid things users do.
Even if the QA person is just another developer tasked with QA it's better than just the single pair of eyes on it.
QA departments are usually separate because they pay QA less than full developers. That is the real business reason they are separate.
We are paying X/hr for these guys to test this crap? Can't we get some people at 60% of that to test while they work on the next feature?
However you could easily treat QA like any other project. Team X does feature A. Team Y does QA for feature A. Next cycle teams swap roles for the next feature.
The problem with that is you head down a rabbit hole fast.
If a security researcher writes a proof of concept exploit code that is then incorporated into malware is the security researcher now an accomplice?
What about the old Backorifice tool? It could be used for good or evil.
What about openssl? openssl can be used to encrypt the command and control communication for malware.
Or even windows iteself. Between windows and visual studio you have everything you need to write, distribute and run malware. Therefore is everyone involved in writing windows, Visual Studio, etc an accomplice?
I know personally in my 23 years of development everywhere I have worked women have been a rather small percentage of the developer workforce.
But I have not noticed any significant difference in the distribution of quality. I have met really good devs and really bad devs regardless of gender.
I would want to look at the complexity of the code in question before judging why there were more comments/changes.
More complex code will generate more comments. There will be more ideas on how to solve the problem. There will be more requests for documenting the tricky portions of the algorithm, etc.
Since the code is the secret sauce we will never get to see the CRs and comments involved to judge for ourselves why the difference was there.
Unfortunately I am not surprised. But it's not an India specific problem. I interview people from all over and end up rejecting very high percentages of them.
Where they come from (school, country, degree level, etc) has so little to do with how well people do that I just ignore all that. You can either think a problem through and code up a solution or you can't.
I would really love to take their test. Knowing what they ask and how well I got graded on it would definitely help me judge if this test has any chance of accurately measuring skill.
It's funny the climate deniers are like atheists:
I don't believe in God because I have never seen any evidence I will accept that he exists.
I don't believe in human caused climate change because I have never seen any evidence I will accept that humans are causing this.
In both cases the consequences if your wrong are rather unfortunate.
My biggest concern is by the time the last holdouts believe humans caused global warming we will be left with an uninhabitable desert planet with oceans devoid of any life.
Putting "I told you this would happen." on your gravestone isn't very satisfying.
If the conversation would turn to this is going badly, what can we do to improve the situation then we might avoid that.. Or at least delay it.
On geological time scales you are correct the planet is not doomed. Killing off the humans would probably be the best thing for the planet long term.
There isn't going to be a magic wand for this. But a multifaceted approach would help.
1) Standards body to oversee the software and protocols.
2) Standard IOT base software stacks and protocols. Ideally run as an open source style project with companies encouraged to give back to the software stacks. Maybe protection from being sued for security problems found if they are using the certified software stacks. i.e. we were using the certified software stack in a certified way is a valid legal defense. If your modifications are the problem you lose that protection. Makes getting your modifications into the base stacks very appealing to the lawyers, etc.
3) Certification program that takes completed devices and runs them through tests. Penetration tests of the completed devices. Manual and automated review of the software. Should be easy to fast track the software reviews if your building on top of one of the approved IOT base software stacks.
4) Require a way to easily update the software of the devices. The reality is forced updates are going to have to be required because most won't manually update the devices.
5) Require that a fully functional software stack be put in escrow for each device and revision of software. The company must provide support for the device or the the software base is released. Lack of support for the device is decided by standards board not the company. Fully functional means that someone can take the stack, compile it and successfully install it on the device. No hidden BS boot encryption keys that are missing, etc. If there are encryption keys like that then they have to be put in escrow with the rest of the software stack.
6) Media campaign to get people to buy only certified IOT devices.
Probably plenty more things that are good ideas/best practices. But this would be a start.
Would that matter?
I'm surprised they can find anyone who would claim to be a Hacker to work with them.
Low pay.
Poor track record sticking to the letter of the law, let alone the spirit of the law.
Do illegal things and hide them behind national security.
To me it is no different than the scientists that won't work on weapons technology for the military.
We can't trust them to use that kind of power responsibly at any level (local, state, or federal law enforcement).
The proper checks and balances are just not there.
No it isn't. If it was, then people would stick to discussing the code and personal insults would not be there. Telling someone they're "deepthroating microsoft" is not a comment on the quality of the code and it's not about merit or lack thereof. It's a personal attack.
Actually I would say that is calling bullshit on hidden agendas. From my reading of the situation Linus found it as offensive as when I see the RIAA/MPAA writing legislation for legislators who submit it as their own.
Now if the discussion had gone into his parentage and how many farm animals were involved that would be personal.
See how there's nothing in there about being very thick skinned? To be a long term Linux contributor you have to have merit and be very thick skinned. We know this because people with sufficient merit get fed up with the system and leave.
There is nothing there about having to coddle to the thin skinned either. Or a duty to be non offensive in the so many ways people get offended these days.
All the snide comments in the world won't make you correct.
You may consider it a snide comment but it's the truth. Why haven't all of these people with sufficient merit put their weight behind a fork of the kernel?
There is nothing stopping a fork from being successful other than a lack of people with sufficient merit backing it.
The two are completely orthogonal.
LKML is only about the merits of the code you submit.. They don't care if your white, black, male, female, lesbian, bi, gay, transgendered, etc. This includes not caring if your the nicest person in the world, or an asshole.
If you want to build your own meritocracy that wants high coding standards as well as politically correct sanitized language in all discussions feel free.
There is nothing standing in the way of creating your vision of Open Source Utopia.
Part of the LKML meritocracy is the ability to deal with assholes criticizing you. It doesn't make it less of a meritocracy. However it sounds like it is a meritocracy you don't want to deal with.
In the real world there are assholes that stand in your way and you have to find a way to deal with them.
Creating a walled garden and not letting the assholes in is one way to deal with it. And perhaps that is what this fork will create. Time will tell.
Yes two have fallen, others will take their place.
If your going to contribute at such a highly visible level as the LKML you better be able to defend your design decisions and code. If harsh criticism will damage your fragile ego then you shouldn't be there.
Don't worry there are plenty of smart people out there that can and will defend their design decisions and code through the harsh criticism.
Okay let's say it is a road.
Netflix paid company A to move X trucks across the road.
Consumers paid company B to receive Y trucks to their house.
It is between company A and B to sort out what they will pay between each other.
If the cost is too high for company A they are free to pass the increased cost onto Netflix.
Just like NetFlix is free to go to company C to get a better deal.
To put this into a more concrete absurdity.. Let's say you have a gated community with an HOA. Guard shack, the whole works.
The HOA could pass a rule that in order for any packages from Amazon to be delivered Amazon must pay $10 per package to the HOA.
It is their road they are using. They can't get it unless they go by the guardshack, etc.
Just as absurd as Netflix paying the consumers ISP to get their internet traffic delivered.
Unfortunately this isn't a huge shock to me. Back in the 90's I remember trying to hook up a fortune 500 company to the internet. They were using public IPs on their internal network.. They complained when I told them they had to readdress their network.. I even dug up the various RFCs, who owned the public blocks they were using, etc.
There was actually a discussion along the lines of will we ever need to communicate with those companies? i.e. can we just ignore the problem.. In the end the argument that those places using public IPs wouldn't be able to communicate properly with the reset of the network got things going in the right direction..
I know where I work we have quite a few open heads for competent C++ or Java devs.
However most fail at the interview stage.. They can't describe data structures they claim to know.. They can't implement some pretty basic problems in a working manner.. They can't decompose a problem into a workable design.
It's fairly rare that we get older people on the interviews.. But the few I have interviewed they tended to fall short in data structures or coding.. They could usually decompose the problem into a workable design.
My guess is that older workers end up in psuedo manager positions.. They design and tell all the underlings what to do.. They spend so much time designing and answering questions from above and below that their dev skills get rusty. When they find themselves looking they don't brush up those rusty skills.. And of course no one ever tells you why they are saying no after the interview.
-Jerry :)
PS: If you looking for a job Amazon in Seattle is definitely hiring
I don't think anyone in the Patriot Guard Riders would object to widening the scope to include kids funerals the WBC protest.
I know I have to agree with the general sentiment.. There are some lines you just don't cross. Picketing a 6yo's funeral is a few hundred miles beyond that line.
Try RTFA:
>Not this phone. It sat by the cash register unclaimed all the next day. “I don’t know anything about this stuff, but I know enough to know this phone was different.”
So the phone sat in the bar for a day and then they tried to figure out who owned it. Sounds pretty reasonable to me.
A better parallel is a phone number.
Somebody made a phone call with a voice distorter and threatened someone.
That phone call came from your house. Should you be arrested and thrown in jail because of that?
Or do they have to prove it was you that made the phone call?
We do own the contents of deployment but not the mechanics of deployment. That means we setup software into packages the deployment system can consume. We identify what set of packages goes into an environment. We choose which environments go on which hosts. The actual deployment is kicked off via a web UI.
The merchanics of the deployment then worry about copying the data over and running the deployment scripts.
If something goes wrong with the automated system it is someone elses problem. However if something goes wrong with the scripts in the package we are deploying it is the devs problem.
I've been in companies that practiced it both ways.
Company A) Developers can never ever access production no matter the reason. The end result in that situation was bugs that couldn't be reproduced on the desktop or in the QA environment. The problems went on for months until I had a lucky break of a developer moving jobs into the system admin role of the production environment. When he looked things over he discovered the previous admin had not configured things in production properly. To the point of lying about it when I had sent a previous check list of things to verify. If I had access to the systems the problem would have been resolved in a few days rather than months.
Company B) Developers own the software and hardware from end to end. In my current company we have to package the software up into a deployment system and deploy it that way. However we do have full access to all the systems. Can/do we do hacks and quick fixes? Yes, if the situation warrants it. But in the end it has to get rolled into the official distribution for it to be correct. Can it be abused? Yes. But that is why the culture of the company become very important. In the end you either trust your developers to do the right thing or you don't. If the company can't trust the developers to have ownership of their code and systems.. Well then at least for me I would say I'm working at the wrong company.
FYI, I enjoy working at company B far more than I ever did at company A. Given a choice I will never go back to an environment where developers don't have access to production.
On the C64 you had to move the ROM out of the way to get to the RAM underneath. I don't remember the exact details but you could either see the RAM or the ROM and it was controllable.
If you want to get into memory expanders the C64 had at least a 512K ram expander available. I remember having one and it worked with GEOS at least.. might have been used as a form of ram drive to speed up games as well.
The drive drive was a computer in itself that you could buy ram expanders for and run programs on. Typically used for increasing load speed or duplicating copy protected disks.
You do realize the Kindle reads PDFs as well.
I have a Kindle Keyboard (Wi-Fi) and all I have to do is copy the PDF over into the documents folder via the USB cable.
He is the Chairman of the Board and was representing the company during the annual shareholders meeting.
That doesn't fit the whole he doesn't really work there anymore statement.
When he isn't on the board and isn't representing the company at the shareholders meetings I'll believe he doesn't work there anymore.
You hit the nail on the head. The primary reason for that is once you have someone hired it is exceedingly hard to get rid of them. You only have to be burned badly once before you only want excellent candidates instead of good enough candidates.
Yes because that couldn't be exploited at all..
What's that? The malware/trojan/root kit installed it's own root-certs and is running a proxy listening on 127.0.0.1:80 and 127.0.0.1:443?
That proxy is snarfing up all the data and shipping it off to some other server...
Just because you can't imagine how it could be abused doesn't mean it can't be abused.