For me the quality issue seems to be not so much a question of "H1-B or not" as of "contractor or not". Almost all of the H1-Bs I've seen have been brought over from one of the big Indian contracting/outsourcing companies, and the attitude of those companies is very much "get it done as fast as we can and still pass the acceptance tests, don't worry about quality or maintainability because we won't be the ones who have to clean up the mess" (or if they are, it's another contract billed by the hour so the worse the mess the better for them). The large American contracting and consulting firms aren't much if any better in that regard either, which is why I hated it when the contractors or consultants got their fingers into the code.
They can tell time like a watch. Timekeeping needs to be independent of a phone, syncing with the phone when in range is fine but I don't want to lose my watch as a timepiece just because I'm out of Bluetooth range of my phone at the moment. Alarms would also be nice, as would stopwatch and countdown timer functions, and all that's easy to do once you've got the basic electronics there.
Notifications. It doesn't need sound, a wristwatch has much better skin contact so vibration'll be pretty reliable. One glance then tells me whether or not it's something I need to deal with. I've got all the advantages of seeing every notification while still being unobtrusive about it.
Biomonitoring. I'm not sanguine about shipping the info off to a company, but having a constant record of pulse, blood-oxygen level, strides taken and so forth can be useful and the wrist is a good place to put the sensors.
They're not as must-have as the hype makes them out to be, but they're fairly useful for things many people would want once they know they're there. I would, however, ditch the color screen in favor of monochrome or an e-ink display. Cheaper and consumes less power.
The problem for me isn't the H1-B workforce itself, but the terms of the H1-B visa that make it impossible for the employee (who is not the visa holder) to participate in the workforce. Since the visa is held by the employer and the terms don't give anywhere near enough time between the candidate accepting an offer and his would-be new employer being able to obtain their own H1-B visa for him, he's going to be forced to leave the country and won't be eligible to return to go to work. That essentially locks an employee into one single employer and prevents him from accepting a better offer for his services even if one's made to him. This smacks an awful lot of a form of slavery. It's almost like those companies don't want to compete in the marketplace for the services of their employees.
No, the RJ45 doesn't need redesigned/replaced to make a smaller connector. Right now it's about as small as it can get and still be handled by human fingers without trouble or damage. If it's made too small to handle, what's the point? For a device where connector size is that critical, it's probably better to use WiFi for connectivity and portability and a USB-to-Ethernet adapter if you absolutely need a hard-wired connection.
I'd also point to micro-USB as an example of why smaller isn't better. It's the most fragile, most trouble-prone connector I've ever had the displeasure of working with. It's easy to damage either the cable connector or the socket or both without realizing it, and the damage won't always even be visible when looking into the socket. This are not good things for a connector. On my cel phone I really wish they'd've left the micro-USB connector off and done a better job with the wireless charging (most of the US variants have all the circuitry for it included but they omit the backplate with the necessary antenna loop and connections). WiFi and Bluetooth let me move things around easily enough, and the space would've been better used for an external microSD slot (I've found very few things that can't be moved via a 64GB flash drive).
It's not just work, I know the same thing applies to sports and just about everything people do. Especially as you become good at something it draws you in and you want to go further and get better. Success at something is in a real sense addictive. Eventually you get to the point Robert Heinlein described as: "There is no way to stop. Writers go on writing long after it becomes financially unnecessary... because it hurts less to write than it does not to write."
Up the ante a bit, and have someone with a ham radio license file a complaint, not about WiFi blocking but about an unlicensed operator's (the hotel) interference with a licensed operator's transmissions. The rules about that, IIRC, apply even on the unlicensed bands and give the FCC well-established grounds to shut down the hotel's WiFi completely until it modifies the equipment to eliminate the interference.
Or in Ruby, or Python, or any number of other languages. Java's just another entry in the list here. Frankly I'd've expected the first cross-platform malware to be in Perl, and to have shown up at least 10 years ago. I'm not sure AV tools would even recognize a Perl program as malware...
It wouldn't need to run as a browser plugin. The idea here is to use some other exploit to gain access and drop the.jar file onto the system, then run it as a regular local application. I suspect a lot of people have it because Oracle's made deals to have it included on the manufacturer's images, and those people don't have a clue what Java is or how to remove it so that's a problem.
I am, however, surprised it took them this long to come up with this idea. It's fairly standard on Unix systems, that's how cross-platform scripting of all sorts is done.
I'd like to see a "repeat offenders" classification for copyright claimants like the copyright holders want for alleged infringers. If more than a certain percentage of your copyright infringement claims turn out to be bogus, your claims get diverted for review and won't be acted on until someone's checked the content and checked with the uploader. Same standard for any automated system, if it can't maintain at least the same level of accuracy expected of claimants then it's results can't be used until after human review.
Less altering the relationship I think than enforcing it. Too many beta testers were, it sounds like, treating the beta test as a sneak preview or early-access program and taking advantage of the offering without providing the feedback that's their part of the agreement. All Microsoft's doing is taking out the switch that lets them avoid being bugged for the feedback they agreed to give. It'll annoy people who were giving feedback but aren't having problems with those particular areas, but they're heavily outnumbered by the people who weren't giving feedback at all. Yet another case of the greedy breaking things for everybody, I suppose.
The "next few minutes" is basically just enough time to give the "abandon ship" order. To be useful the algorithm has to predict the rogue wave far enough in advance to let the ship turn and steam clear of the wave group. In a storm, that's probably 20-30 minutes which I don't see happening any time soon.
Would that be a single interface specification for manufacturers to query activity information? A single specification for insuring devices only work with other devices manufactured or licensed by this alliance?
I'd end with </sarcasm>, but anymore that'd just be immediately followed an another <sarcasm>.
@boggle. I use that software a lot simply to get rid of the forced previews and the like so I can sit down to watch a movie and watch the bloody movie, which ought to tell the MPAA and company something right there. The biggest advocate of piracy right now is the MPAA itself, as they constantly and vocally equate simply watching a movie you've purchased legally with piracy.
I've gotten this a lot with devices besides cameras (eg. an LG G3 phone), even when plugged into a 3.0 port. It seems to be caused only by devices with a standard micro-USB connector, not a full-sized one. My thought is that the device's USB chip is 3.0-capable, but the connector and/or cable don't have the extra pins/wires for 3.0 so the device is reporting itself as 3.0 but can only run as 2.0 which makes Windows complain. I haven't seen any problems because of it, even under Windows (I normally connect the devices to Linux machines).
At the top end, the big tech companies like Google or Microsoft have their own spam-filtering systems in-house. At the bottom, individuals and entities too small to run their own mail servers either depend on Bayesian filtering in their e-mail clients or get email from one of the big tech companies. And in the middle, they either outsource their email to one of the big tech companies or can put together their own spam-filtering solution readily enough using available tools like SpamAssassin that're mostly open-source. End result: there's no market for spam filtering except as part of a complete email provider business on the scale of Google or Microsoft.
Not all development work involves solitary coding. How do you get the latest changes from a co-worker when you can't access the repository you both normally push changes to and his personal machine with his copy of the repository doesn't accept incoming connections (and neither does yours, so you can't have him push the changes to you)? How do you access the branch you didn't know you needed until now which isn't in your local copy? How do you get that refactoring a colleague just committed and pushed before the outage that you need to have because your part of the work's predicated on it? How do you get anything into the build process when the build process pulls from the repository that's offline?
All of those can be worked around, but amusingly what you'd need to do is almost exactly what you'd need to do with a non-distributed version control system.
This is why there's redundancy built into the system, more satellites than are strictly needed for operation. If one's clock goes out-of-spec, you notice that it's not agreeing with the rest of the constellation and drop it from your sources. If it's a transient glitch it'll come back in-spec and come back into use, if it's a permanent problem they decommission it and schedule a replacement. Redundancy makes the difference between a major crisis and a minor annoyance.
It's not about stopping spam so much as detecting mail that's not being sent from the servers the purported domain owner says it should be coming from.
It doesn't require total cooperation.
There are no jurisdictional problems with implementing DKIM/DMARC, and they were designed to work with SMTP (although they'll work with any other mail protocol when it comes to that).
One of the goals is to reduce the profitability of spam.
DMARC doesn't require email headers, and DKIM's header doesn't need to be legislated for you to implement it. Yes, that means the spammers don't have to implement it, but that won't help them evade it since the whole point of DKIM is to make it impossible for spammers to implement the header correctly (they don't have the correct private key to generate the signature, only the legitimate domain owner has it).
There's no blacklist, and the only whitelist is of valid outgoing mail servers for a domain maintained by the domain owner (who ought to know what mail servers his domain uses).
It doesn't demand that you trust any servers. It tells you what servers the domain owner trusts to send mail for him. Whether you trust that list or not, you can still trust the important fact needed: any server not on that list should not be trusted to be sending mail from the domain.
One of the proposed solutions (that looks like it might be effective), DMARC, isn't even hard to set up. OK, you need DKIM set up properly on your outgoing mail servers, but that's not that hard to do. If I can figure out how to do it, starting from scratch, in an afternoon, any competent enterprise netadmin should be able to do it. Once DKIM's signing mail, DMARC is just a matter of publishing the DNS records. There's reporting software you can install to send reports back to domain owners when your systems receive problematic mail claiming to be from them, but to just let others detect problematic mail you just need the DNS record with your policies published. This is frankly not rocket science here.
And if your mail software doesn't support DKIM or DMARC? Get better mail software.
You don't compromise with reality. Nor with mathematics. It is what it is, if you don't like that it really doesn't care nor does it have to. If the politicians insist on backdoors or "golden keys", their system's going to fail miserably and spectacularly. The only question is exactly what form the fireworks are going to take, and who's going to foot the bill for cleaning up the mess. My vote's that, if they keep insisting on this, we counter by insisting that they foot the bill for failure. We've warned them, why should their refusal to listen make us responsible for fixing the resulting crisis?
I use PWSafe combined with an OwnCloud instance for sync. Devices have their own local copy of the database plus access to the OwnCloud copy, so I can handle even complicated cases of multiple conflicting updates from multiple devices (I usually do changes on a PC and the "master" gets uploaded to OwnCloud automatically, but devices can either change the OwnCloud copy and those changes get merged into the "master" or they can change their local copy and upload that to OwnCloud for merging into the master manually). All the advantages of the cloud without the data ever having to leave my servers.
Mostly it's because changes to the major version of a distribution tend to involve major-version transitions of multiple software packages, which tends to involve non-trivial differences in configuration files that users will have changed from the initial default contents. Packages can contain scripts to help deal with that, but if I'm doing a 21->23 upgrade I need to run both the 21->22 and the 22->23 scripts and that's hard when the 22 packages were never installed and the 21->22 scripts which would've been in those packages aren't available. Solving this in a way that works right on production systems is... doable but nontrivial. And most of the simple ways involve giving up the ability to use multiple repositories.
I wouldn't run it without the authorities being able to meet the requirements for a search warrant. Otherwise you have the problem of copies of the document in the inboxes of people with no involvement whatsoever who were sent the document in a deliberate attempt by the terrorists to bury their tracks in a crowd of false leads. Given that the sender, not the recipient, determines to whom a message is sent, merely receiving a message without anything more doesn't indicate any involvement or intent on the part of the recipient and can't reasonably be construed as any indication of probable cause to search. How about they first search the known terrorist's mailbox for the names and addresses he's corresponded with looking for who's replied to him about the plan? Then the authorities can target the searches of specifically those accounts and there isn't this problem.
This is one reason to segregate devices and have firewall rules that control which devices can make outgoing connections. That way you can insure IoT and other devices that have no business talking to the Internet can't talk to the Internet.
I also run a monitoring job that collects MAC addresses and associated IP addresses from the router's ARP cache and reports on unexpected changes. It doesn't make it impossible to slip a device onto my network without it being noticed, but it takes a fair amount more work that the likely intruders won't be putting forth. It also helps find the MAC addresses of new equipment that doesn't like to say what it's MAC address is.
Slashdot Mirror
For me the quality issue seems to be not so much a question of "H1-B or not" as of "contractor or not". Almost all of the H1-Bs I've seen have been brought over from one of the big Indian contracting/outsourcing companies, and the attitude of those companies is very much "get it done as fast as we can and still pass the acceptance tests, don't worry about quality or maintainability because we won't be the ones who have to clean up the mess" (or if they are, it's another contract billed by the hour so the worse the mess the better for them). The large American contracting and consulting firms aren't much if any better in that regard either, which is why I hated it when the contractors or consultants got their fingers into the code.
I can see them being useful.
They're not as must-have as the hype makes them out to be, but they're fairly useful for things many people would want once they know they're there. I would, however, ditch the color screen in favor of monochrome or an e-ink display. Cheaper and consumes less power.
The problem for me isn't the H1-B workforce itself, but the terms of the H1-B visa that make it impossible for the employee (who is not the visa holder) to participate in the workforce. Since the visa is held by the employer and the terms don't give anywhere near enough time between the candidate accepting an offer and his would-be new employer being able to obtain their own H1-B visa for him, he's going to be forced to leave the country and won't be eligible to return to go to work. That essentially locks an employee into one single employer and prevents him from accepting a better offer for his services even if one's made to him. This smacks an awful lot of a form of slavery. It's almost like those companies don't want to compete in the marketplace for the services of their employees.
No, the RJ45 doesn't need redesigned/replaced to make a smaller connector. Right now it's about as small as it can get and still be handled by human fingers without trouble or damage. If it's made too small to handle, what's the point? For a device where connector size is that critical, it's probably better to use WiFi for connectivity and portability and a USB-to-Ethernet adapter if you absolutely need a hard-wired connection.
I'd also point to micro-USB as an example of why smaller isn't better. It's the most fragile, most trouble-prone connector I've ever had the displeasure of working with. It's easy to damage either the cable connector or the socket or both without realizing it, and the damage won't always even be visible when looking into the socket. This are not good things for a connector. On my cel phone I really wish they'd've left the micro-USB connector off and done a better job with the wireless charging (most of the US variants have all the circuitry for it included but they omit the backplate with the necessary antenna loop and connections). WiFi and Bluetooth let me move things around easily enough, and the space would've been better used for an external microSD slot (I've found very few things that can't be moved via a 64GB flash drive).
It's not just work, I know the same thing applies to sports and just about everything people do. Especially as you become good at something it draws you in and you want to go further and get better. Success at something is in a real sense addictive. Eventually you get to the point Robert Heinlein described as: "There is no way to stop. Writers go on writing long after it becomes financially unnecessary... because it hurts less to write than it does not to write."
Up the ante a bit, and have someone with a ham radio license file a complaint, not about WiFi blocking but about an unlicensed operator's (the hotel) interference with a licensed operator's transmissions. The rules about that, IIRC, apply even on the unlicensed bands and give the FCC well-established grounds to shut down the hotel's WiFi completely until it modifies the equipment to eliminate the interference.
Or in Ruby, or Python, or any number of other languages. Java's just another entry in the list here. Frankly I'd've expected the first cross-platform malware to be in Perl, and to have shown up at least 10 years ago. I'm not sure AV tools would even recognize a Perl program as malware...
It wouldn't need to run as a browser plugin. The idea here is to use some other exploit to gain access and drop the .jar file onto the system, then run it as a regular local application. I suspect a lot of people have it because Oracle's made deals to have it included on the manufacturer's images, and those people don't have a clue what Java is or how to remove it so that's a problem.
I am, however, surprised it took them this long to come up with this idea. It's fairly standard on Unix systems, that's how cross-platform scripting of all sorts is done.
NORAD does too much tracking. If a bird deorbits they know which bird it was, who put it into orbit when and from where.
I'd like to see a "repeat offenders" classification for copyright claimants like the copyright holders want for alleged infringers. If more than a certain percentage of your copyright infringement claims turn out to be bogus, your claims get diverted for review and won't be acted on until someone's checked the content and checked with the uploader. Same standard for any automated system, if it can't maintain at least the same level of accuracy expected of claimants then it's results can't be used until after human review.
Less altering the relationship I think than enforcing it. Too many beta testers were, it sounds like, treating the beta test as a sneak preview or early-access program and taking advantage of the offering without providing the feedback that's their part of the agreement. All Microsoft's doing is taking out the switch that lets them avoid being bugged for the feedback they agreed to give. It'll annoy people who were giving feedback but aren't having problems with those particular areas, but they're heavily outnumbered by the people who weren't giving feedback at all. Yet another case of the greedy breaking things for everybody, I suppose.
The "next few minutes" is basically just enough time to give the "abandon ship" order. To be useful the algorithm has to predict the rogue wave far enough in advance to let the ship turn and steam clear of the wave group. In a storm, that's probably 20-30 minutes which I don't see happening any time soon.
Would that be a single interface specification for manufacturers to query activity information? A single specification for insuring devices only work with other devices manufactured or licensed by this alliance?
I'd end with </sarcasm>, but anymore that'd just be immediately followed an another <sarcasm>.
@boggle. I use that software a lot simply to get rid of the forced previews and the like so I can sit down to watch a movie and watch the bloody movie, which ought to tell the MPAA and company something right there. The biggest advocate of piracy right now is the MPAA itself, as they constantly and vocally equate simply watching a movie you've purchased legally with piracy.
I've gotten this a lot with devices besides cameras (eg. an LG G3 phone), even when plugged into a 3.0 port. It seems to be caused only by devices with a standard micro-USB connector, not a full-sized one. My thought is that the device's USB chip is 3.0-capable, but the connector and/or cable don't have the extra pins/wires for 3.0 so the device is reporting itself as 3.0 but can only run as 2.0 which makes Windows complain. I haven't seen any problems because of it, even under Windows (I normally connect the devices to Linux machines).
At the top end, the big tech companies like Google or Microsoft have their own spam-filtering systems in-house. At the bottom, individuals and entities too small to run their own mail servers either depend on Bayesian filtering in their e-mail clients or get email from one of the big tech companies. And in the middle, they either outsource their email to one of the big tech companies or can put together their own spam-filtering solution readily enough using available tools like SpamAssassin that're mostly open-source. End result: there's no market for spam filtering except as part of a complete email provider business on the scale of Google or Microsoft.
Not all development work involves solitary coding. How do you get the latest changes from a co-worker when you can't access the repository you both normally push changes to and his personal machine with his copy of the repository doesn't accept incoming connections (and neither does yours, so you can't have him push the changes to you)? How do you access the branch you didn't know you needed until now which isn't in your local copy? How do you get that refactoring a colleague just committed and pushed before the outage that you need to have because your part of the work's predicated on it? How do you get anything into the build process when the build process pulls from the repository that's offline?
All of those can be worked around, but amusingly what you'd need to do is almost exactly what you'd need to do with a non-distributed version control system.
This is why there's redundancy built into the system, more satellites than are strictly needed for operation. If one's clock goes out-of-spec, you notice that it's not agreeing with the rest of the constellation and drop it from your sources. If it's a transient glitch it'll come back in-spec and come back into use, if it's a permanent problem they decommission it and schedule a replacement. Redundancy makes the difference between a major crisis and a minor annoyance.
Fail.
One of the proposed solutions (that looks like it might be effective), DMARC, isn't even hard to set up. OK, you need DKIM set up properly on your outgoing mail servers, but that's not that hard to do. If I can figure out how to do it, starting from scratch, in an afternoon, any competent enterprise netadmin should be able to do it. Once DKIM's signing mail, DMARC is just a matter of publishing the DNS records. There's reporting software you can install to send reports back to domain owners when your systems receive problematic mail claiming to be from them, but to just let others detect problematic mail you just need the DNS record with your policies published. This is frankly not rocket science here.
And if your mail software doesn't support DKIM or DMARC? Get better mail software.
You don't compromise with reality. Nor with mathematics. It is what it is, if you don't like that it really doesn't care nor does it have to. If the politicians insist on backdoors or "golden keys", their system's going to fail miserably and spectacularly. The only question is exactly what form the fireworks are going to take, and who's going to foot the bill for cleaning up the mess. My vote's that, if they keep insisting on this, we counter by insisting that they foot the bill for failure. We've warned them, why should their refusal to listen make us responsible for fixing the resulting crisis?
I use PWSafe combined with an OwnCloud instance for sync. Devices have their own local copy of the database plus access to the OwnCloud copy, so I can handle even complicated cases of multiple conflicting updates from multiple devices (I usually do changes on a PC and the "master" gets uploaded to OwnCloud automatically, but devices can either change the OwnCloud copy and those changes get merged into the "master" or they can change their local copy and upload that to OwnCloud for merging into the master manually). All the advantages of the cloud without the data ever having to leave my servers.
Mostly it's because changes to the major version of a distribution tend to involve major-version transitions of multiple software packages, which tends to involve non-trivial differences in configuration files that users will have changed from the initial default contents. Packages can contain scripts to help deal with that, but if I'm doing a 21->23 upgrade I need to run both the 21->22 and the 22->23 scripts and that's hard when the 22 packages were never installed and the 21->22 scripts which would've been in those packages aren't available. Solving this in a way that works right on production systems is... doable but nontrivial. And most of the simple ways involve giving up the ability to use multiple repositories.
I wouldn't run it without the authorities being able to meet the requirements for a search warrant. Otherwise you have the problem of copies of the document in the inboxes of people with no involvement whatsoever who were sent the document in a deliberate attempt by the terrorists to bury their tracks in a crowd of false leads. Given that the sender, not the recipient, determines to whom a message is sent, merely receiving a message without anything more doesn't indicate any involvement or intent on the part of the recipient and can't reasonably be construed as any indication of probable cause to search. How about they first search the known terrorist's mailbox for the names and addresses he's corresponded with looking for who's replied to him about the plan? Then the authorities can target the searches of specifically those accounts and there isn't this problem.
This is one reason to segregate devices and have firewall rules that control which devices can make outgoing connections. That way you can insure IoT and other devices that have no business talking to the Internet can't talk to the Internet.
I also run a monitoring job that collects MAC addresses and associated IP addresses from the router's ARP cache and reports on unexpected changes. It doesn't make it impossible to slip a device onto my network without it being noticed, but it takes a fair amount more work that the likely intruders won't be putting forth. It also helps find the MAC addresses of new equipment that doesn't like to say what it's MAC address is.