And that certification should disallow actions like FTDI took. If a self-certifier fails to follow the rules, they should have to, in the future, go through an outside party from an 'approved certifier list' to get certification. Certifiers on the 'approved certifier list' who fail to follow the rules would be banned forever from being certifiers and forfeit a bond.
Microsoft is the agent pushing this crap to your machine under their moniker, therefore they have significant responsibility for the content. Microsoft is really hurting themselves by allowing this to go on -- esp. when this specific company had previously proven themselves to be untrustworthy.
I can see why FTDI has done this -- although I would rather they would track down the board builders who use the fake chips and those that sell their boards and sue them.
However, I'm trying to figure out what Microsoft's interest in pushing this. Did they just not test this case (surely, after the last time, they should be testing this)? Accepting such drivers will just discourage people from 'auto updating' and they seem bent on encouraging that behavior, not discouraging it.
(Although, in my case, Microsoft had already managed to get me to stop taking updates as I got tired of having to carefully check each one to see if it was another undocumented driveby update to nag me to upgrade to Windows 10 from 8.1).
When I really don't want to vote for any listed candidate (using paper absentee ballots), I overvote -- I just vote for everyone for that office. This prevents anyone from altering my ballot before it is counted so it appears I voted for a specific candidate. No, I'm not paranoid.
How many decades should the U.S. let the office of President remain unfilled even though there's a Presidential election every two weeks? Or, would the current President/Vice President just get to rule for decades even though everyone hates them (and they were disqualified from running again on the first ballot decades earlier because 'none of the above' won).
How would that make any sense? The second place candidate can be VERY unpopular in a lopsided election.
If a universally popular Presidential candidate got 99.9% of the popular vote, and the second place candidate (a serial pedophile) got 0.1% of the vote (having cornered the pedophile vote, the anti-establishment vote, and the "unable to mark ballot correctly" vote), why should someone that less than 1 in 1000 voters wanted as President be one heartbeat away from becoming the President?
No one (including police and military personnel) ever "needs" a gun. Just as they don't "need" fluids or food or medical care. However, in all cases, the consequence of not have a gun, fluids, food, or medical care may be death. So, I think you need to define "need".
Here, however, are a few instances (well more than the number of fingers on one of your hands, assuming that you're human and have a normal anatomy) where guns were quite useful to those that had them.
A qualified person has to review every bit of the video and redact as needed.
When an officer enters your home and has the bodycam on, it's nobody's business what's in your home unless it's part of a criminal investigation (vs. just a fishing expedition by reporter or by a thief casing houses with the help of the police video). If a child rape victim is being interviewed in the field, the audio and video of that interaction should not be made available "just for the asking" (except, as necessary, as part of a criminal case or, perhaps, a complaint by an involved party about how the interaction was handled) for pedophiles to jerk off to. If police respond to a domestic violence call and the wife has locked herself in a utility closet and is naked, when she comes out and the bodycam captures her state of undress, that's not something that should be released for every perv on the internet to post to porn sites. The list goes on and on.
If the request is not for a specific officer at a specific time but for something like "All video showing interactions between Latino officers and African American residents between 12/1/2015 00:00 and 1/1/2016 00:00", careful examination of the material is required and someone qualified to make a judgement call on if a resident is "African American" or not.
Getting the video is the easy part, vetting it is the hard and expensive part.
Without specifics of the request and what type of review was needed, it's hard to know if the charge is unreasonable. It does sound a little high to me, but it might be perfectly reasonable.
However, police must be consulted and have input into the process. How would a third party,without consultation with police, know that a particular person talking to a police officer (perhaps just by their clothing or stature et al even if the face is obscured) could cause that person to be identified (rightfully or wrongly) as the "snitch" whose information resulted in three gang thugs being convicted and sentenced to life without parole for killing a child in a misdirected drive by shooting?
If we don't handle such cases very conservatively as bodycams become more prevalent, after one retaliation murder, citizens in crime ridden neighborhoods will be LESS likely than ever to talk to police. This is rather opposite from the goal of "community policing" advocates.
I think we need more experience with this before we put too many processes in place to solve problems that are not problems.
The main intent of bodycams seems to be to resolve what happened during a couple minutes of a particular officer's career. If there's a specific request for a timeframe around a particular event, if the police refuse to provide the unedited footage or redact stuff that the requester wants, the courts can be called on to resolve the issue.
At a minimum, one trusted person (not just an admin) would need to review the entire video once even if nothing was found to redact. This person may have to research ongoing investigations or determine if releasing a specific portion would compromise an investigation and may have to determine if someone is an at-risk informant. If something needs to be redacted, there's additional video editing required (perhaps by another person).
It seems reasonable that each hour of video released would require a minimum of one person-hour of review and maybe several person-hours. $190/hour isn't necessarily excessive.
Remember, also, this person/these persons may need to be paid overtime (and union wages and pension contributions...) to fulfill the request if it's to get completed in a reasonable timeframe.
When someone, say "Big Mike" Brown, is shot by police, it's known when and where it happened. Releasing five minutes of video in response to a specific incident once the investigation is done would cost little and would still be extremely useful. One does not have to "trust the police" to release the video. One does have to trust them (or those related to them) to not redact stuff that is relevant but such redaction will be obvious and can be dealt with by the courts if needed.
Seriously, if you had kids and some pedophile was raping one of them and a cop wearing a body cam came across it, would you want the video of your kid being raped to be on the internet forever because someone "has the right to bodycam footage"? How about video of the body of a loved one who died in your house in a horrible accident?
No, they are not useless. When a specific event occurs, usually just a few minutes of recording is needed to better understand what happened and, just a few minutes worth need to be cleared for release. This was a broad request for almost 200 hours of video - the fact that such a request is quite expensive to fulfill does not mean that the cameras are 'useless'.
Second, it's safer as one device can't destroy an entire train full of people.
Umm... Just because it hasn't been done, doesn't mean it won't - esp. with HSR. When (not if) it happens, rail travel may become as annoying as air travel.
There's a lot of track to protect. And with drones and robotics available to the "bad guys", it's hard to protect the track from small, but powerful explosives being planted at key points on the track in a curve (carefully timed for detonation based on train approach/position) to result in a train flying off the track and, if the perp is clever, falling some distance, at a high speed. That will be pretty bad for the passengers.
One advantage of airplanes are that you can control what gets in/on them because they are only on the ground in controlled areas - that's what causes the TSA hassle to the typical passenger. On the other hand, planes are, of course, vulnerable to ground based missiles/artillery, but those are hard to get. And, if you DO manage to get explosives or something similar on board to destroy the plane in flight, you may be able to result in quite a few injuries/deaths on the ground - but, this is probably hard to predict except right under places, mostly approach/departure, where the planes are at low altitudes.
My guess is that the first terrorist induced high speed derailment will cause not only dramatic moves to protect track, but also, in classic security theater fashion, apply much the same standards to trains as planes to the extent those standards are intended to prevent bringing explosives aboard (box cutters are not as much of a problem on trains - but then, with armored cockpit doors, they shouldn't be a problem anymore on planes).
With so little detail, it's hard to say for sure, but it sounds like you were likely wrong.
First, the fact that something is flushed from a register is NO guarantee that it will be visible to other processors at any particular time in the future. Sure, most architectures and implementations with most workloads will move it "fairly quickly" from caches to 'main' memory shared by all processors. But "fairly quickly" is undefined - one instruction? Two? 20? Seven clock cycles? Six?. Worse, once the register is actually flushed to main memory by the processor doing the write, there's no guarantee that other processors will see the updated value when accessing the physical address at any particular time in the future -- the 'stale' version of the data may be sitting in L1 or L2 cache for an arbitrary period of time (and this is usually even longer and more unpredictable and, in my experience, the more common source of concurrency problems in code written by amateurs who have never carefully read even the memory model section of even one hardware architecture spec).
Second, C makes no guarantees about when a register (or even what a 'register' is - esp. on a particular architecture) is flushed to to the L1/L2/L? cache/memory. Particular implementations on particular architectures at particular optimization levels may do so when you expect -- but they also may do something quite different.
When you're programming in a high level language, you should adhere to the rules of the high level language and not make assumptions about how the compiler, runtime, and underlying architecture work as you have no idea when a new version of compiler, a new version of runtime, or a new revision of hardware etc will be used with your code and invalidate your assumptions -- and that's not even considering porting to an alternative architecture in the future.
The fact that an OS vendor coded something a particular way does not mean that it's a good idea for you to do it. They know what hardware their OS targets (including multiple architectures, each of which will likely have different implementations of key concurrency control primitives) and will patch their code if needed. As well, in the case of Microsoft, both the microprocessor vendors and (to a lesser extent) system builders test their implementations on Windows before alpha release so if there's a discrepancy, either the hardware will likely be changed or Microsoft will issue a bug fix for that hardware. Note that the underlying OS even almost certainly has all sorts of "hacks" in it to get around errata in specific steppings of Intel microprocessors. Depending on the OS, just stepping through the assembly code for a library or system call may be especially misleading unless you have verified that that's really the code that runs on EVERY implementation of the hardware/OS etc.
Of course, if you know that your code would never need to run on another compiler, run-time, architecture, implementation of the architecture (including clock rates, memory speeds), or even stepping of a microprocessor and you understand all the layers well (perhaps implemented them yourself) have at it -- but, please, do us all a favor and just write your code in assembly so it's clearer to those who may follow you what you did rather than leave others trying to guess what you assumed about the underlying infrastructure.
For the rest of us that know things change, when writing in a high level language, be professional and follow the specs and use available OS libraries for synchronization needs where available. I've had to implement my own in the long distant past (including to replace a horrible implementation of CriticalSections back in the early days of Windows NT), but those days are mostly in the distant rearview mirror now that most everything has been multicore for at least 15 years.
If you're even thinking about 'registers' when considering correctness of concurrency when programming in a high level language, you are almost certainly doing something wrong.
That caught my eye also, but this would not be an ex post facto law if I'm to believe the summary is accurate and complete (yes, I know...).
It does not criminalize an act performed in the past at which time it was legal.
The action it is criminalizing, after its passage, is selling a specific class of phones. That class of phones are those made after January 1, 2016 which the manufacturer has no means of decrypting. It doesn't even, based on the summary, prevent manufacturing of such a phone in New York (not that I expect there are any such manufacturers).
It would be like passing a law aimed at reducing pollution that banned used car dealers from selling cars made before 1980.
I recall driving a rental car many years ago at about 9:30AM in a section of NYC that was very congested - and most of the cars were taxis (it was pretty much a sea of yellow). The only way to make progress was to play a little game of chicken with the taxi drivers and shove the nose of my car in front of their bumpers when there really wasn't enough room to do so "safely". And, that's exactly what they were doing with me and each other also so I didn't get honked at or cursed at -- it was just how you could get where you were going.
However everyone, myself included, was making what would be considered illegal lane changes and IF there had been an accident fault would have been allocated to the driver shoving their nose into the tiny bit of daylight between two cars in the adjacent lane.
I can't imagine that the google lawyers would let the engineers code the software to drive that way OR to come as close to pedestrians that were jaywalking here and there. I suspect a google self driving car would just sit there and start whimpering and maybe 12 hours later finally think it was safe to progress when traffic was lighter.
A more actual example... I was reading someone complaining because a google self-driving car was in front of them in a residential area and a garbage truck picking up rubbish was in front of the google car. The google car didn't have the sense to pass the truck (perfectly legal and what drivers normally do) as it stopped every 50 feet to pick up another bin all the way up the block. This left the person behind having to pass not only the truck, but the google car that was dutifully tailing the truck. The more google cars that piled up behind a garbage truck, the harder this passing would be.
In light rush hour where I live, there are all sorts of instances where merging onto a freeway requires playing a bit of chicken -- else you would end up at the end of the merge lane in a dead stop (and that's REALLY difficult to recover from and creates a giant mess for everyone). Sometimes someone will act unpredictably (either intentionally closing a gap to keep you from taking it or, more often, trying to "help" you at the last minute by trying to create a slot in front of them when you were planning on sliding in behind them). Other times, you just have to act like you're going to take a slot that's really a little too small to take without making someone slow down a bit (almost everyone is already closer to the car in front of them than they should be so there are no gaps to merge into leaving proper clearances behind and ahead of you). Again, I can't imagine the lawyers (or the programmers) allowing self-driving cars to be that aggressive and, in the end, I'll bet it won't be uncommon to see traffic jams caused by cars that couldn't merge "safely" so just stop at the end of the merge lane - that won't be popular.
Mixing self driving cars running code overseen by lawyers and conservative programmers with meat bag driven cars in congested situations seems to be very challenging. However, once on the freeway going in a straight line w/o any need to deviate, I'm pretty sure, on the average, self driving cars are/will soon be much safer than meat bag driven cars whose drivers are on their cell phone or shaving or putting on mascara (yep, I've seen that - amazing).
I've spent way too many hours in my life w/lawyers when I've needed to deal with H-1B issues. I would have loved, in every instance, to find an"American" developer even nearly as qualified and even at a higher salary (the H-1B process costs money for the employer and pain for me, the hiring manager, I would much rather be spending my time reviewing designs, mentoring young employees, mediating conflicts between good but strong minded developers, and defending resources) -- but they just didn't exist. So, yes, I know something about H-1Bs
My plumber example was simply an economics test in real life related to the notion that somehow experience, alone, is a very relevant factor. Are you willing to pay more for something just because an old fart produced it? Of course not if it is YOUR money.
It would be pretty hard to find a 26 year old licensed and respected Neurosurgeon. But, H-1B or not, that must be a pretty awesome person if they existed and I might prefer they operate on me than some old fart who graduated at the bottom of their class and had managed to keep their job for 25 years and hadn't kept up on the latest developments very well. Dealing with family members' serious medical conditions, I've actually most respected some of the youngest doctors at teaching universities and have assisted in having relatives transferred from the care of old fart doctors to much younger, and more qualified, doctors.
I value useful experience which is applied to the job at hand highly. However, I don't value age or number of years of repetitious experience. I much prefer an employee that embraces new technology, learns new stuff, takes responsibility for their code and, if it fails, takes it as a personal failing that they will go to the ends fo the Earth to fix and mitigate the impact of the bug. I don't care what age the developer is and I've worked with many and many have worked for me that ARE older and get it. What happens is that it's hard to judge 22 year olds and they all think they are the best thing since sliced bread so managers (myself included) hire them on a gut feel. Sometimes this works out, but sometimes it doesn't. However, when I'm looking at a 45 year old, they have a work history and career trajectory, I may know people they have worked with, I can ask them questions regarding enterprise reality (customer crisis situations etc.) and I can evaluate them on their performance so I don't hire them on a 'gut feel'. Of course, when layoffs come, I toss the least productive members of the team and, unsurprisingly, they are often young people that my "gut feel" was not right on. One reason older workers feel "discriminated against" is that once one has 15 years of experience, failure or meritocracy is obvious -- with a 22 year old, you are looking for untapped potential
BTW, I graduated university in the (very) early 80's. Do the math. I've lived through many a downsizing and never was threatened (and, in my early years, when very rich "termination packages" were being offered, my managers sat me down and said "I have to approve the package, I won't approve it for you because I want to keep you" -- in later years that became something we [as I was then a manager] couldn't do any more unfortunately because the lawyers didn't like it).
Your are wrong about companies wanting to retrain existing talent.
Then why work for those companies? I've never worked for one. If you're not contributing sufficiently that your employer would rather hire unproven outsiders and train them than train you, a known quantity, that's a pretty good hint that they don't think much of you. You probably then should do something different -- either improve your skills or switch to a company whose needs better match your capabilities and interests.
Experienced employees usually are at a higher wage than a new inexperienced employee.
If "experienced" employees are making more money but are not worth that much money, of course they will be replaced by those providing better ROI. Why would employers pay more just because someone is older unless that also inferred some useful (to the employer) increase in productivity, quality, or something similar? If you begin to find that younger workers are more desirable to employers because they are cheaper, either stop accepting raises to avoid pricing yourself out of the market or step up your game.
Assume you have the option of two plumbers, one 35 years old with 15 years of experience and one 65 years old with 45 years of experience and you have a fairly routine job to do. People you trust have recommended both plumbers to you based on both work quality and them meeting commitments. You've seen both plumbers' work and believe that both do good work. However, the 35 year old quotes $6K for the job and the 65 year old quotes $9K for the work. Do you hire the 35 year old or spend another $3K to hire the 65 year old just because they are older? I can't think of any reason in this case not to select the 35 year old.
To be honest, of the American engineers I've worked with who complained about H-1B visas in general, I would hire virtually none of them -- and that's not because they are complaining about H-1B visas, it's because they just aren't very good at their jobs which, I suspect, results in them being insecure and fearing any competition. Obviously there have been individual H-1B "mishires" that I've heard complaints about from people I do respect and would hire -- but even that has been fairly rare (again, this may be because I haven't worked for companies that abused the H-1B program -- I'm all for eliminating abuse of the program by those who use it not to hire the best workers, but the cheapest workers).
The problem is that $110K is too low to be very useful in the SV and too high in other parts of the country. For somewhere that a nice house on a nice piece of property costs $300K, $110K is a ridiculously high minimum salary for an H-1B worker.
If you need to hire a highly skilled individual in some small town in the midwest because you need a few specialists, you probably can't get anyone to move from the SV for almost any amount of salary (they have families and friends in the SV, they have a home, their partners have jobs, they like the weather and activities in the Bay Area, they may feel they would be committing career suicide by getting out of the churn of a high tech area, and they are really committing to two moves - one into the small town and one back to the "big city" when the job ends). $110K may much more than the existing specialists on your staff are already making (that would be the "prevailing wage").
I think the goal should to impose a disincentive on hiring H-1B workers because they are cheaper. I think it's fine to hire them if they are better. I, personally, have no problem with H-1B's being issued to hire workers who are smarter, more productive, better educated, less annoying than "native" workers. Why drag America's economy down by handicapping our products by lazy or incompetent engineering just to protect "American Jobs". The economy is global and burying one's head in the sand about that fact would be stupid. It's dangerous to rely on protectionism to compensate for one's own inability to compete in the job market. By importing the cream of the crop, we motivate "native" workers to step up their game and everyone benefits (except those that probably should have picked a different field instead of, perhaps, picking a field that they thought paid well rather than one they had the skills for). We don't want to be a High School basketball team in an NBA world.
(Tip to American kids: spend a little less time on Facebook and a little more time studying and building stuff, else you likely won't be the most qualified for the jobs you will be applying to).
Killing the H-1B program would just encourage offshoring and cost American jobs. If one can't find sufficiently skilled American workers in particular key areas, preventing them from hiring foreign workers will encourage them to move the entire development effort offshore - certainly if they were already near the cusp of that making sense. The program should be fixed as it suffers from some abuse. However, I've hired and acquired H-1B developers and they have consistently been much more competent as a group than American workers (i.e., those born, raised, and receiving all of their education in the United States) and I've never abused it. I did work at one company (no longer exists) which I think was pushing the edge of abuse however.
It's pretty easy to detect when 'prevailing wage' has been set 25% too low -- esp. since the Federal government would, on a $140K/yr H-1B job get $35K they could use to fund investigating and enforcing the provision in that one worker's case. The goal of the 25% suggestion is to set it high enough it's NOT possible to, under scrutiny, game it.
A fixed number is complete B.S. Wages vary by region and jobs.
Why should employers train/retrain employees in basic skills? Do you expect to 'train' your doctor? Do you expect to 'train' the electrician who you hire to rewire your house?
If you want to get a job programming in R, learn R on your own and then apply.
When an employer brings in a new technology into an existing job, they are generally eager to train valued employees with potential in the new technology (less valued and easily replaced employees, of course, need not apply).
Why should an employee strike start a 'no H-1B' period? Employee strikes are voluntary on the part of the employee. Employees could just declare a 60 second strike every year on New Year's eve and continually renew the 'no H-1B' period.
As well, any such general rule must require that the restriction only apply to hiring H1-Bs for the same/equivalent job at the same general location. If demand for GE jet engines declines and they have to close one of their jet engine plants and lay off janitors, there's no logical reason that should prevent GE from using H-1B visas to hire needed foreign PhDs to improve image processing algorithms in their healthcare division 2,000 miles away.
I would prefer a substantial Federal tax (perhaps 25% of the reported W-2 income?) paid by the H-1B employer and removal of H-1B caps.
Retain the prevailing wage requirement, but when computing general prevailing wages, include the H-1B tax the employers pay in the prevailing wage calculation for H-1B workers in general (but not in the wage of the specific H-1B position that is being evaluated).
Just for show, also retain the 'must try to hire an American first' requirement - but that's really a joke as we all know the 'on paper' qualifications of a developer mean almost nothing as some of the worst performers have some of the best looking resumes so enforcement is impossible without hamstringing employers and American companies.
The Federal government would first use the taxes so raised to sharpen enforcement of the provisions of the H-1B program (esp. as it relates to 'prevailing wage'), the rest could go into the Social Security Trust Fund to prop that up.
This would go a long way towards making sure that the employers actually NEED to hire foreign workers and make it much harder to game 'prevailing wage' by making the out of pocket cost to the employer significantly higher for H-1B workers.
In addition, by including the employer tax when computing prevailing wage and then requiring that the next H-1B worker get that higher wage it creates a snowball effect that discourages frivolous use of H-1Bs even more. One effect would be to drive the 'prevailing wage' for H-1B computations higher and higher as a larger percentage of comparable positions were filled by H-1B holders. Since the employer actually has to pay the H-1B holder the 'adjusted' prevailing wage, they would be making more than American workers overall which would make the H-1B option even less attractive AND would cause American workers to demand raises if they were, in fact, contributing as much. Rinse and repeat. To avoid a runaway situation which could have bad consequences (such as American workers abandoning the field entirely), there would probably need to be some sort of brake on this effect such as capping the 'prevailing wage adjustment' to 25% of the base prevailing wage.
Slashdot Mirror
And that certification should disallow actions like FTDI took. If a self-certifier fails to follow the rules, they should have to, in the future, go through an outside party from an 'approved certifier list' to get certification. Certifiers on the 'approved certifier list' who fail to follow the rules would be banned forever from being certifiers and forfeit a bond.
Microsoft is the agent pushing this crap to your machine under their moniker, therefore they have significant responsibility for the content. Microsoft is really hurting themselves by allowing this to go on -- esp. when this specific company had previously proven themselves to be untrustworthy.
I can see why FTDI has done this -- although I would rather they would track down the board builders who use the fake chips and those that sell their boards and sue them.
However, I'm trying to figure out what Microsoft's interest in pushing this. Did they just not test this case (surely, after the last time, they should be testing this)? Accepting such drivers will just discourage people from 'auto updating' and they seem bent on encouraging that behavior, not discouraging it.
(Although, in my case, Microsoft had already managed to get me to stop taking updates as I got tired of having to carefully check each one to see if it was another undocumented driveby update to nag me to upgrade to Windows 10 from 8.1).
When I really don't want to vote for any listed candidate (using paper absentee ballots), I overvote -- I just vote for everyone for that office. This prevents anyone from altering my ballot before it is counted so it appears I voted for a specific candidate. No, I'm not paranoid.
How many decades should the U.S. let the office of President remain unfilled even though there's a Presidential election every two weeks? Or, would the current President/Vice President just get to rule for decades even though everyone hates them (and they were disqualified from running again on the first ballot decades earlier because 'none of the above' won).
How would that make any sense? The second place candidate can be VERY unpopular in a lopsided election.
If a universally popular Presidential candidate got 99.9% of the popular vote, and the second place candidate (a serial pedophile) got 0.1% of the vote (having cornered the pedophile vote, the anti-establishment vote, and the "unable to mark ballot correctly" vote), why should someone that less than 1 in 1000 voters wanted as President be one heartbeat away from becoming the President?
No, he was impeached by the House. He was then acquitted rather than convicted by the Senate.
The impeachment was completely successful, else the Senate would never have weighed in.
No one (including police and military personnel) ever "needs" a gun. Just as they don't "need" fluids or food or medical care. However, in all cases, the consequence of not have a gun, fluids, food, or medical care may be death. So, I think you need to define "need".
Here, however, are a few instances (well more than the number of fingers on one of your hands, assuming that you're human and have a normal anatomy) where guns were quite useful to those that had them.
A qualified person has to review every bit of the video and redact as needed.
When an officer enters your home and has the bodycam on, it's nobody's business what's in your home unless it's part of a criminal investigation (vs. just a fishing expedition by reporter or by a thief casing houses with the help of the police video). If a child rape victim is being interviewed in the field, the audio and video of that interaction should not be made available "just for the asking" (except, as necessary, as part of a criminal case or, perhaps, a complaint by an involved party about how the interaction was handled) for pedophiles to jerk off to. If police respond to a domestic violence call and the wife has locked herself in a utility closet and is naked, when she comes out and the bodycam captures her state of undress, that's not something that should be released for every perv on the internet to post to porn sites. The list goes on and on.
If the request is not for a specific officer at a specific time but for something like "All video showing interactions between Latino officers and African American residents between 12/1/2015 00:00 and 1/1/2016 00:00", careful examination of the material is required and someone qualified to make a judgement call on if a resident is "African American" or not.
Getting the video is the easy part, vetting it is the hard and expensive part.
Without specifics of the request and what type of review was needed, it's hard to know if the charge is unreasonable. It does sound a little high to me, but it might be perfectly reasonable.
However, police must be consulted and have input into the process. How would a third party,without consultation with police, know that a particular person talking to a police officer (perhaps just by their clothing or stature et al even if the face is obscured) could cause that person to be identified (rightfully or wrongly) as the "snitch" whose information resulted in three gang thugs being convicted and sentenced to life without parole for killing a child in a misdirected drive by shooting?
If we don't handle such cases very conservatively as bodycams become more prevalent, after one retaliation murder, citizens in crime ridden neighborhoods will be LESS likely than ever to talk to police. This is rather opposite from the goal of "community policing" advocates.
I think we need more experience with this before we put too many processes in place to solve problems that are not problems.
The main intent of bodycams seems to be to resolve what happened during a couple minutes of a particular officer's career. If there's a specific request for a timeframe around a particular event, if the police refuse to provide the unedited footage or redact stuff that the requester wants, the courts can be called on to resolve the issue.
At a minimum, one trusted person (not just an admin) would need to review the entire video once even if nothing was found to redact. This person may have to research ongoing investigations or determine if releasing a specific portion would compromise an investigation and may have to determine if someone is an at-risk informant. If something needs to be redacted, there's additional video editing required (perhaps by another person).
It seems reasonable that each hour of video released would require a minimum of one person-hour of review and maybe several person-hours. $190/hour isn't necessarily excessive.
Remember, also, this person/these persons may need to be paid overtime (and union wages and pension contributions...) to fulfill the request if it's to get completed in a reasonable timeframe.
When someone, say "Big Mike" Brown, is shot by police, it's known when and where it happened. Releasing five minutes of video in response to a specific incident once the investigation is done would cost little and would still be extremely useful. One does not have to "trust the police" to release the video. One does have to trust them (or those related to them) to not redact stuff that is relevant but such redaction will be obvious and can be dealt with by the courts if needed.
Seriously, if you had kids and some pedophile was raping one of them and a cop wearing a body cam came across it, would you want the video of your kid being raped to be on the internet forever because someone "has the right to bodycam footage"? How about video of the body of a loved one who died in your house in a horrible accident?
No, they are not useless. When a specific event occurs, usually just a few minutes of recording is needed to better understand what happened and, just a few minutes worth need to be cleared for release. This was a broad request for almost 200 hours of video - the fact that such a request is quite expensive to fulfill does not mean that the cameras are 'useless'.
How do you identify people who can be trusted not to reveal confidential information that, if revealed, may cost someone their lives?
Just being 'TV folk' does not mean that someone can be trusted.
Umm... Just because it hasn't been done, doesn't mean it won't - esp. with HSR. When (not if) it happens, rail travel may become as annoying as air travel.
There's a lot of track to protect. And with drones and robotics available to the "bad guys", it's hard to protect the track from small, but powerful explosives being planted at key points on the track in a curve (carefully timed for detonation based on train approach/position) to result in a train flying off the track and, if the perp is clever, falling some distance, at a high speed. That will be pretty bad for the passengers.
One advantage of airplanes are that you can control what gets in/on them because they are only on the ground in controlled areas - that's what causes the TSA hassle to the typical passenger. On the other hand, planes are, of course, vulnerable to ground based missiles/artillery, but those are hard to get. And, if you DO manage to get explosives or something similar on board to destroy the plane in flight, you may be able to result in quite a few injuries/deaths on the ground - but, this is probably hard to predict except right under places, mostly approach/departure, where the planes are at low altitudes.
My guess is that the first terrorist induced high speed derailment will cause not only dramatic moves to protect track, but also, in classic security theater fashion, apply much the same standards to trains as planes to the extent those standards are intended to prevent bringing explosives aboard (box cutters are not as much of a problem on trains - but then, with armored cockpit doors, they shouldn't be a problem anymore on planes).
With so little detail, it's hard to say for sure, but it sounds like you were likely wrong.
First, the fact that something is flushed from a register is NO guarantee that it will be visible to other processors at any particular time in the future. Sure, most architectures and implementations with most workloads will move it "fairly quickly" from caches to 'main' memory shared by all processors. But "fairly quickly" is undefined - one instruction? Two? 20? Seven clock cycles? Six?. Worse, once the register is actually flushed to main memory by the processor doing the write, there's no guarantee that other processors will see the updated value when accessing the physical address at any particular time in the future -- the 'stale' version of the data may be sitting in L1 or L2 cache for an arbitrary period of time (and this is usually even longer and more unpredictable and, in my experience, the more common source of concurrency problems in code written by amateurs who have never carefully read even the memory model section of even one hardware architecture spec).
Second, C makes no guarantees about when a register (or even what a 'register' is - esp. on a particular architecture) is flushed to to the L1/L2/L? cache/memory. Particular implementations on particular architectures at particular optimization levels may do so when you expect -- but they also may do something quite different.
When you're programming in a high level language, you should adhere to the rules of the high level language and not make assumptions about how the compiler, runtime, and underlying architecture work as you have no idea when a new version of compiler, a new version of runtime, or a new revision of hardware etc will be used with your code and invalidate your assumptions -- and that's not even considering porting to an alternative architecture in the future.
The fact that an OS vendor coded something a particular way does not mean that it's a good idea for you to do it. They know what hardware their OS targets (including multiple architectures, each of which will likely have different implementations of key concurrency control primitives) and will patch their code if needed. As well, in the case of Microsoft, both the microprocessor vendors and (to a lesser extent) system builders test their implementations on Windows before alpha release so if there's a discrepancy, either the hardware will likely be changed or Microsoft will issue a bug fix for that hardware. Note that the underlying OS even almost certainly has all sorts of "hacks" in it to get around errata in specific steppings of Intel microprocessors. Depending on the OS, just stepping through the assembly code for a library or system call may be especially misleading unless you have verified that that's really the code that runs on EVERY implementation of the hardware/OS etc.
Of course, if you know that your code would never need to run on another compiler, run-time, architecture, implementation of the architecture (including clock rates, memory speeds), or even stepping of a microprocessor and you understand all the layers well (perhaps implemented them yourself) have at it -- but, please, do us all a favor and just write your code in assembly so it's clearer to those who may follow you what you did rather than leave others trying to guess what you assumed about the underlying infrastructure.
For the rest of us that know things change, when writing in a high level language, be professional and follow the specs and use available OS libraries for synchronization needs where available. I've had to implement my own in the long distant past (including to replace a horrible implementation of CriticalSections back in the early days of Windows NT), but those days are mostly in the distant rearview mirror now that most everything has been multicore for at least 15 years.
If you're even thinking about 'registers' when considering correctness of concurrency when programming in a high level language, you are almost certainly doing something wrong.
That caught my eye also, but this would not be an ex post facto law if I'm to believe the summary is accurate and complete (yes, I know...).
It does not criminalize an act performed in the past at which time it was legal.
The action it is criminalizing, after its passage, is selling a specific class of phones. That class of phones are those made after January 1, 2016 which the manufacturer has no means of decrypting. It doesn't even, based on the summary, prevent manufacturing of such a phone in New York (not that I expect there are any such manufacturers).
It would be like passing a law aimed at reducing pollution that banned used car dealers from selling cars made before 1980.
Indeed.
I recall driving a rental car many years ago at about 9:30AM in a section of NYC that was very congested - and most of the cars were taxis (it was pretty much a sea of yellow). The only way to make progress was to play a little game of chicken with the taxi drivers and shove the nose of my car in front of their bumpers when there really wasn't enough room to do so "safely". And, that's exactly what they were doing with me and each other also so I didn't get honked at or cursed at -- it was just how you could get where you were going.
However everyone, myself included, was making what would be considered illegal lane changes and IF there had been an accident fault would have been allocated to the driver shoving their nose into the tiny bit of daylight between two cars in the adjacent lane.
I can't imagine that the google lawyers would let the engineers code the software to drive that way OR to come as close to pedestrians that were jaywalking here and there. I suspect a google self driving car would just sit there and start whimpering and maybe 12 hours later finally think it was safe to progress when traffic was lighter.
A more actual example... I was reading someone complaining because a google self-driving car was in front of them in a residential area and a garbage truck picking up rubbish was in front of the google car. The google car didn't have the sense to pass the truck (perfectly legal and what drivers normally do) as it stopped every 50 feet to pick up another bin all the way up the block. This left the person behind having to pass not only the truck, but the google car that was dutifully tailing the truck. The more google cars that piled up behind a garbage truck, the harder this passing would be.
In light rush hour where I live, there are all sorts of instances where merging onto a freeway requires playing a bit of chicken -- else you would end up at the end of the merge lane in a dead stop (and that's REALLY difficult to recover from and creates a giant mess for everyone). Sometimes someone will act unpredictably (either intentionally closing a gap to keep you from taking it or, more often, trying to "help" you at the last minute by trying to create a slot in front of them when you were planning on sliding in behind them). Other times, you just have to act like you're going to take a slot that's really a little too small to take without making someone slow down a bit (almost everyone is already closer to the car in front of them than they should be so there are no gaps to merge into leaving proper clearances behind and ahead of you). Again, I can't imagine the lawyers (or the programmers) allowing self-driving cars to be that aggressive and, in the end, I'll bet it won't be uncommon to see traffic jams caused by cars that couldn't merge "safely" so just stop at the end of the merge lane - that won't be popular.
Mixing self driving cars running code overseen by lawyers and conservative programmers with meat bag driven cars in congested situations seems to be very challenging. However, once on the freeway going in a straight line w/o any need to deviate, I'm pretty sure, on the average, self driving cars are/will soon be much safer than meat bag driven cars whose drivers are on their cell phone or shaving or putting on mascara (yep, I've seen that - amazing).
I've spent way too many hours in my life w/lawyers when I've needed to deal with H-1B issues. I would have loved, in every instance, to find an"American" developer even nearly as qualified and even at a higher salary (the H-1B process costs money for the employer and pain for me, the hiring manager, I would much rather be spending my time reviewing designs, mentoring young employees, mediating conflicts between good but strong minded developers, and defending resources) -- but they just didn't exist. So, yes, I know something about H-1Bs
My plumber example was simply an economics test in real life related to the notion that somehow experience, alone, is a very relevant factor. Are you willing to pay more for something just because an old fart produced it? Of course not if it is YOUR money.
It would be pretty hard to find a 26 year old licensed and respected Neurosurgeon. But, H-1B or not, that must be a pretty awesome person if they existed and I might prefer they operate on me than some old fart who graduated at the bottom of their class and had managed to keep their job for 25 years and hadn't kept up on the latest developments very well. Dealing with family members' serious medical conditions, I've actually most respected some of the youngest doctors at teaching universities and have assisted in having relatives transferred from the care of old fart doctors to much younger, and more qualified, doctors.
I value useful experience which is applied to the job at hand highly. However, I don't value age or number of years of repetitious experience. I much prefer an employee that embraces new technology, learns new stuff, takes responsibility for their code and, if it fails, takes it as a personal failing that they will go to the ends fo the Earth to fix and mitigate the impact of the bug. I don't care what age the developer is and I've worked with many and many have worked for me that ARE older and get it. What happens is that it's hard to judge 22 year olds and they all think they are the best thing since sliced bread so managers (myself included) hire them on a gut feel. Sometimes this works out, but sometimes it doesn't. However, when I'm looking at a 45 year old, they have a work history and career trajectory, I may know people they have worked with, I can ask them questions regarding enterprise reality (customer crisis situations etc.) and I can evaluate them on their performance so I don't hire them on a 'gut feel'. Of course, when layoffs come, I toss the least productive members of the team and, unsurprisingly, they are often young people that my "gut feel" was not right on. One reason older workers feel "discriminated against" is that once one has 15 years of experience, failure or meritocracy is obvious -- with a 22 year old, you are looking for untapped potential
BTW, I graduated university in the (very) early 80's. Do the math. I've lived through many a downsizing and never was threatened (and, in my early years, when very rich "termination packages" were being offered, my managers sat me down and said "I have to approve the package, I won't approve it for you because I want to keep you" -- in later years that became something we [as I was then a manager] couldn't do any more unfortunately because the lawyers didn't like it).
Then why work for those companies? I've never worked for one. If you're not contributing sufficiently that your employer would rather hire unproven outsiders and train them than train you, a known quantity, that's a pretty good hint that they don't think much of you. You probably then should do something different -- either improve your skills or switch to a company whose needs better match your capabilities and interests.
If "experienced" employees are making more money but are not worth that much money, of course they will be replaced by those providing better ROI. Why would employers pay more just because someone is older unless that also inferred some useful (to the employer) increase in productivity, quality, or something similar? If you begin to find that younger workers are more desirable to employers because they are cheaper, either stop accepting raises to avoid pricing yourself out of the market or step up your game.
Assume you have the option of two plumbers, one 35 years old with 15 years of experience and one 65 years old with 45 years of experience and you have a fairly routine job to do. People you trust have recommended both plumbers to you based on both work quality and them meeting commitments. You've seen both plumbers' work and believe that both do good work. However, the 35 year old quotes $6K for the job and the 65 year old quotes $9K for the work. Do you hire the 35 year old or spend another $3K to hire the 65 year old just because they are older? I can't think of any reason in this case not to select the 35 year old.
To be honest, of the American engineers I've worked with who complained about H-1B visas in general, I would hire virtually none of them -- and that's not because they are complaining about H-1B visas, it's because they just aren't very good at their jobs which, I suspect, results in them being insecure and fearing any competition. Obviously there have been individual H-1B "mishires" that I've heard complaints about from people I do respect and would hire -- but even that has been fairly rare (again, this may be because I haven't worked for companies that abused the H-1B program -- I'm all for eliminating abuse of the program by those who use it not to hire the best workers, but the cheapest workers).
The problem is that $110K is too low to be very useful in the SV and too high in other parts of the country. For somewhere that a nice house on a nice piece of property costs $300K, $110K is a ridiculously high minimum salary for an H-1B worker.
If you need to hire a highly skilled individual in some small town in the midwest because you need a few specialists, you probably can't get anyone to move from the SV for almost any amount of salary (they have families and friends in the SV, they have a home, their partners have jobs, they like the weather and activities in the Bay Area, they may feel they would be committing career suicide by getting out of the churn of a high tech area, and they are really committing to two moves - one into the small town and one back to the "big city" when the job ends). $110K may much more than the existing specialists on your staff are already making (that would be the "prevailing wage").
I think the goal should to impose a disincentive on hiring H-1B workers because they are cheaper. I think it's fine to hire them if they are better. I, personally, have no problem with H-1B's being issued to hire workers who are smarter, more productive, better educated, less annoying than "native" workers. Why drag America's economy down by handicapping our products by lazy or incompetent engineering just to protect "American Jobs". The economy is global and burying one's head in the sand about that fact would be stupid. It's dangerous to rely on protectionism to compensate for one's own inability to compete in the job market. By importing the cream of the crop, we motivate "native" workers to step up their game and everyone benefits (except those that probably should have picked a different field instead of, perhaps, picking a field that they thought paid well rather than one they had the skills for). We don't want to be a High School basketball team in an NBA world.
(Tip to American kids: spend a little less time on Facebook and a little more time studying and building stuff, else you likely won't be the most qualified for the jobs you will be applying to).
Killing the H-1B program would just encourage offshoring and cost American jobs. If one can't find sufficiently skilled American workers in particular key areas, preventing them from hiring foreign workers will encourage them to move the entire development effort offshore - certainly if they were already near the cusp of that making sense. The program should be fixed as it suffers from some abuse. However, I've hired and acquired H-1B developers and they have consistently been much more competent as a group than American workers (i.e., those born, raised, and receiving all of their education in the United States) and I've never abused it. I did work at one company (no longer exists) which I think was pushing the edge of abuse however.
It's pretty easy to detect when 'prevailing wage' has been set 25% too low -- esp. since the Federal government would, on a $140K/yr H-1B job get $35K they could use to fund investigating and enforcing the provision in that one worker's case. The goal of the 25% suggestion is to set it high enough it's NOT possible to, under scrutiny, game it.
A fixed number is complete B.S. Wages vary by region and jobs.
Why should employers train/retrain employees in basic skills? Do you expect to 'train' your doctor? Do you expect to 'train' the electrician who you hire to rewire your house?
If you want to get a job programming in R, learn R on your own and then apply.
When an employer brings in a new technology into an existing job, they are generally eager to train valued employees with potential in the new technology (less valued and easily replaced employees, of course, need not apply).
Why should an employee strike start a 'no H-1B' period? Employee strikes are voluntary on the part of the employee. Employees could just declare a 60 second strike every year on New Year's eve and continually renew the 'no H-1B' period.
As well, any such general rule must require that the restriction only apply to hiring H1-Bs for the same/equivalent job at the same general location. If demand for GE jet engines declines and they have to close one of their jet engine plants and lay off janitors, there's no logical reason that should prevent GE from using H-1B visas to hire needed foreign PhDs to improve image processing algorithms in their healthcare division 2,000 miles away.
I would prefer a substantial Federal tax (perhaps 25% of the reported W-2 income?) paid by the H-1B employer and removal of H-1B caps.
Retain the prevailing wage requirement, but when computing general prevailing wages, include the H-1B tax the employers pay in the prevailing wage calculation for H-1B workers in general (but not in the wage of the specific H-1B position that is being evaluated).
Just for show, also retain the 'must try to hire an American first' requirement - but that's really a joke as we all know the 'on paper' qualifications of a developer mean almost nothing as some of the worst performers have some of the best looking resumes so enforcement is impossible without hamstringing employers and American companies.
The Federal government would first use the taxes so raised to sharpen enforcement of the provisions of the H-1B program (esp. as it relates to 'prevailing wage'), the rest could go into the Social Security Trust Fund to prop that up.
This would go a long way towards making sure that the employers actually NEED to hire foreign workers and make it much harder to game 'prevailing wage' by making the out of pocket cost to the employer significantly higher for H-1B workers.
In addition, by including the employer tax when computing prevailing wage and then requiring that the next H-1B worker get that higher wage it creates a snowball effect that discourages frivolous use of H-1Bs even more. One effect would be to drive the 'prevailing wage' for H-1B computations higher and higher as a larger percentage of comparable positions were filled by H-1B holders. Since the employer actually has to pay the H-1B holder the 'adjusted' prevailing wage, they would be making more than American workers overall which would make the H-1B option even less attractive AND would cause American workers to demand raises if they were, in fact, contributing as much. Rinse and repeat. To avoid a runaway situation which could have bad consequences (such as American workers abandoning the field entirely), there would probably need to be some sort of brake on this effect such as capping the 'prevailing wage adjustment' to 25% of the base prevailing wage.