Start by giving him tasks maintaining the software. Give him an overview of how things are organized, then give him a task that needs done and answer his questions as they come up. Someone maintaining code will have to know how to figure it out, so let him get started on that now while you're around to answer questions. Once he's done, critique the code with an eye towards how many hidden problems it may have and how well it fits with the system. If he's doing good work, give him progressively more complex tasks.
Once you've got a feel for how he's doing, good or bad, bring some of the management you work for in on the critiques. If he's doing well, this lets you highlight how well you teach your replacement which can lead to good references later. If he's not doing well, this lets you highlight the problems while you can still demonstrate directly that it's not because your software's poorly-designed or poorly-documented and it's not because you're not clearly explaining the system to him.
It's not surprising about Alito. Think about this: if copies made in foreign countries are not lawfully made as far as US copyright law goes, then what about copyrighted works including software manufactured (made) in Asian countries and brought into the US by the manufacturer for sale? Suddenly all those Windows discs that Microsoft has made in cheaper Asian factories? Not legal for sale in the US even if Microsoft themselves is selling them, they weren't lawfully made in accordance with the interpretation of copyright law the lower courts wanted to use.
And the conversation will go something like this:
"There's someone peeping through my window."
"Which window is he at?"
"He's looking in my living-room window."
"So he's at the living-room window?"
"Well, he's out on the sidewalk, but he's looking in through my window."
"He's not up at your window or on your property, then?"
"... no."
"Sir, just close your curtains so he can't see in and call us if he comes on your property. Until he does, it's a public sidewalk.".
"about" has a specific legal meaning here, and it isn't merely "in the vicinity of". If you were up a tree trying to gain a view over a fence, they could ding you. If you were peering through a small hole in a fence to see what you normally wouldn't be able to, they could ding you. Standing on the sidewalk where everyone normally walks? The cops might hassle you, but even they know the DA won't charge you (and if one did, any competent lawyer could get the charges dismissed in 5 minutes and get the DA a good chewing-out by the judge which is why the DA won't charge you in the first place) without something beyond just standing there.
If you don't take any steps to give yourself privacy, the law isn't going to make everyone else go out of their way to give you privacy.
Because people like you keep telling them it's OK to be completely ignorant of things they're going to need to use in everyday life. 20 years ago we could excuse people not being familiar with computers. These days with cel phones being almost universal and computers being something everyone uses every day, it's time to quit making excuses.
If you get out of high school without being able to do basic arithmetic, we don't excuse you and say "Math is hard, we shouldn't expect people to know how to add.". If you own a car and don't know the difference between the steering wheel and the brake pedal, we don't excuse you saying "Cars are complicated, people shouldn't be expected to know how to drive them just to get around in them.". When someone's VCR is flashing 12:00 because they can't figure out "Setup | Clock | Set Time | type in 4 numbers and select AM or PM", we make jokes about it. This is the 21st century, when the quick-start sheet for the whiz-bang new electronic toy you bought says "We recommend you secure your router by going to this URL, going to the Security tab, selecting these settings from the security and encryption drop-downs, typing a password into the password box and hitting OK." and you elect not to bother, it's time to place the blame squarely where it belongs: on you for not following the instructions, not the instructions for not being followable. I mean, come on, it's more complicated than that to set up Netflix or Facebook and people manage those just fine.
And if you read the statutes, it won't be a violation of the law. All of them require either a) trespassing onto the property or b) violation of a reasonable expectation of privacy. You aren't trespassing if you're standing on public property where you'd ordinarily have every right to be standing, and you aren't violating any expectation of privacy if there's nothing in the way that would provide any sort of privacy. A person doesn't have any expectation of privacy standing in front of a window where the curtains and blinds are open and there's no obstructions so they can see the sidewalk as clearly as anyone on the sidewalk could see them. Again, I note the paparazzi, if all those laws applied there'd be no candid photos in the tabloids because all the photogs would be in jail.
Individual end-users don't have the ability to protect themselves. Most have no idea of encryption, much less what data is accessible to someone scanning Wifi frequencies (most people couldn't even tell you what a "frequency" is!). Even if they had the knowledge, they have limited time and resources.
End users have plenty of ability to protect themselves. You don't have to know how encryption works to set a password in your router and switch encryption on. The manuals walk you through all the steps. They even recommend right on the quick-start sheet that you set it up, so there's no excuse for not knowing you should do it. If they have limited time and resources, then it becomes a matter of priorities. If those end users consider their own privacy to be less important than the couple minutes of their time it takes to flip security on on their wireless, I have a hard time finding any sympathy for them when they complain about a lack of privacy. If they don't like it... they need to give their privacy a higher priority. And if you don't want people hearing what you say, don't set up a loudspeaker broadcasting to the entire neighborhood.
If I did that, what law would I be breaking? If I'm not obstructing the sidewalk, not going onto your property and not doing anything to bypass any privacy measures you've put in place (eg. by using a ladder to see over the fence you've put up), exactly what law would I be breaking standing there watching your house?
I think you'll find if you check that it's not a violation of any law. Only if you've taken some steps to insure privacy can I be touched for bypassing those measures. Celebrities have been fighting this for years. It's how the paparazzi get those candid photos and don't end up in jail.
This is a failure of the doctor, not the patient. It means the doctor isn't explaining to the patient what the information means, why it should be interpreted a certain way, what other interpretations there are and why they're wrong, and why a certain course is the best one. I've dealt with too many doctors who get offended at having to explain those "why"s, resulting in me finding another doctor who's a bit more open to keeping me informed. Yes you'll find some idiots who won't listen, but you'll also find a larger number of non-idiots who've decided that your intransigence and refusal to give them information means you don't really know anything and they need to start looking elsewhere.
How will he impose it? On ISPs? My e-mail doesn't go through my ISP. On services like Google? That's going to be fun because most people don't access Google Mail as an e-mail service, they access it as a Web site. How do you determine how much traffic is e-mail and how much is Web site? Nobody's going to want to pay a tax on the traffic spent refreshing a Web site with no e-mail sent or received. On individual users? How does he propose to track their usage given that their systems don't have any internal accounting for stuff like this? And how's he going to deal with non-Windows OSes? I doubt he'd have any legal authority to tell people they must run Windows just because that's the only one he's had software written for.
I see so many technical problems here that I don't think it'll fly even if it manages to get past the political issues.
I telecommute (medical issues), and during the workday I'm expected to be connected via VPN and logged in on the network. That means e-mail and IM up and running. Availability... the only issue there is if I'm away from the computer getting something to eat or dealing with the medical issues. Other than that, the reason I'm not responding is probably that I'm in the middle of assigned work and you haven't tried IMing me (IM windows pop up a notification to get my attention, the downside being I get really grouchy if it turns out it wasn't really an emergency).
If Yahoo had problems with telecommute employees not being available, it sounds like they didn't set things up and manage them properly.
When setting up a test like this, first look at the legitimate e-mails sent around your company. If your business routinely circulates e-mails containing attachments employees are expected to open or links they're expected to click on, then ask yourself why you've got an overlap between what you expect employees to do and what you want them to not do. If you expect employees to check addresses but your e-mail client hides addresses, ask yourself why you're hiding what you want recipients to check. If you're having to ask those kinds of questions then the first problem you need to address isn't employees being vulnerable to spearphishing attacks, it's your internal e-mail culture and standards that make those vulnerabilities normal and expected.
Expect a lot of resistance to fixing these things. Not from your regular workers, from the upper layers of management who like these things because they make life easy and look "Oooh, shiny!".
It's a lot like physical security. You can emphasize it all you want, but when managers get angry at employees who closed the door in the manager's face forcing them to use their own key you will not get employees to stop letting people tailgate through doors.
The major thing for me is that the official documentation is written based on how someone at the vendor thinks the software ought to be used, while StackOverflow shows how it's actually used in common cases.
Example: I needed a custom configuration section for app.config/web.config for a.Net application. I laid out my XML to be readable by the people who'd have to maintain the configuration. When I went to the official documentation, did I find any examples showing common XML layouts and how to translate them into the code to implement them? Nope, not a bit, just examples of "correct" code with snippets of the XML they'd produce. None of which matched common patterns, BTW. I was looking for a simple top-level BUREAUS element containing multiple BUREAU elements with the bureau name as an attribute, each in turn containing multiple KEY elements with name and value attributes to hold each bureau's configuration settings. StackOverflow and other sites were the only places that gave me actual useful examples of taking an XML layout and turning it into the.Net configuration section code matching the XML.
The best thing I can recommend for official documentation is to stop including just the official "this is the way we intend it to work" description. If you intend it to be used one way, explain why this is the best way to use it. And then go looking at sites like StackOverflow for how people actually want to use the APIs. If what people are asking to do doesn't match the intended usage, start asking yourselves "Why?". Think long and hard about it, because in the real world what my boss wants done always, always trumps what the vendor thinks (my boss signs my paycheck, the vendor doesn't). And then adjust your documentation to include examples that line up with what developers are actually asking to do.
So, what happens if as a private citizen I post a notice on my property saying that any unsolicited material deposited on my property will incur a disposal fee of $100 per item, and then bill the YP company for my disposing of the trash they left without permission?
Reminder: freedom of speech does not mean the freedom to use someone else's property without permission. You want to speak, use public property or hire your own hall.
For routine stuff, the automated systems are usually faster and smoother. When I know what to expect, have everything ready and don't have anything exceptional to deal with, I much prefer to punch a few buttons on a machine and be done with it. When I want a human being involved is when the exceptions pop up: there's a problem, or I don't know exactly what to expect or what I need, or I have something that's not part of the normal flow that needs dealt with. That's when I want to take it to a human being who can exercise some judgement or explain to me what's going on. And ideally having the automated systems handling the routine stuff should improve things by freeing up the human reps to concentrate only on those exception cases.
The above, though, is probably why people prefer the machines: all too often the human reps can't apply any discretion or can't explain what's needed. Policies don't allow them any leeway, and hiring and training policies select against actually understanding what's happening. Given the choice between the machine and a human drone who can't do anything except follow the book, most people will go with the machine that'll get it over with quicker.
Probably because Prenda already has a case in Federal court where they're... well, to say they aren't doing well is like saying the Titanic was taking on a bit of water that night in 1912. My guess is the next move on the part of the defendants here is to ask to have these cases consolidated with the preexisting one.
They can, but that again would break all those small kludgy business-critical things that must work correctly for things to get done. The business is trying to prevent that kind of breakage, not break things themselves.
And why should they disable it? The ability to do small quick-and-dirty tasks using macros or VBA without needing to involve IT is one of the advantages the business wanted from those products. Now they should give it up, just because Microsoft finds it inconvenient to not break things? If I were a business, frankly I'd view that as an argument for switching to a more suitable product (especially if said alternative also let me avoid the major UI changes that've come with recent versions of Office, from the ribbon down to Office's stubborn refusal to follow the desktop color scheme like any other Windows application).
First, get a USB keyboard and mouse that you can plug into the laptop (directly or via a hub), so you don't need to use the laptop's keyboard and trackpad. Then set up your display configuration to duplicate the desktop on both monitors. Now you can close or almost close the laptop and slide it under the monitor, or off to one side, out of the way while you work. Alternatively you can extend your desktop across both monitors, set the 27" monitor to be your main display and use the laptop's screen as a secondary monitor. This second option gives you the advantage of being able to set the 27" monitor to a higher resolution than the laptop's screen would support.
It's not even necessarily complex macros or "real" programming. It's the small, kludgy things written by the guys in Finance or Sales or Support to get a particular job done. Usually they're written without a lot of reference to the technical docs, because the guys writing them don't have MSDN subscriptions themselves (don't need them, they aren't developers, IT handles installing whatever software they need). They're written based on what works and gets the job done. And then it gets forgotten about because it doesn't break, it just sits there doing it's job. No one of these is a big thing, when an upgrade breaks it it's probably a 5-minute fix. The problem is that a) that fix requires someone who's familiar with those tools (I'm not, I work on the server side doing the heavy lifting, the guys in Finance and Sales know far more about programming Word and Excel macros and VBA than I do because they do it regularly and I don't), and b) it's not just one thing broken, there's dozens to hundreds scattered all over the place and they aren't documented and often won't even show up as broken until end-of-month or end-of-quarter or end-of-year.
Bluntly put, if you're including a user-accessible macro capability or programming language in your software, then you are supporting non-professionals writing macros and programs. If that will cause problems with your upgrades, then either a) you screwed up your upgrade by not checking that it doesn't break things you support or b) WTF were you thinking including macro and programming capability you didn't intend to support?
If Microsoft can provide corporations a written guarantee that the updates won't break any of the custom programming those corporations use in their applications and documents, it'll fly. The reason corporate IT doesn't update often is they have all these business-critical things lurking, macros used in spreadsheets, document templates, custom internal applications, that must work, and they need to check that updates don't break those things before they can roll the updates out.
You aren't going to be able to sell business on something, even if the price is lower, if it isn't going to give them anything they aren't already getting and it'll increase the costs associated with the business being down while IT fixes what the latest update broke.
Can you point to one that uses a random nonce to insure that responses can't be recorded and reused and can't be predicted before the actual transaction, and that use a process where the hashed form of the password can't simply be treated as the password itself?
That sounds like a challenge/response system. Does the plug-in require that the server send a random nonce? If not, it's vulnerable to replay and pre-play attacks, since without the nonce the hash values are predictable. And with a nonce you should only need one exchange, assuming your hash algorithm is sufficiently robust (if it isn't, I'm afraid no number of repetitions will make the exchange secure).
Note: as has been demonstrated repeatedly over the last decade, any cryptographic system that's vulnerable to something better than a brute-force attack and which depends on computational infeasibility will end up broken in short order, the only question is how quickly advances in hardware will make what was once infeasible trivial.
Also note: the above doesn't mean that systems that are only vulnerable to a brute-force attack won't become vulnerable, only that they're the best we can do. Once hardware advances to the point where it's feasible to brute-force the key, all you can do is find an orders-of-magnitude-harder problem to base your system on.
Unfortunately, as has been demonstrated recently, hashed passwords don't protect very well against attacks either if the intruder gets access to the stored passwords themselves. Faster and cheaper hardware combined with cheap storage have allowed attacks on hashed passwords that would've been infeasible only a few years ago. And hashed passwords on the back-end mean that cleartext passwords almost have to be passed over the wire where they're vulnerable to interception not just by things snooping network traffic but by malware that's inserted itself into the network stack on either end.
And most importantly, storing passwords in the clear makes it perfectly clear that they are vulnerable to any compromise that gives an intruder access to the stored passwords. Having them hashed gives a false sense of security and the opening to argue that compromises don't have to be disclosed because the passwords are hashed and thus haven't really been compromised, even though the hash isn't going to really keep the passwords from being compromised.
I much prefer a system that segregates passwords onto a dedicated authentication service that runs on a machine that's walled off and isolated from even the production machines except for the small hole needed for access to the authentication service (which should be written, at least the input and input-parsing portions, by professional paranoids). Then store passwords on it in the clear if needed so you can use challenge-response authentication methods that avoid needing to transmit the password itself between the client and your systems. That way your efforts to protect the passwords can be concentrated on that authentication server with it's relatively small exposed area, rather than on your entire system with it's large exposure to attacks.
I look at this and look at my entertainment budget and just sigh. I'm trying to get the most value for my dollar out of games, and this... ain' it.
And for multi-player games, there's another factor to consider. If you can buy better weapons/gear/skills/etc., then the game's going to be dominated by the professional players, the ones who're literally making a living playing the game. I've dealt with that kind of situation, and all I can say is I don't need the hassle. Especially if there's any sort of PvP component to the game. Being forced to spend my hard-earned money to stay on even footing with them... not my idea of a fun way to spend an evening. Frankly I'd rather wrestle with a nasty graph-theory problem involving logistics and determining optimal routes, and that's the kind of thing that gives most non-certifiably-insane people migraines. When that's more fun than the idea behind a game mechanic...
They need things more basic than understanding of the hardware. If it were just that they don't understand the speed trade-offs of various storage, I'd be overjoyed. No, these are people who don't understand the concept of factoring out common functionality so you only have to implement it once, and why this is a good idea. Even though they've just gotten done whinging about having to fix the same exact bug for the fifth time because the same code was implemented in 5 different places, each one using different variable names so scans for other occurrences of one copy don't pick up the others.
Slashdot Mirror
Start by giving him tasks maintaining the software. Give him an overview of how things are organized, then give him a task that needs done and answer his questions as they come up. Someone maintaining code will have to know how to figure it out, so let him get started on that now while you're around to answer questions. Once he's done, critique the code with an eye towards how many hidden problems it may have and how well it fits with the system. If he's doing good work, give him progressively more complex tasks.
Once you've got a feel for how he's doing, good or bad, bring some of the management you work for in on the critiques. If he's doing well, this lets you highlight how well you teach your replacement which can lead to good references later. If he's not doing well, this lets you highlight the problems while you can still demonstrate directly that it's not because your software's poorly-designed or poorly-documented and it's not because you're not clearly explaining the system to him.
It's not surprising about Alito. Think about this: if copies made in foreign countries are not lawfully made as far as US copyright law goes, then what about copyrighted works including software manufactured (made) in Asian countries and brought into the US by the manufacturer for sale? Suddenly all those Windows discs that Microsoft has made in cheaper Asian factories? Not legal for sale in the US even if Microsoft themselves is selling them, they weren't lawfully made in accordance with the interpretation of copyright law the lower courts wanted to use.
And the conversation will go something like this:
"There's someone peeping through my window."
"Which window is he at?"
"He's looking in my living-room window."
"So he's at the living-room window?"
"Well, he's out on the sidewalk, but he's looking in through my window."
"He's not up at your window or on your property, then?"
"... no."
"Sir, just close your curtains so he can't see in and call us if he comes on your property. Until he does, it's a public sidewalk.".
"about" has a specific legal meaning here, and it isn't merely "in the vicinity of". If you were up a tree trying to gain a view over a fence, they could ding you. If you were peering through a small hole in a fence to see what you normally wouldn't be able to, they could ding you. Standing on the sidewalk where everyone normally walks? The cops might hassle you, but even they know the DA won't charge you (and if one did, any competent lawyer could get the charges dismissed in 5 minutes and get the DA a good chewing-out by the judge which is why the DA won't charge you in the first place) without something beyond just standing there.
If you don't take any steps to give yourself privacy, the law isn't going to make everyone else go out of their way to give you privacy.
Because people like you keep telling them it's OK to be completely ignorant of things they're going to need to use in everyday life. 20 years ago we could excuse people not being familiar with computers. These days with cel phones being almost universal and computers being something everyone uses every day, it's time to quit making excuses.
If you get out of high school without being able to do basic arithmetic, we don't excuse you and say "Math is hard, we shouldn't expect people to know how to add.". If you own a car and don't know the difference between the steering wheel and the brake pedal, we don't excuse you saying "Cars are complicated, people shouldn't be expected to know how to drive them just to get around in them.". When someone's VCR is flashing 12:00 because they can't figure out "Setup | Clock | Set Time | type in 4 numbers and select AM or PM", we make jokes about it. This is the 21st century, when the quick-start sheet for the whiz-bang new electronic toy you bought says "We recommend you secure your router by going to this URL, going to the Security tab, selecting these settings from the security and encryption drop-downs, typing a password into the password box and hitting OK." and you elect not to bother, it's time to place the blame squarely where it belongs: on you for not following the instructions, not the instructions for not being followable. I mean, come on, it's more complicated than that to set up Netflix or Facebook and people manage those just fine.
And if you read the statutes, it won't be a violation of the law. All of them require either a) trespassing onto the property or b) violation of a reasonable expectation of privacy. You aren't trespassing if you're standing on public property where you'd ordinarily have every right to be standing, and you aren't violating any expectation of privacy if there's nothing in the way that would provide any sort of privacy. A person doesn't have any expectation of privacy standing in front of a window where the curtains and blinds are open and there's no obstructions so they can see the sidewalk as clearly as anyone on the sidewalk could see them. Again, I note the paparazzi, if all those laws applied there'd be no candid photos in the tabloids because all the photogs would be in jail.
End users have plenty of ability to protect themselves. You don't have to know how encryption works to set a password in your router and switch encryption on. The manuals walk you through all the steps. They even recommend right on the quick-start sheet that you set it up, so there's no excuse for not knowing you should do it. If they have limited time and resources, then it becomes a matter of priorities. If those end users consider their own privacy to be less important than the couple minutes of their time it takes to flip security on on their wireless, I have a hard time finding any sympathy for them when they complain about a lack of privacy. If they don't like it... they need to give their privacy a higher priority. And if you don't want people hearing what you say, don't set up a loudspeaker broadcasting to the entire neighborhood.
If I did that, what law would I be breaking? If I'm not obstructing the sidewalk, not going onto your property and not doing anything to bypass any privacy measures you've put in place (eg. by using a ladder to see over the fence you've put up), exactly what law would I be breaking standing there watching your house?
I think you'll find if you check that it's not a violation of any law. Only if you've taken some steps to insure privacy can I be touched for bypassing those measures. Celebrities have been fighting this for years. It's how the paparazzi get those candid photos and don't end up in jail.
This is a failure of the doctor, not the patient. It means the doctor isn't explaining to the patient what the information means, why it should be interpreted a certain way, what other interpretations there are and why they're wrong, and why a certain course is the best one. I've dealt with too many doctors who get offended at having to explain those "why"s, resulting in me finding another doctor who's a bit more open to keeping me informed. Yes you'll find some idiots who won't listen, but you'll also find a larger number of non-idiots who've decided that your intransigence and refusal to give them information means you don't really know anything and they need to start looking elsewhere.
How will he impose it? On ISPs? My e-mail doesn't go through my ISP. On services like Google? That's going to be fun because most people don't access Google Mail as an e-mail service, they access it as a Web site. How do you determine how much traffic is e-mail and how much is Web site? Nobody's going to want to pay a tax on the traffic spent refreshing a Web site with no e-mail sent or received. On individual users? How does he propose to track their usage given that their systems don't have any internal accounting for stuff like this? And how's he going to deal with non-Windows OSes? I doubt he'd have any legal authority to tell people they must run Windows just because that's the only one he's had software written for.
I see so many technical problems here that I don't think it'll fly even if it manages to get past the political issues.
I telecommute (medical issues), and during the workday I'm expected to be connected via VPN and logged in on the network. That means e-mail and IM up and running. Availability... the only issue there is if I'm away from the computer getting something to eat or dealing with the medical issues. Other than that, the reason I'm not responding is probably that I'm in the middle of assigned work and you haven't tried IMing me (IM windows pop up a notification to get my attention, the downside being I get really grouchy if it turns out it wasn't really an emergency).
If Yahoo had problems with telecommute employees not being available, it sounds like they didn't set things up and manage them properly.
When setting up a test like this, first look at the legitimate e-mails sent around your company. If your business routinely circulates e-mails containing attachments employees are expected to open or links they're expected to click on, then ask yourself why you've got an overlap between what you expect employees to do and what you want them to not do. If you expect employees to check addresses but your e-mail client hides addresses, ask yourself why you're hiding what you want recipients to check. If you're having to ask those kinds of questions then the first problem you need to address isn't employees being vulnerable to spearphishing attacks, it's your internal e-mail culture and standards that make those vulnerabilities normal and expected.
Expect a lot of resistance to fixing these things. Not from your regular workers, from the upper layers of management who like these things because they make life easy and look "Oooh, shiny!".
It's a lot like physical security. You can emphasize it all you want, but when managers get angry at employees who closed the door in the manager's face forcing them to use their own key you will not get employees to stop letting people tailgate through doors.
The major thing for me is that the official documentation is written based on how someone at the vendor thinks the software ought to be used, while StackOverflow shows how it's actually used in common cases.
Example: I needed a custom configuration section for app.config/web.config for a .Net application. I laid out my XML to be readable by the people who'd have to maintain the configuration. When I went to the official documentation, did I find any examples showing common XML layouts and how to translate them into the code to implement them? Nope, not a bit, just examples of "correct" code with snippets of the XML they'd produce. None of which matched common patterns, BTW. I was looking for a simple top-level BUREAUS element containing multiple BUREAU elements with the bureau name as an attribute, each in turn containing multiple KEY elements with name and value attributes to hold each bureau's configuration settings. StackOverflow and other sites were the only places that gave me actual useful examples of taking an XML layout and turning it into the .Net configuration section code matching the XML.
The best thing I can recommend for official documentation is to stop including just the official "this is the way we intend it to work" description. If you intend it to be used one way, explain why this is the best way to use it. And then go looking at sites like StackOverflow for how people actually want to use the APIs. If what people are asking to do doesn't match the intended usage, start asking yourselves "Why?". Think long and hard about it, because in the real world what my boss wants done always, always trumps what the vendor thinks (my boss signs my paycheck, the vendor doesn't). And then adjust your documentation to include examples that line up with what developers are actually asking to do.
So, what happens if as a private citizen I post a notice on my property saying that any unsolicited material deposited on my property will incur a disposal fee of $100 per item, and then bill the YP company for my disposing of the trash they left without permission?
Reminder: freedom of speech does not mean the freedom to use someone else's property without permission. You want to speak, use public property or hire your own hall.
For routine stuff, the automated systems are usually faster and smoother. When I know what to expect, have everything ready and don't have anything exceptional to deal with, I much prefer to punch a few buttons on a machine and be done with it. When I want a human being involved is when the exceptions pop up: there's a problem, or I don't know exactly what to expect or what I need, or I have something that's not part of the normal flow that needs dealt with. That's when I want to take it to a human being who can exercise some judgement or explain to me what's going on. And ideally having the automated systems handling the routine stuff should improve things by freeing up the human reps to concentrate only on those exception cases.
The above, though, is probably why people prefer the machines: all too often the human reps can't apply any discretion or can't explain what's needed. Policies don't allow them any leeway, and hiring and training policies select against actually understanding what's happening. Given the choice between the machine and a human drone who can't do anything except follow the book, most people will go with the machine that'll get it over with quicker.
Probably because Prenda already has a case in Federal court where they're... well, to say they aren't doing well is like saying the Titanic was taking on a bit of water that night in 1912. My guess is the next move on the part of the defendants here is to ask to have these cases consolidated with the preexisting one.
They can, but that again would break all those small kludgy business-critical things that must work correctly for things to get done. The business is trying to prevent that kind of breakage, not break things themselves.
And why should they disable it? The ability to do small quick-and-dirty tasks using macros or VBA without needing to involve IT is one of the advantages the business wanted from those products. Now they should give it up, just because Microsoft finds it inconvenient to not break things? If I were a business, frankly I'd view that as an argument for switching to a more suitable product (especially if said alternative also let me avoid the major UI changes that've come with recent versions of Office, from the ribbon down to Office's stubborn refusal to follow the desktop color scheme like any other Windows application).
First, get a USB keyboard and mouse that you can plug into the laptop (directly or via a hub), so you don't need to use the laptop's keyboard and trackpad. Then set up your display configuration to duplicate the desktop on both monitors. Now you can close or almost close the laptop and slide it under the monitor, or off to one side, out of the way while you work. Alternatively you can extend your desktop across both monitors, set the 27" monitor to be your main display and use the laptop's screen as a secondary monitor. This second option gives you the advantage of being able to set the 27" monitor to a higher resolution than the laptop's screen would support.
It's not even necessarily complex macros or "real" programming. It's the small, kludgy things written by the guys in Finance or Sales or Support to get a particular job done. Usually they're written without a lot of reference to the technical docs, because the guys writing them don't have MSDN subscriptions themselves (don't need them, they aren't developers, IT handles installing whatever software they need). They're written based on what works and gets the job done. And then it gets forgotten about because it doesn't break, it just sits there doing it's job. No one of these is a big thing, when an upgrade breaks it it's probably a 5-minute fix. The problem is that a) that fix requires someone who's familiar with those tools (I'm not, I work on the server side doing the heavy lifting, the guys in Finance and Sales know far more about programming Word and Excel macros and VBA than I do because they do it regularly and I don't), and b) it's not just one thing broken, there's dozens to hundreds scattered all over the place and they aren't documented and often won't even show up as broken until end-of-month or end-of-quarter or end-of-year.
Bluntly put, if you're including a user-accessible macro capability or programming language in your software, then you are supporting non-professionals writing macros and programs. If that will cause problems with your upgrades, then either a) you screwed up your upgrade by not checking that it doesn't break things you support or b) WTF were you thinking including macro and programming capability you didn't intend to support?
If Microsoft can provide corporations a written guarantee that the updates won't break any of the custom programming those corporations use in their applications and documents, it'll fly. The reason corporate IT doesn't update often is they have all these business-critical things lurking, macros used in spreadsheets, document templates, custom internal applications, that must work, and they need to check that updates don't break those things before they can roll the updates out.
You aren't going to be able to sell business on something, even if the price is lower, if it isn't going to give them anything they aren't already getting and it'll increase the costs associated with the business being down while IT fixes what the latest update broke.
Can you point to one that uses a random nonce to insure that responses can't be recorded and reused and can't be predicted before the actual transaction, and that use a process where the hashed form of the password can't simply be treated as the password itself?
That sounds like a challenge/response system. Does the plug-in require that the server send a random nonce? If not, it's vulnerable to replay and pre-play attacks, since without the nonce the hash values are predictable. And with a nonce you should only need one exchange, assuming your hash algorithm is sufficiently robust (if it isn't, I'm afraid no number of repetitions will make the exchange secure).
Note: as has been demonstrated repeatedly over the last decade, any cryptographic system that's vulnerable to something better than a brute-force attack and which depends on computational infeasibility will end up broken in short order, the only question is how quickly advances in hardware will make what was once infeasible trivial.
Also note: the above doesn't mean that systems that are only vulnerable to a brute-force attack won't become vulnerable, only that they're the best we can do. Once hardware advances to the point where it's feasible to brute-force the key, all you can do is find an orders-of-magnitude-harder problem to base your system on.
Unfortunately, as has been demonstrated recently, hashed passwords don't protect very well against attacks either if the intruder gets access to the stored passwords themselves. Faster and cheaper hardware combined with cheap storage have allowed attacks on hashed passwords that would've been infeasible only a few years ago. And hashed passwords on the back-end mean that cleartext passwords almost have to be passed over the wire where they're vulnerable to interception not just by things snooping network traffic but by malware that's inserted itself into the network stack on either end.
And most importantly, storing passwords in the clear makes it perfectly clear that they are vulnerable to any compromise that gives an intruder access to the stored passwords. Having them hashed gives a false sense of security and the opening to argue that compromises don't have to be disclosed because the passwords are hashed and thus haven't really been compromised, even though the hash isn't going to really keep the passwords from being compromised.
I much prefer a system that segregates passwords onto a dedicated authentication service that runs on a machine that's walled off and isolated from even the production machines except for the small hole needed for access to the authentication service (which should be written, at least the input and input-parsing portions, by professional paranoids). Then store passwords on it in the clear if needed so you can use challenge-response authentication methods that avoid needing to transmit the password itself between the client and your systems. That way your efforts to protect the passwords can be concentrated on that authentication server with it's relatively small exposed area, rather than on your entire system with it's large exposure to attacks.
I look at this and look at my entertainment budget and just sigh. I'm trying to get the most value for my dollar out of games, and this... ain' it.
And for multi-player games, there's another factor to consider. If you can buy better weapons/gear/skills/etc., then the game's going to be dominated by the professional players, the ones who're literally making a living playing the game. I've dealt with that kind of situation, and all I can say is I don't need the hassle. Especially if there's any sort of PvP component to the game. Being forced to spend my hard-earned money to stay on even footing with them... not my idea of a fun way to spend an evening. Frankly I'd rather wrestle with a nasty graph-theory problem involving logistics and determining optimal routes, and that's the kind of thing that gives most non-certifiably-insane people migraines. When that's more fun than the idea behind a game mechanic...
They need things more basic than understanding of the hardware. If it were just that they don't understand the speed trade-offs of various storage, I'd be overjoyed. No, these are people who don't understand the concept of factoring out common functionality so you only have to implement it once, and why this is a good idea. Even though they've just gotten done whinging about having to fix the same exact bug for the fifth time because the same code was implemented in 5 different places, each one using different variable names so scans for other occurrences of one copy don't pick up the others.