If I have a roof I am going to want to replace it as close to it's expected life as possible.
That's why I think comparing it to machinery that needs maintenance, rather than something you'd just wait until it breaks. Software is a complex system with moving parts, not a roof. It's not about always having the latest and greatest, but the truth is, it very well may be more expensive to go straight from SQL 2005 to 2015 (or whatever comes next) than to go 2005 to 2008 to 2012 to 2015. It's impossible to say which will be more expensive when 2008 is just being released, since you don't know what will change between 2008 and 2015 when 2015 isn't a product yet. But even in hindsight, it's very difficult to calculate those kinds of costs.
The problem with not having someone maintain your code is that you lose time and productivity due to things like, "poor performance that might have been fixed if you had someone working occasionally to improve things," and "bugs that aren't very serious so we never bother to get them fixed." I don't care how brilliant you think business owners are, they aren't able to capture that kind of data clearly. But then when you do get around to upgrading from 2005 to 2015, it's possible that you'll have to upgrade to 2008 or 2012 first anyway, since there may be no other upgrade path. If there are major changes, then the upgrade will tend to be bumpy, and you're more likely to see show-stopper bugs as you make the change. All that will be made worse because you won't have anyone around that's familiar with the code you're upgrading. Not only will there be bigger problems, bigger delays, and more loss of productivity, but you're more likely to run into some catastrophic error.
But even in hindsight, it's impossible to know how close you came to a catastrophic error. It's impossible to know how much quicker and smoother the upgrade process could have gone if someone had been familiar with your code. It's very hard to track how much productivity you lost due to small bugs and minor delays. That's in hindsight. Starting in 2005 when you kicked off the project, you have no way of guessing what you'll run into without support.
So to me, if there were a factory owner who said, "My whole business relies on this on piece of custom built machinery. I'm not going to do maintenance. I'm not going to secure a source of replacement parts. I'm just going to run it into the ground, and when it dies, I'll figure out how to rebuild it then." then whatever, it's his factory. If he thinks that's going to be the most effective way forward, go for it. But I won't feel sorry for him if it breaks down after 5 years and he complains, "But it's too expensive to rebuild it!"
He is probably not figuring into his maintenance costs the fact that the engineer did a crappy job making sure the machine had a solid surface to sit on, and now the floor is buckling under the machine, requiring extensive repairs to both the floor and the machine.
Well if he's going to hire crappy engineers and architects, maybe he should figure in those maintenance costs. He should probably budget a little extra for unexpected problems either way.
So my question is: when custom software is created/deployed, is the business made aware of the maintenance costs?
It should be. If the developers are external/outsourced, then there should be some kind of structured agreement for maintenance, bug fixes, enhancements, and upgrades. It probably won't all be rolled into a flat fee, but some of it may be. If you've hired programmers to make a complex, business critical application, and they haven't raised the issue of maintenance, then they're either incompetent or dishonest.
Yes, but factory owners will continue repairing that old machinery (even fabricating new parts themselves if needed) as long as the machine suits the needs of the business, no matter how old the machinery gets.
Yes, but that is largely my point: you don't just buy the machine and expect it to keep working forever. You'll need to plan to buy replacement parts and hire people to perform maintenance and upkeep on an ongoing basis. You'll need to plan to have an ongoing expense that is "maintenance and upkeep". You may need to have a plan for changing your vendor for replacement parts, or to fabricate the parts yourself if vendors discontinue them. It takes time and work and money and expertise.
So where I think you're wrong is when you say the following: "As long as it suits the needs of the business (and not the whims of the IT staff) it will continue to be used and there is no need to spend more money on it." (emphasis mine)
Expect to spend money on it. Expect that the software will need to have bug fixes and updates. Even if you don't want to add functionality, you will need to upgrade it to run on newer platforms. If you use APIs to integrate with Microsoft Office, then plan to keep those up to date as new versions of Office are released. If you're using SQL Server 2005 on the back end, expect that someday you'll want to move to 2008 or 2012. You can keep the code-base, but you're going to have to keep programmers busy doing regular updates and maintenance on a regular basis.
Sure, you *could* just keep Windows XP running IE6 on computers that are 7 years old, accessing a database on an old unmaintained application. Just like a factory *could* build a bunch of custom machinery, fire all the people who built it, and refuse to spend money on simple maintenance. In both cases, you'd be fine for a little while.
When a piece of software is integral to a business, and there is no simple upgrade path, sometimes the cheapest (and *correct*) option is to stay on an "outdated" platform. Often, mitigating the issues with the old systems are cheaper than upgrading the software (if that is even possible).
Yes, but that doesn't really contradict the previous post. Staying on the "outdated" platform is still a short-term solution aimed at keeping costs low. Don't get me wrong, it might be a great short-term solution. Sometimes what you need is a short-term stop-gap until a long-term solution becomes more feasible.
On the other hand, if you're sticking with a short-term solution and you aren't also actively working on a better long-term solution, then you're just kicking the can down the road.
It costs money to redevelop a system with 10 years of development. Not 10 years worth- but easily 5 years worth and that's after 3 years of having a smaller staff analyze the problem...Because they do NOT want to hire the 30 programmers and pay them for 3 years to rewrite all the software.
Why not? Obviously they paid programmers to develop their current system, so why is it so outrageous to expect them to continue to pay programmers to upgrade and fix the system? In my opinion, the problem is that people look at these things all wrong. They think, "we'll pay some cheap programmers to write some software for us, and then we'll have this system that will operate forever for free!"
Funny how factory owners don't go, "we'll pay someone to build custom machinery and build out this factory, and then the factory will operate forever for free!" In a factory, people have the sense to realize you're going to have to maintain the machinery. You're going to need access to replacement parts when something breaks. You'll need to pay some mechanics to keep things running smoothly and tune things. The more custom it is, the more you'll need mechanics and engineers to build replacement parts as you go, and address design problems as they come up. You're going to have to plan to be able to replace the whole thing one piece at a time, even if not replacing the whole system at once.
Custom built software solutions are the same way. If you're going to build your business around one, you should prepare to have adequate programming resources to maintain the system and keep it up to date. You should have a plan to replace and upgrade the whole thing one piece at a time, even if not replacing the whole system at once. The more custom it is, the more resources you'll need to keep it up.
So these businesses shouldn't look at this as an expensive one-time project to be put off as long as possible. It should be an ongoing process that goes on for as long as their business goes on. Basing your business on custom-built software without the programming resources to maintain it is about as stupid and operating a factory with custom machinery without mechanics or replacement parts. That is, it may work for a while, but sooner or later you're going to have a catastrophic failure.
It's a generalized problem with metrics, measurements, and assessments. Holding contests are a good way to find people who like contests and perform well in that setting. Collecting resumes and cover letters is a good way to find people who are good at producing cover letters and resumes. Using algorithms is a great way to find people who fit those algorithms.
Know what you're measuring, and try to find a measurement that lines up with what you want.
Yeah, I really don't understand what Microsoft is thinking for Windows 8 licensing. They offer the OEM version, which you're legally not supposed to use unless you're building and reselling. They offer the upgrade version, which you're not supposed to use unless you're upgrading. Each version locks itself to specific hardware, so you're not supposed to be able to migrate from one machine to another. So what do you do if you buy a copy for a computer that you already own, and don't have Windows installed?
They may have a version for that, but I spent a while looking and couldn't find a real answer.
I agree, and that was pretty much where I was going with my post. I have a hard time saying that you couldn't come up with a system that would be effective at stopping piracy, but it would inhibit legitimate users so severely that it would ruin Microsoft. They know this, so they've made many concessions in their activation scheme, but it makes it weaker at stopping pirates, and yet it's still a pain for legitimate users.
I think this is pretty much always the case with "activation" schemes. DRM is troublesome enough, but it's likely to become a mess when you start locking things to specific hardware instead of just locking it to an account.
it definitely needs an activation system that doesn't make things difficult for its legal customers on a too-regular basis.
There's no such thing. You're not going to come up with a system that inhibits piracy but also doesn't create more work and effort for legitimate customers. Computers are not smart enough to judge whether what you're doing is "fair".
Even the Metro interface, while the design is interesting and unique, ultimately isn't all that use friendly.
I agree. I wanted to like it. I think it looks cool. It suffers from a huge problem, in my opinion, in that so many of the UI elements are hidden.
What I mean is, there are simply too many things that only show up when you hover the mouse cursor in a particular place, or when you right-click on a particular item. Worse: the "hidden" things that appear when you hover or right-click aren't entirely consistent, so if you're in a new application, you don't really know what you're going to get when you right-click. That's pretty bone-headed.
The worst part, in my opinion, is the hovering, though. It necessarily slows you down. Every time you have to hover, it adds at least a few fractions of a second to wait for it to appear, and then to visually confirm that the correct thing appeared. Then, once the hover menu appears, you have to visually seek out the control you were looking for, and move the cursor there. If you don't time things well and you miss your target, the hover menu disappears (or doesn't show up properly in the first place) and you have to start over.
All in all, it's a awful design that a good UI designer should have been able to dismiss at the design stage. It never should have made it into a shipping product.
Yes, I wasn't trying to say that there's anything wrong with typing quickly and without much thought. My point was that, even if you have some kind of visual cue to tell you whether your password will be obscured, people might not pay enough attention to that cue and type their password quickly before realizing that it's unmasked.
It also reminds me of the discussion of the cell phone network going out after the bombing in Boston. A lot of people were taking the attitude, "Well it's fine for the cell phone network to go out in an emergency. It's not serious infrastructure. You shouldn't be relying on cell phones." As thought the cell phones were toys for teenagers to post Facebook posts, while landlines were for "real" stuff.
Why not a choice? What's wrong with a button that says, "Unmask Password"?
That's not a terrible idea, but I would be very careful about implementing it. The problem is that it *can* be worse to have a security measure be in place "sometimes" or "most of time" than to not have it in place at all. If password masking is common enough that people assume it will be there, then they'll rely on it, get a sense of security from it, and let their guard down. Then they may type their password out in an unmasked field without noticing in time. People tend to type their passwords out quickly without much thought as it is, so it may not even be enough to provide a visual cue indicating that the password will not be masked.
Either you security do "yes" or security do "no." You security do "guess so," squish, just like grape.
Ok, maybe that quote doesn't really work, since security isn't really about absolutes. But it kinda works.
I think the concept was that the Cylons were just so technologically superior that technological attacks were futile. You might say that's unrealistic, but we're talking about monster space robots, so...
Not only did they show a world beyond the federation where money and greed were still present, but they showed the seedy underbelly of the federation. The main characters sometimes engaged in unethical behavior. There was the whole deal with Bashir being genetically engineered. There were assassinations. There was section 31.
It was also one of the earliest shows of its type to frequently have multi-episode (even multi-season) plot-lines. They had a whole season where they had to flee the station and couldn't return. That show was really good.
you object to aggregator apps for some reason you haven't really specified
They're an ok stopgap solution that isn't necessarily a real solution. To be more specific, if you have a bunch of email accounts being aggregated into one virtual inbox and you like doing that, cool. It's your option to have multiple accounts and to aggregate them however you like. What I'm saying is that the ability to access your AIM and Jabber and Yahoo chat accounts through pidgin doesn't fundamentally solve the problem of having multiple incompatible protocols that do effectively the same thing. Because (a) it's still a hack that add complexity for no good reason; and (b) it still doesn't really add interoperability. The fact that I'm using Pidgin doesn't mean that I don't have to sign up for and sign into all these different accounts. All it does is make it slightly more convenient to access your myriad of incompatible proprietary accounts.
It also doesn't address the other issue I was pointing out: that I can't necessarily have all my different *kinds* of communications (e.g SMS, voicemail, twitter, chat) going into one inbox. You can largely accomplish it by having everything send you email notifications, but again, you're not really solving the issue. You're painting over the cracks instead of addressing the issue.
While the cost is distributed between the customers, the real cost - the amount of energy wasted - is staggering.
What strikes me is that the entire bitcoin system is arguably a waste of energy. If we're going to pay people to expend energy on CPU cycles, couldn't we have those CPU cycles solve a real problem? Surely there must be useful and productive things that could be done with all that computing power.
I don't know what kind of e-mail you're using, but mine is pretty much the opposite of proprietary.
Right, but that's just email. Email is just about the only thing named that operates the way I would advocate.
All of your other objections seem to boil down to "but everyone won't use my preferred system, so we need to force them to!"
Nope. It would be closer to interpret me to saying, "but everyone is choosing to use their own preferred system, they all prefer different systems, and those systems are incompatible with each other, so they're forcing me to sign up for 50 different systems if I want to be able to talk to everyone!"
...nobody is really bound to any particular system.
Except that we're all stuck using them until they become unpopular, and then they're replaced with the new different proprietary solutions.
It may be a non-issue in approximately the same way that pretty much everything is a "non-issue". If you happen to be in a circumstance where it doesn't matter, or you're short-sighted enough to ignore the problems that can and will arise, then nothing is a real issue. Unified inboxes that pull from various different accounts are all fine and dandy, but there are various issues related to freedom, security, availability, economic development, etc. that come from having all these different communication systems that are essentially proprietary.
If that's too big a concept for you, then can I just point out that there are still simple issues such as: I can't (as far as I know) forward my iMessage messages to my gmail account. I can't connect to Skype IM through the IM client of my choice. There is currently no solution for a true "unified inbox" which captures all of my incoming email, SMS, IM, voicemail, responses to my forum posts, Tweets directed at me, etc. My only option is to try to get all of these services to send me emails, which many (though not all) of these services will support, but which results in a hodge-podge of different formats and different methods of reply.
I think this is just one part of a larger problem, which is that our communications are all fragmented.
Personally, I have 4 different email addresses that I actively use, as well as several that I don't use. I have 4 different IM accounts/protocols that I actively use. I have my cell phone, my work phone, and a Google Voice number, and voicemail for each. I have SMS via Google Voice and my phone directly, and then I also have iMessage on my phone, which arguably counts as a 5th IM account rather than SMS. I have membership and various forums and social networks. Through some of those social networks, I have even more email addresses and IM accounts. There may be even more accounts that I'm not thinking of.
So beyond the issue of SMS/chat, in that we have all these different incompatible and slightly different communications which don't work well together, and there isn't really a larger scheme to make it all coherent. I think Google may be the only company that's really trying to tackle the issue. They have been relatively successful in incorporating video, audio, and text chat with social networking. All that is tied in with Gmail and Google Voice under the same account, even though they're not really integrated yet. It'd be great if they could open APIs and protocols that allowed full interoperability with other services, e.g. if your friend could have Google+ and you have a Facebook account and a third friend sets up his own server, they can all still talk to each other and post on each others' walls.
But beyond that, I think we should be asking questions like: what's the difference between a IM message and SMS? Should you IM status be the same as a tweet? Where do you draw the line between a short blog post and a long Facebook status? What's the difference between sending an email and sending a IM to someone who is offline?
I would not only ask whether we need all these incompatible protocols, but whether we need all these different *kinds* of messages. Let's figure out which ones we really need, and then formulate standard protocols for distributing them.
I would also add, "projects are often not very well defined, which leads to feature creep," and, "there's always more to do." There's always more to do. More features to add. More QA to perform. More bugs to fix. Nothing is ever done.
But be careful not to say, "No, that's impossible," unless it's impossible. More often it's, "Well we could do that, but it will mean sacrificing features X and Y and it will cost an extra $Z."
Slashdot Mirror
If I have a roof I am going to want to replace it as close to it's expected life as possible.
That's why I think comparing it to machinery that needs maintenance, rather than something you'd just wait until it breaks. Software is a complex system with moving parts, not a roof. It's not about always having the latest and greatest, but the truth is, it very well may be more expensive to go straight from SQL 2005 to 2015 (or whatever comes next) than to go 2005 to 2008 to 2012 to 2015. It's impossible to say which will be more expensive when 2008 is just being released, since you don't know what will change between 2008 and 2015 when 2015 isn't a product yet. But even in hindsight, it's very difficult to calculate those kinds of costs.
The problem with not having someone maintain your code is that you lose time and productivity due to things like, "poor performance that might have been fixed if you had someone working occasionally to improve things," and "bugs that aren't very serious so we never bother to get them fixed." I don't care how brilliant you think business owners are, they aren't able to capture that kind of data clearly. But then when you do get around to upgrading from 2005 to 2015, it's possible that you'll have to upgrade to 2008 or 2012 first anyway, since there may be no other upgrade path. If there are major changes, then the upgrade will tend to be bumpy, and you're more likely to see show-stopper bugs as you make the change. All that will be made worse because you won't have anyone around that's familiar with the code you're upgrading. Not only will there be bigger problems, bigger delays, and more loss of productivity, but you're more likely to run into some catastrophic error.
But even in hindsight, it's impossible to know how close you came to a catastrophic error. It's impossible to know how much quicker and smoother the upgrade process could have gone if someone had been familiar with your code. It's very hard to track how much productivity you lost due to small bugs and minor delays. That's in hindsight. Starting in 2005 when you kicked off the project, you have no way of guessing what you'll run into without support.
So to me, if there were a factory owner who said, "My whole business relies on this on piece of custom built machinery. I'm not going to do maintenance. I'm not going to secure a source of replacement parts. I'm just going to run it into the ground, and when it dies, I'll figure out how to rebuild it then." then whatever, it's his factory. If he thinks that's going to be the most effective way forward, go for it. But I won't feel sorry for him if it breaks down after 5 years and he complains, "But it's too expensive to rebuild it!"
He is probably not figuring into his maintenance costs the fact that the engineer did a crappy job making sure the machine had a solid surface to sit on, and now the floor is buckling under the machine, requiring extensive repairs to both the floor and the machine.
Well if he's going to hire crappy engineers and architects, maybe he should figure in those maintenance costs. He should probably budget a little extra for unexpected problems either way.
So my question is: when custom software is created/deployed, is the business made aware of the maintenance costs?
It should be. If the developers are external/outsourced, then there should be some kind of structured agreement for maintenance, bug fixes, enhancements, and upgrades. It probably won't all be rolled into a flat fee, but some of it may be. If you've hired programmers to make a complex, business critical application, and they haven't raised the issue of maintenance, then they're either incompetent or dishonest.
Yes, but factory owners will continue repairing that old machinery (even fabricating new parts themselves if needed) as long as the machine suits the needs of the business, no matter how old the machinery gets.
Yes, but that is largely my point: you don't just buy the machine and expect it to keep working forever. You'll need to plan to buy replacement parts and hire people to perform maintenance and upkeep on an ongoing basis. You'll need to plan to have an ongoing expense that is "maintenance and upkeep". You may need to have a plan for changing your vendor for replacement parts, or to fabricate the parts yourself if vendors discontinue them. It takes time and work and money and expertise.
So where I think you're wrong is when you say the following: "As long as it suits the needs of the business (and not the whims of the IT staff) it will continue to be used and there is no need to spend more money on it." (emphasis mine)
Expect to spend money on it. Expect that the software will need to have bug fixes and updates. Even if you don't want to add functionality, you will need to upgrade it to run on newer platforms. If you use APIs to integrate with Microsoft Office, then plan to keep those up to date as new versions of Office are released. If you're using SQL Server 2005 on the back end, expect that someday you'll want to move to 2008 or 2012. You can keep the code-base, but you're going to have to keep programmers busy doing regular updates and maintenance on a regular basis.
Sure, you *could* just keep Windows XP running IE6 on computers that are 7 years old, accessing a database on an old unmaintained application. Just like a factory *could* build a bunch of custom machinery, fire all the people who built it, and refuse to spend money on simple maintenance. In both cases, you'd be fine for a little while.
When a piece of software is integral to a business, and there is no simple upgrade path, sometimes the cheapest (and *correct*) option is to stay on an "outdated" platform. Often, mitigating the issues with the old systems are cheaper than upgrading the software (if that is even possible).
Yes, but that doesn't really contradict the previous post. Staying on the "outdated" platform is still a short-term solution aimed at keeping costs low. Don't get me wrong, it might be a great short-term solution. Sometimes what you need is a short-term stop-gap until a long-term solution becomes more feasible.
On the other hand, if you're sticking with a short-term solution and you aren't also actively working on a better long-term solution, then you're just kicking the can down the road.
It costs money to redevelop a system with 10 years of development. Not 10 years worth- but easily 5 years worth and that's after 3 years of having a smaller staff analyze the problem...Because they do NOT want to hire the 30 programmers and pay them for 3 years to rewrite all the software.
Why not? Obviously they paid programmers to develop their current system, so why is it so outrageous to expect them to continue to pay programmers to upgrade and fix the system? In my opinion, the problem is that people look at these things all wrong. They think, "we'll pay some cheap programmers to write some software for us, and then we'll have this system that will operate forever for free!"
Funny how factory owners don't go, "we'll pay someone to build custom machinery and build out this factory, and then the factory will operate forever for free!" In a factory, people have the sense to realize you're going to have to maintain the machinery. You're going to need access to replacement parts when something breaks. You'll need to pay some mechanics to keep things running smoothly and tune things. The more custom it is, the more you'll need mechanics and engineers to build replacement parts as you go, and address design problems as they come up. You're going to have to plan to be able to replace the whole thing one piece at a time, even if not replacing the whole system at once.
Custom built software solutions are the same way. If you're going to build your business around one, you should prepare to have adequate programming resources to maintain the system and keep it up to date. You should have a plan to replace and upgrade the whole thing one piece at a time, even if not replacing the whole system at once. The more custom it is, the more resources you'll need to keep it up.
So these businesses shouldn't look at this as an expensive one-time project to be put off as long as possible. It should be an ongoing process that goes on for as long as their business goes on. Basing your business on custom-built software without the programming resources to maintain it is about as stupid and operating a factory with custom machinery without mechanics or replacement parts. That is, it may work for a while, but sooner or later you're going to have a catastrophic failure.
It's a generalized problem with metrics, measurements, and assessments. Holding contests are a good way to find people who like contests and perform well in that setting. Collecting resumes and cover letters is a good way to find people who are good at producing cover letters and resumes. Using algorithms is a great way to find people who fit those algorithms.
Know what you're measuring, and try to find a measurement that lines up with what you want.
Yeah, I really don't understand what Microsoft is thinking for Windows 8 licensing. They offer the OEM version, which you're legally not supposed to use unless you're building and reselling. They offer the upgrade version, which you're not supposed to use unless you're upgrading. Each version locks itself to specific hardware, so you're not supposed to be able to migrate from one machine to another. So what do you do if you buy a copy for a computer that you already own, and don't have Windows installed?
They may have a version for that, but I spent a while looking and couldn't find a real answer.
I agree, and that was pretty much where I was going with my post. I have a hard time saying that you couldn't come up with a system that would be effective at stopping piracy, but it would inhibit legitimate users so severely that it would ruin Microsoft. They know this, so they've made many concessions in their activation scheme, but it makes it weaker at stopping pirates, and yet it's still a pain for legitimate users.
I think this is pretty much always the case with "activation" schemes. DRM is troublesome enough, but it's likely to become a mess when you start locking things to specific hardware instead of just locking it to an account.
it definitely needs an activation system that doesn't make things difficult for its legal customers on a too-regular basis.
There's no such thing. You're not going to come up with a system that inhibits piracy but also doesn't create more work and effort for legitimate customers. Computers are not smart enough to judge whether what you're doing is "fair".
Even the Metro interface, while the design is interesting and unique, ultimately isn't all that use friendly.
I agree. I wanted to like it. I think it looks cool. It suffers from a huge problem, in my opinion, in that so many of the UI elements are hidden.
What I mean is, there are simply too many things that only show up when you hover the mouse cursor in a particular place, or when you right-click on a particular item. Worse: the "hidden" things that appear when you hover or right-click aren't entirely consistent, so if you're in a new application, you don't really know what you're going to get when you right-click. That's pretty bone-headed.
The worst part, in my opinion, is the hovering, though. It necessarily slows you down. Every time you have to hover, it adds at least a few fractions of a second to wait for it to appear, and then to visually confirm that the correct thing appeared. Then, once the hover menu appears, you have to visually seek out the control you were looking for, and move the cursor there. If you don't time things well and you miss your target, the hover menu disappears (or doesn't show up properly in the first place) and you have to start over.
All in all, it's a awful design that a good UI designer should have been able to dismiss at the design stage. It never should have made it into a shipping product.
Yes, I wasn't trying to say that there's anything wrong with typing quickly and without much thought. My point was that, even if you have some kind of visual cue to tell you whether your password will be obscured, people might not pay enough attention to that cue and type their password quickly before realizing that it's unmasked.
It also reminds me of the discussion of the cell phone network going out after the bombing in Boston. A lot of people were taking the attitude, "Well it's fine for the cell phone network to go out in an emergency. It's not serious infrastructure. You shouldn't be relying on cell phones." As thought the cell phones were toys for teenagers to post Facebook posts, while landlines were for "real" stuff.
Why not a choice? What's wrong with a button that says, "Unmask Password"?
That's not a terrible idea, but I would be very careful about implementing it. The problem is that it *can* be worse to have a security measure be in place "sometimes" or "most of time" than to not have it in place at all. If password masking is common enough that people assume it will be there, then they'll rely on it, get a sense of security from it, and let their guard down. Then they may type their password out in an unmasked field without noticing in time. People tend to type their passwords out quickly without much thought as it is, so it may not even be enough to provide a visual cue indicating that the password will not be masked.
Either you security do "yes" or security do "no." You security do "guess so," squish, just like grape.
Ok, maybe that quote doesn't really work, since security isn't really about absolutes. But it kinda works.
Multiple incompatible protocols might offend your sense of elegance, but that's the way it is. I don't see it as an issue.
Well you're bragging about being stubborn and blind. Congratulations. Your mother must be so proud.
I think the concept was that the Cylons were just so technologically superior that technological attacks were futile. You might say that's unrealistic, but we're talking about monster space robots, so...
Not only did they show a world beyond the federation where money and greed were still present, but they showed the seedy underbelly of the federation. The main characters sometimes engaged in unethical behavior. There was the whole deal with Bashir being genetically engineered. There were assassinations. There was section 31.
It was also one of the earliest shows of its type to frequently have multi-episode (even multi-season) plot-lines. They had a whole season where they had to flee the station and couldn't return. That show was really good.
you object to aggregator apps for some reason you haven't really specified
They're an ok stopgap solution that isn't necessarily a real solution. To be more specific, if you have a bunch of email accounts being aggregated into one virtual inbox and you like doing that, cool. It's your option to have multiple accounts and to aggregate them however you like. What I'm saying is that the ability to access your AIM and Jabber and Yahoo chat accounts through pidgin doesn't fundamentally solve the problem of having multiple incompatible protocols that do effectively the same thing. Because (a) it's still a hack that add complexity for no good reason; and (b) it still doesn't really add interoperability. The fact that I'm using Pidgin doesn't mean that I don't have to sign up for and sign into all these different accounts. All it does is make it slightly more convenient to access your myriad of incompatible proprietary accounts.
It also doesn't address the other issue I was pointing out: that I can't necessarily have all my different *kinds* of communications (e.g SMS, voicemail, twitter, chat) going into one inbox. You can largely accomplish it by having everything send you email notifications, but again, you're not really solving the issue. You're painting over the cracks instead of addressing the issue.
While the cost is distributed between the customers, the real cost - the amount of energy wasted - is staggering.
What strikes me is that the entire bitcoin system is arguably a waste of energy. If we're going to pay people to expend energy on CPU cycles, couldn't we have those CPU cycles solve a real problem? Surely there must be useful and productive things that could be done with all that computing power.
I don't know what kind of e-mail you're using, but mine is pretty much the opposite of proprietary.
Right, but that's just email. Email is just about the only thing named that operates the way I would advocate.
All of your other objections seem to boil down to "but everyone won't use my preferred system, so we need to force them to!"
Nope. It would be closer to interpret me to saying, "but everyone is choosing to use their own preferred system, they all prefer different systems, and those systems are incompatible with each other, so they're forcing me to sign up for 50 different systems if I want to be able to talk to everyone!"
...nobody is really bound to any particular system.
Except that we're all stuck using them until they become unpopular, and then they're replaced with the new different proprietary solutions.
It may be a non-issue in approximately the same way that pretty much everything is a "non-issue". If you happen to be in a circumstance where it doesn't matter, or you're short-sighted enough to ignore the problems that can and will arise, then nothing is a real issue. Unified inboxes that pull from various different accounts are all fine and dandy, but there are various issues related to freedom, security, availability, economic development, etc. that come from having all these different communication systems that are essentially proprietary.
If that's too big a concept for you, then can I just point out that there are still simple issues such as: I can't (as far as I know) forward my iMessage messages to my gmail account. I can't connect to Skype IM through the IM client of my choice. There is currently no solution for a true "unified inbox" which captures all of my incoming email, SMS, IM, voicemail, responses to my forum posts, Tweets directed at me, etc. My only option is to try to get all of these services to send me emails, which many (though not all) of these services will support, but which results in a hodge-podge of different formats and different methods of reply.
This could be done better.
I think this is just one part of a larger problem, which is that our communications are all fragmented.
Personally, I have 4 different email addresses that I actively use, as well as several that I don't use. I have 4 different IM accounts/protocols that I actively use. I have my cell phone, my work phone, and a Google Voice number, and voicemail for each. I have SMS via Google Voice and my phone directly, and then I also have iMessage on my phone, which arguably counts as a 5th IM account rather than SMS. I have membership and various forums and social networks. Through some of those social networks, I have even more email addresses and IM accounts. There may be even more accounts that I'm not thinking of.
So beyond the issue of SMS/chat, in that we have all these different incompatible and slightly different communications which don't work well together, and there isn't really a larger scheme to make it all coherent. I think Google may be the only company that's really trying to tackle the issue. They have been relatively successful in incorporating video, audio, and text chat with social networking. All that is tied in with Gmail and Google Voice under the same account, even though they're not really integrated yet. It'd be great if they could open APIs and protocols that allowed full interoperability with other services, e.g. if your friend could have Google+ and you have a Facebook account and a third friend sets up his own server, they can all still talk to each other and post on each others' walls.
But beyond that, I think we should be asking questions like: what's the difference between a IM message and SMS? Should you IM status be the same as a tweet? Where do you draw the line between a short blog post and a long Facebook status? What's the difference between sending an email and sending a IM to someone who is offline?
I would not only ask whether we need all these incompatible protocols, but whether we need all these different *kinds* of messages. Let's figure out which ones we really need, and then formulate standard protocols for distributing them.
Or have it plug into your cell phone, and offload the processing there too.
Blackberry has finally a whole smartphone market. Is that bad?
I would also add, "projects are often not very well defined, which leads to feature creep," and, "there's always more to do." There's always more to do. More features to add. More QA to perform. More bugs to fix. Nothing is ever done.
But be careful not to say, "No, that's impossible," unless it's impossible. More often it's, "Well we could do that, but it will mean sacrificing features X and Y and it will cost an extra $Z."