Counter-argument: Obviously management knew much better than the engineers how to run the Space Shuttle program, so they were entirely right to ignore the engineers' warnings about how freezing temperatures would affect the SRB sealing rings on Challenger and how ice strikes would affect the leading edges of the wings on Columbia.
Every other business is subject to that same degree of government regulation, ie. the laws limiting their ability to disclaim liability and those warranties and requiring things like business licenses. I don't see any reason why software publishers should be subject to any less regulation. Beyond that, tort law's sufficed in most other fields so I don't see why it shouldn't suffice here.
There are, of course, exceptions. Firmware for medical devices, aircraft control software, that sort of thing where people's lives are placed directly at risk should be subject to a higher degree of regulation and standards for software just as it is for every other aspect. And it should be handled the same way, based on the judgement of long-time practitioners in the field. In other words we don't base the rules on what marketing executives think or hot-shot web-app programmers with less than 5 years working experience, we look to the people with 40+ years in the field who've seen (and had to clean up) all the messes and know what caused them and how to prevent them. Which, yes, is probably not going to result in rules the marketing execs like, but life's like that sometimes.
I think we need to also educate people on the difference between software development as a hobby and as a profession.
If I just need to build a storage shed or garden sun-shelter for my backyard, I can build it to any standard of quality, or lack thereof, that I want. It can be completely wonky, as long as it works for me. But if I want to build storage sheds for other people, the rules change. I need to build them to at least a minimum standard of quality, people will expect the trim and paint and the like to not fall off or peel, the doors can't fall off the hinges if you push them wrong, that sort of thing. And if I don't build to those minimum standards I'm going to be held legally liable for the shortcomings.
The same thing applies to software development. Just because you can slap together a to-do list app that works for you, doesn't mean it's ready to market to others. One of the problems is that you can market it without facing any liability for poor quality, and the absolute maximum liability you may face is to have to refund the purchase price. There's no other field where that's the case. Besides education, IMO we need to remove the ability for software publishers to disclaim liability for damages and the implied warranties of merchantability and fitness for purpose. Make it clear that when you move from writing quick apps for yourself or your friends to marketing your software to the public, you're moving into a realm where you're going to be required to meet certain minimum standards of quality whether you like it or not and you'd better be prepared for this.
Yes, this would hurt many software publishers. IMO they need hurt, because the quality of their work is far from what I'd call professional or even reasonable for what they advertise it as.
As far as being able to restrict viewing to only the recipient, that's easy. Every standard mail client today supports it. The hard bit's getting the recipient to generate a public-key certificate and install it as a personal certificate and key in their e-mail client. Then you just encrypt the e-mail using their public key and send it as an S/MIME message, their mail client will automatically decrypt it for them. I could even make that work in web-mail with a browser extension that recognizes the message text block, grabs it and decrypts it and stuffs the results back in the text block for the user to see. The obvious advantages here are that a) you wouldn't need to use any particular service provider to send the mail and b) not even the service provider or e-mail servers would be able to see the cleartext. The hard part's the PKI, and really all that needs is an extension for the mail client to automate generation of a certificate and installation into the client like we have in browsers. Depending on the browser and OS that might be simplified by taking advantage of shared OS cryptography features.
I've kicked this idea around as a commercial possibility, but it all comes down to two basic problems:
- If the messages are truly private it's nigh impossible to generate revenue by any means except annual subscriptions from users. Senders might pay, but recipients won't and that breaks the whole thing.
- Controlling what happens after the message reaches the recipient's nigh-impossible. The best you can do is if you restrict recipients to a platform like mobile where they have to access messages through your app. There's still ways around the controls, but you can make it so the phone has to be rooted and then access to the secure credential storage obtained and that's not something that can be automated enough to be feasible for the average user to do. In an uncontrolled environment like a browser or a regular e-mail client? Forget it.
Usually a requirement for DirectX or ActiveX is for the viewer software they provide, not the camera itself. Either their application uses DirectX to handle the graphics display, or the standard Web page the camera puts around the stream uses an ActiveX widget to display the stream. Usually if you can get the manual for the camera and take a look at the Web page it generates you can find the URL for the actual video stream and use that in any video software. A little more work will give you how to configure the camera for resolution and stream encoding and such to get exactly what you want.
That's actually only partially right. If you pass on the source code along with the binaries, you're only obligated to give the source to people you give the binaries to. But if you make an offer to provide the source, you have to provide the source to anyone who asks. That's because of 6c (GPL v3) or 3c (GPL v2) which allow those you gave binaries to to pass along those binaries and your offer of source code to others. Those bits mean those additional people are entitled to the source through your offer so you can't refuse to give people the source just because you didn't give them binaries direcetly. No, you can't bar recipients from passing along the binaries per those bits without yourself violating your license, except by including the source in what you distribute.
Much the same here. The attraction of G+ was that it was a lot easier to use for non-public streams. Where Facebook tried to make everything public for the world to see, G+ made it easy to keep things limited to specific groups so that a) conversations wouldn't be visible to people I didn't want to see them (and to people that aren't interested, my family really doesn't want to have a ringside seat for my rather heated discussions about the technical aspects of IPv6) and b) we wouldn't be inundated by trolls, spammers and general idjits. I think that's one of the problems, it's not that G+ isn't active but that the outlets saying it's dead are basing that only on public activity which isn't G+'s focus.
Except that most of Silicon Valley can't save money outsourcing to India. Sure they could hire the same number of workers cheaper, but they can't get the same amount of work done on an ongoing basis. They make their money the way US consultants have: swoop in, hack together something that meets requirements enough to get the final payment, then disappear the morning after the release to production. When the company finds all the bugs and problems, their own people have to clean up the mess or the company has to hire a different set of consultants to try and fix things. It's a great gig for the consultants, not so great for the companies afterwards. And word never gets out because it's the higher-ups who hired the consultants and admitting that the whole thing failed would tarnish their reputation so all the problems get firmly swept under the rug (or better yet, blamed on the company employees who had nothing to do with the project but are tasked with supporting it).
Now if you're talking first-line helpdesk or somesuch, you may save money outsourcing that. Your customers will hate you, but you'll save money. But software development, network engineering, database design, system administration, none of that is first-line helpdesk-type stuff. There's a reason companies are finding it cheaper to move work from India and the like back to the US.
That's fairly easy to solve. The problem is that the H-1B is tied to the position at the company more than the employee. So tie the H-1B to the employee (the company making him the offer doesn't need to sponsor and obtain an H-1B for him, his goes with him and the company that brought him in needs to sponsor and obtain another to bring a replacement in) and give him a 3-month grace period if the company terminates him (and he keeps his H-1B until either he leaves the country himself or his 3 months expires). I guarantee we'll see a lot of screaming from the companies using H-1Bs if that's proposed, with the volume correlating directly to how well it'd solve the problem of H-1B abuse.
It's completely about money. It's not that there's not enough qualified workers in the US to fill those jobs. It's that there's not enough that're willing to work for the wages the companies want to pay. Now, normally when demand exceeds supply companies are all about "Well, naturally you're going to have to pay more, that's just the law of supply and demand.". But then the companies are on the short end of that equation, suddenly it's completely unnatural and they want the right to manipulate the supply to get the prices they'd like to pay. And I'd be fine with that if they were willing to say "We don't want to pay US wages, we're moving the company to India where labor's cheaper.". Or even if they were to bring in foreign workers on fair terms where those workers become part of the labor market like everyone else with the same right to take a better offer if one comes along. But not when the companies want to use a system where they can bring in foreign workers but leave their visas tied to the company so the workers can't accept better offers even if they get them because they'll lose their visa before they can get a new one set up.
Free would be nice, but for me it's more a matter of feasibility. Free public transit's not useful if what would be a 15-minute drive by car takes 90 minutes by public transit and still involves a half-mile of walking at either end to get to the nearest transit stop. Ditto, as was the case at my last employer, if there is no public transit in the area where I work. If I could ride public transit, have it take a reasonable amount of time and have stops within a short walk of where I need to go, I'd cheerfully use it even if I had to pay more than the current prices.
Although even then there's still a few problems. For instance, what do I do when I'm bringing home groceries or large items from shopping? I still need some form of car for that stuff, it won't fit on conventional public transit. Frankly I'd love to see self-driving cars adopted on a scale that permits a switch from mass to true public transit: you call a small car to where you are, tell it where you want to go, sit back and wait for it to get there. If you've got stuff, you either call a larger car or have the store put it in an automated delivery vehicle. If you could do this at scale and provide separated lanes with only self-driving vehicles in them, I'd bet the problem of making a self-driving car work would be a lot easier than if they have to deal with unpredictable human-driven cars.
The question comes down to, is access to this site legitimately work-related or not? If it isn't, no access. If it's dangerous, no access. If it's reasonably safe and needed for work, then the user needs access period. No time window, no login, if they need access to that site for work then they should have access to it. Either that site needs removed from the block list entirely, or an exception to the block needs to be made for whatever group needs access (developers may need access to sites that the call center people don't, for example).
From what I read of the vulnerability, it was severe enough to merit the severity level given to it. If you were affected by it. That's the catch. This is the canonical "severe but unlikely" scenario, somewhat like one where cars are known to randomly explode killing everyone within a 10-mile radius but only the Ford Focus will do this and only if it's got the metallic purple paint job that was a custom order and there were only a couple dozen sold. You can't rate it low severity because losing that big a chunk of a major city is hardly "low severity", but you don't want to have everybody fretting about the safety of their cars when it's only a couple dozen people involved. There isn't a good way to describe this kind of scenario except by giving details, even if those details will let black-hats know which cars to steal to use as rolling bombs. And then there's the usefulness of the warning. IMO if the notification doesn't contain either instructions on how to mitigate the vulnerability or enough information that I can work out what the vulnerability is and how to mitigate against it, the notification's of absolutely no use to me. If you can't/won't give me enough information for me to protect my systems then I'd rather you didn't bother with a vulnerability notification, just fix the problem and flag the next release with "important security fix, details are in the changelog". But I'd prefer that you just provide the information.
You mean like the 5GHz band? I'm finding it just perfect, I need 2 APs (one for each floor) but I get good coverage out to the porch and balcony without the signal going too much further. My network's harder to spot and there's less interference with other people so we can cram more networks into the area. Of course I'm also a proponent of wired networking for fixed-location computers so I've usually already got ports near where I want an AP.