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.
Their extension can't affect the recipient's end of things if the recipient isn't also running that extension. In that case nothing Dmail can do can prevent the recipient from saving the message, forwarding it or doing anything else with it. Dmail can play tricks with HTML e-mail by replacing the body of the e-mail with a dummy wrapper that fetches the message via HTTP from a Dmail server and they can use some Javascript tricks to try and block "Save as", but those are going to run into problems with anything that blocks remote content or disables Javascript in e-mail. Even if the recipient's using Gmail in Chrome that's going to be an issue considering how that sort of blocking's basic to blocking malware. And of course if the recipient's running a non-browser client using IMAP4, Dmail's completely out of luck.
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.
Re:wrong wrong wrong about copyleft
on
On Being Pro-GPL
·
· Score: 4, Informative
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.
ISAGN for an e-mail system that makes it easy to get an x.509 certificate associated with your e-mail address, pull in the certificates for other users so you can automatically encrypt messages to them, and handles all encryption/decryption on the client side (whether in an application like Thunderbird or in client-side Javascript in a Web browser). The infrastructure's there except for the ability to generate a CSR or retrieve a certificate in e-mail clients. In fact with client support it's not even necessary to use any one service for anything but certificate generation/lookup, the encrypted messages can travel over standard e-mail channels. Let 'em ask for anything they want when everything's encrypted and I never had the keys at any point.
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.
Because Sendmail and other MTAs don't have the message by that point. It's in the recipient's mailbox, and it's probably an IMAP server that has it at that point. Assuming their mail client hasn't downloaded it. The general rule is that only the user gives orders about their mailbox, so you aren't going to be able to order it to delete their messages. Their mail client definitely isn't going to comply without at least asking them first, and many people set them to refuse such requests to avoid complications.
Bluntly put, don't expect to have any control over what happens to a message once it leaves your hands because you're no longer in control of it.
More like they've decided their salary's necessary to keep a roof over their family's heads and food on the table, and they aren't willing to risk that when the boss says "Work however much I tell you to or I'll replace you with someone who will.".
The pollsters can blame telemarketing for this. The ban on recorded/automated calls and restrictions on other calls to cel phones came about because those calls cost the cel-phone owner money (either real money or minutes they paid real money for) to receive and telemarketing calls were chewing up too large a chunk for most people to just shrug off. People ignore or hang up on polling calls because at the start they sound indistinguishable from recorded/automated telemarketing calls and it simply isn't worth the time to listen long enough to separate the two when most of the time it'll be a telemarketer anyway. The laws came about because the telemarketers insisted on calling in such numbers, at such inconvenient hours, despite all protests by the public that it finally reached an intolerable level.
As usual, a small bunch of greedy, inconsiderate jerks screw things up for everybody else.
Why tie your email to your ISP? I ignore my ISP's email service except for email from them about my account. If I were you I'd set up an email account with another service and use that as my primary email. That way when I change ISPs (and I will, whether because I moved or because I got fed up with crappy Internet service) I don't have to worry about changing my email address everywhere. In fact it might not hurt to have accounts at more than one email service, so you have an established backup in case it's needed.
Not technically, no, but the way things work in practical reality if the customer isn't the commenter it's someone else in that household and the customer will very likely be able to point the finger at them. The only problem might be if they're running open WiFi, otherwise all the methods you describe involve way too much effort and/or technical chops for a random person to put into just making a comment like this. When option A is 95% likely and option B is 5% likely, B might happen but that's not the way to bet.
It'd be too easy for authors to set up an alternative Kindle store, for one thing. The DRM's well-understood and there's many options around for stripping the DRM off AZW* files, if it can be decoded it can almost certainly encoded as well. The only thing different for the customer would be having to enter the serial number of their Kindle by hand rather than having the Kindle upload it as part of the registration process like it does with Amazon. Or you can go the Baen route and publish without DRM. It wouldn't take Goodreads or other index sites much to add pointers to author stores, and then all that Amazon has to offer is a single checkout.
Note that Amazon already does this for Android: they don't like Google's restrictions on apps so they built their own app store and version of the Play Store app and sell apps directly to users. They already know how easy it'd be for authors to cut them out of the loop entirely. And amusingly enough the authors would probably use AWS instances for their sites and stores, so Amazon would be in a way helping the authors to cut Amazon out of the loop.
This isn't going to affect the majority of books. It's strictly for the Kindle Unlimited and Kindle Online Lending Library portions, where customers can read the book without buying it. Simply don't make your books available through those programs, or limit them to initial books in a series or those likely to hook readers into wanting more of your works. Basically juggle the benefits of KU/KOLL exposure generating additional sales vs. the potential cost in royalties.
That's easy enough to deal with, and the schedulers involved should already deal with it. It's not like the difference between level-triggered and edge-triggered events is something new or novel, how do you think those same schedulers handle the twice-yearly DST transitions that involve adding or dropping an entire hour to/from the clock? Just as handling those transitions involves discarding the misconception that a day is always 24 hours long, dealing with leap seconds correctly involves discarding the idea that a minute is always 60 seconds long. In the process you'll also realize why Unix cron schedules at the start of an interval, not the end (events trigger at the start of an hour, day etc., not on the last second of the hour/day/whatever).
Universal Apps are good for tablet-oriented apps that would be useful on a desktop. They could, with a bit of tweaking, be used to allow some phone apps to run on the desktop, but the form factor demands UI differences that make them awkward to use with desktop conventions. The problem isn't making the applications portable. That's the easy part. The hard part is dealing with the fact that phones and tablets demand a different type of UI than a desktop PC to deal with the drastic difference in physical screen size and available types of I/O.
I'm wondering how long it'll take for the Android version of Skype to disappear...
Mostly my list of desirable qualities is similar. I disagree about the "meaningless" part though. The one about "Any particular process artifact is probably irrelevant." is instantly clear to me. He's saying that it's the result of process that matters, not the specific bits that go into it, which is something more managers need to grasp. You need to use what works for the way your team works together, and you can't get so attached to one particular thing that you can't throw it out and replace it if it's not going to be a good fit with your team. The goal, after all, isn't to fit a set of specific methods together in a certain order, is it? No, it's to get the software done on time, to spec and without errors.
Slashdot Mirror
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.
Their extension can't affect the recipient's end of things if the recipient isn't also running that extension. In that case nothing Dmail can do can prevent the recipient from saving the message, forwarding it or doing anything else with it. Dmail can play tricks with HTML e-mail by replacing the body of the e-mail with a dummy wrapper that fetches the message via HTTP from a Dmail server and they can use some Javascript tricks to try and block "Save as", but those are going to run into problems with anything that blocks remote content or disables Javascript in e-mail. Even if the recipient's using Gmail in Chrome that's going to be an issue considering how that sort of blocking's basic to blocking malware. And of course if the recipient's running a non-browser client using IMAP4, Dmail's completely out of luck.
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:
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.
ISAGN for an e-mail system that makes it easy to get an x.509 certificate associated with your e-mail address, pull in the certificates for other users so you can automatically encrypt messages to them, and handles all encryption/decryption on the client side (whether in an application like Thunderbird or in client-side Javascript in a Web browser). The infrastructure's there except for the ability to generate a CSR or retrieve a certificate in e-mail clients. In fact with client support it's not even necessary to use any one service for anything but certificate generation/lookup, the encrypted messages can travel over standard e-mail channels. Let 'em ask for anything they want when everything's encrypted and I never had the keys at any point.
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.
Because Sendmail and other MTAs don't have the message by that point. It's in the recipient's mailbox, and it's probably an IMAP server that has it at that point. Assuming their mail client hasn't downloaded it. The general rule is that only the user gives orders about their mailbox, so you aren't going to be able to order it to delete their messages. Their mail client definitely isn't going to comply without at least asking them first, and many people set them to refuse such requests to avoid complications.
Bluntly put, don't expect to have any control over what happens to a message once it leaves your hands because you're no longer in control of it.
More like they've decided their salary's necessary to keep a roof over their family's heads and food on the table, and they aren't willing to risk that when the boss says "Work however much I tell you to or I'll replace you with someone who will.".
The pollsters can blame telemarketing for this. The ban on recorded/automated calls and restrictions on other calls to cel phones came about because those calls cost the cel-phone owner money (either real money or minutes they paid real money for) to receive and telemarketing calls were chewing up too large a chunk for most people to just shrug off. People ignore or hang up on polling calls because at the start they sound indistinguishable from recorded/automated telemarketing calls and it simply isn't worth the time to listen long enough to separate the two when most of the time it'll be a telemarketer anyway. The laws came about because the telemarketers insisted on calling in such numbers, at such inconvenient hours, despite all protests by the public that it finally reached an intolerable level.
As usual, a small bunch of greedy, inconsiderate jerks screw things up for everybody else.
Why tie your email to your ISP? I ignore my ISP's email service except for email from them about my account. If I were you I'd set up an email account with another service and use that as my primary email. That way when I change ISPs (and I will, whether because I moved or because I got fed up with crappy Internet service) I don't have to worry about changing my email address everywhere. In fact it might not hurt to have accounts at more than one email service, so you have an established backup in case it's needed.
Not technically, no, but the way things work in practical reality if the customer isn't the commenter it's someone else in that household and the customer will very likely be able to point the finger at them. The only problem might be if they're running open WiFi, otherwise all the methods you describe involve way too much effort and/or technical chops for a random person to put into just making a comment like this. When option A is 95% likely and option B is 5% likely, B might happen but that's not the way to bet.
It'd be too easy for authors to set up an alternative Kindle store, for one thing. The DRM's well-understood and there's many options around for stripping the DRM off AZW* files, if it can be decoded it can almost certainly encoded as well. The only thing different for the customer would be having to enter the serial number of their Kindle by hand rather than having the Kindle upload it as part of the registration process like it does with Amazon. Or you can go the Baen route and publish without DRM. It wouldn't take Goodreads or other index sites much to add pointers to author stores, and then all that Amazon has to offer is a single checkout.
Note that Amazon already does this for Android: they don't like Google's restrictions on apps so they built their own app store and version of the Play Store app and sell apps directly to users. They already know how easy it'd be for authors to cut them out of the loop entirely. And amusingly enough the authors would probably use AWS instances for their sites and stores, so Amazon would be in a way helping the authors to cut Amazon out of the loop.
This isn't going to affect the majority of books. It's strictly for the Kindle Unlimited and Kindle Online Lending Library portions, where customers can read the book without buying it. Simply don't make your books available through those programs, or limit them to initial books in a series or those likely to hook readers into wanting more of your works. Basically juggle the benefits of KU/KOLL exposure generating additional sales vs. the potential cost in royalties.
That's easy enough to deal with, and the schedulers involved should already deal with it. It's not like the difference between level-triggered and edge-triggered events is something new or novel, how do you think those same schedulers handle the twice-yearly DST transitions that involve adding or dropping an entire hour to/from the clock? Just as handling those transitions involves discarding the misconception that a day is always 24 hours long, dealing with leap seconds correctly involves discarding the idea that a minute is always 60 seconds long. In the process you'll also realize why Unix cron schedules at the start of an interval, not the end (events trigger at the start of an hour, day etc., not on the last second of the hour/day/whatever).
Universal Apps are good for tablet-oriented apps that would be useful on a desktop. They could, with a bit of tweaking, be used to allow some phone apps to run on the desktop, but the form factor demands UI differences that make them awkward to use with desktop conventions. The problem isn't making the applications portable. That's the easy part. The hard part is dealing with the fact that phones and tablets demand a different type of UI than a desktop PC to deal with the drastic difference in physical screen size and available types of I/O.
I'm wondering how long it'll take for the Android version of Skype to disappear...
Mostly my list of desirable qualities is similar. I disagree about the "meaningless" part though. The one about "Any particular process artifact is probably irrelevant." is instantly clear to me. He's saying that it's the result of process that matters, not the specific bits that go into it, which is something more managers need to grasp. You need to use what works for the way your team works together, and you can't get so attached to one particular thing that you can't throw it out and replace it if it's not going to be a good fit with your team. The goal, after all, isn't to fit a set of specific methods together in a certain order, is it? No, it's to get the software done on time, to spec and without errors.