A mag-strip card IS a type of password. Depending on the institution that issued it, it's a rediculously long propietary password. It's a string of encoded bits. Nothing magical about it.
Yes, of course it is. It is not however a password that a human has to remember (besides keeping it in their pocket or whatever). Any security system that relies on humans behaving un an unhumanlike way (remembering numberous frequently changing complicated passwords) is inherently broken. People just won't do it with any reliability. They will find some way around it, even if it means writing down all their passwords on a post-it stuck to their monitor.
Furthermore, most people (and by most, i mean just about everyone), NEVER change either their PIN or their card, unless it's stolen. Is that type of system any more secure?
Well, as you said yourself, the PIN is not the password, just one component of a much bigger password. If it's big enough, and if the physical card part of the system is well designed, then the only time they should change the is when it is stolen, right?
Your users shouldn't require anything more than a 4 digit pin & a magnetic card. If it's enough to protect their money, it's surely enough to protect some stupid data.
Any lame brained security system that depends on people choosing difficult to remember passwords and changing them every 3-6 months is broken by design.
It would be more interesting to know what percentage of companies see OSSing their own stuff as part of their IT strategy.
I have used OSS tools in all of the 5 companies I have worked for. All but one of them could be considered that a critical part of their business would stop working (in the short term at least) if those tools disappeared in the morning. None of them however has ever had any intention of releasing the source to anything they develop, even if they didn't make money directly from that SW.
It's a small sample I know, but I would imagine that most companies are the same as those I have worked for.
The first bid for a contract I made was for a govt. dept., I wrote it would take 30 developers a year and a half to do, way more than anybody else estimated. Needless to say it was rejected.
They bought an "off the shelf" product to do it, though luckily seeing as how we had seemed to know what we were talking about they gave us the customization work on a rolling contract.
Finally took 30 developers a year and a half to customize it:-)
If Linux provided a stable ABI, then maybe manufacturers would be willing to support it more. It chooses not to provide that for it's own ideological reasons.
Re:Aren't we still in an Ice Age?
on
A New Ice Age?
·
· Score: 1
For most of history mankind has lived close to the survival margins.
recognises that it's a job, and you don't do what you don't get paid for. That there is no excuse for any project to demand your unpaid overtime, and furthermore, that no project if it was managed properly whould ever need such contributions.
That's probably why they prefer ppl with 2 years experience:-)
use a documentation generator, like javadoc, or doxygen, etc.. and commment your interfaces and code a lot. It has the advantage of always being relatively up to date, something your documentation doesn't seem to be.
That has nothing to do with the internal architecture of Windows. That's a bug in ZoneAlarm. There is no reason to blame Windows at all for a bug in a software product written to run on Windows.
While you are quite correct in one sense, microsoft didn't write the code, surely modern operating systems should be limiting the rights of userland programs so that just because someone deploys a piece of buggy software (cf. all software ever created) their whole system is suddenly vulnerable to attack. Unix type systems are somewhat better in this regard, but there is no doubt that they suffer from the tyranny/vulnerability of root. I'm not saying it's an easy problem to solve, but as a commercial OS vendor Microsoft should be doing an awful lot more about it than they are now. So should commercial distributors of other OS (whether they are open source or not).
That's probably because in most cases you can't claim to be an Engineer unless you really are one. There are professional associations and legal regulations so on. It's not the same for SW "Engineering" at all. Maybe it should be, but that's a whole 'nother discussion.
I agree. There was one bank that had all old green screen interface to their ATMs when I was in college, and the other's were fancy graphics. Everyone used to go to the green screen one whenever possible, because it was much faster to do anything on.
The problem, IMO, is that providing a specification that is detailed enough and correct enough to generate a correct program from is just as hard as writing the correct program in the first place.
Exactly. Job ads for programmers in the future will contain the line "Must have 10+ years experience of MS Visual Specification.NET", and Salon.com will be writing articles about how programming in Specification stinks, and how it's all going to be solved by DoWhatIMeanNotWhatISay++, OpenMindReader or somesuch.
Games are slightly different, because they don't directly compete with each other (except in scattered cases, like HL2 versus Doom 3).
I disagree with this. Every game out there is in direct competition with every other game, no matter what the genre. If I spend $50 on a game. That's $50 that's not going to be spent on any other game.
Microsoft has a monopoly in Intel based Hardware. MacOS X has a monopoly on Apple Hardware. If you produce an application for the Mac and Apple decides to ship a competing product pre-installed then you are just as dead as if Microsoft had done the same.
Most of the Indian programmers I have ever had to speak with, have always spoken English very well.
Both you and the poster you responded to are exaggerating. There are many Indian workers who speak english flawlessly, with accents noone would ever have trouble understanding.
There are many who, though technically might be said to be speaking english, are frankly unintelligible to anybody other than themselves.
Then there are a bunch in the middle who, though they speak too fast, and stress words incorrectly, and retain the typical Indian babble, are understandable if you pay close attention.
In my opinion, the problem mostly stems from the fact that the two sets who babble have had english since they were children, but "indian english", and haven't bothered to learn any kind of standard accent, the way other non-native speakers inevitably do, but instead kept their own accent, the same way all native english speakers do. The ones who speak fine have obviously grasped that English is spoken completely differently in India to the rest of the world, and have adapted their speech accordingly.
They are all though, no more intelligent or stupid than anybody else.
You shouldn't complain about phones that are clearly not marketed towards you. Nokia, Sony Ericsson, Motorola, etc. have absolutely huge ranges of phones. They cater for just about every market niche you could concieve of. One consequence of that however it that many/most phones will have features that you have absolutely no interest in. Do you complain that trucks have way too many features, and are way too bulky, when all you want is something to pop down to the shops in? No you don't (I hope!). This is exactly the same thing however. Does this phone look like it is trying to be a solid reliable business phone? Does it look like it even knows what a solid reliable business phone is? No, but plenty of other models do.
The point of phones on cameras is that people bring their phone everywhere. People don't bring their camera everywhere, no matter how small it is. Of course a tiny fixed lens is going to be worse than one with real optical zoom, but it's plenty good enough for a lot of things.
Yea, I own an LG-VX6000, and I tell you this...I bought it for the actual features it has as a phone and not the camera.
As you should. It is after all primarily a phone.
I've taken a few pictures with the camera, and put simply...there can be no replacement for film and digital cameras anytime in the near future.
People said the same about digital cameras when they first arrived, but now you are including them with film to make your point. This Nokia phone has the same resolution as the Kodak that I bought 5 years ago. That's not such a long time really. Other manufacturers have already 2 and higher megapixel phones, and I can't see them stopping competing with each other anytime soon.
Yes, and it caused more damage than the one that it was supposed to be protecting you against. It was the only worm/virus so far to cause a global outage in the company where I work.
You want commercially competing companies to be "selective" of who they sell to? You'll excuse me if I am a little sceptical.
What would actually happen is that there would be numerous TLDs with "cool" names selling sub-domains to just anyone, and it would be impossible for anyone to remember what any of them really meant. Much like the situation now, just more chaotic.
The first thing for the whole naming mess would be for browsers to automatically display the whois information nicely formatted on the screen for whatever website you were visiting. Then people could begin to guess whose site they were visiting. Whois should be enhanced, and linked with site certificates and so on. That would benefit the end user experience. There should be a standardised HTML element for processing transactions, and browsers should display relevant information for where that was going, who they were, etc... There should be standardised ways to query national companies register, national trademark listing, and so on, so that browesrs could automatically display this stuff, instead of people having to (and typically not) track it down themselves. Those things would be advantages. More TLDs would be just one big nothing.
I think (in my non-lawyerish way) that Linus is wrong about what a judge will consider a derived work.
For userland programs all of which dynamically use the kernel he has said that he (as the copyright holder) won't find them actionable. (even if some GPL interpreters might disagree). I agree that they are not actionable, but not just because he thinks so. I think that even if he thought they were actionable, any judge would rule against him. Otherwise the entire software industry would have no legal basis, and clearly it does. Dynamic loading or plugins just leaves a library shaped hole in your program. It could be filled by any library that matches the shape of the hole.
For dynamically loadable kernel modules or drivers he thinks they are actionable. For the same reasons as in userland above I think that just because he believes they are actionable, doesn't make it so. I think that no judge will agree with him.
For dynamically loadable kernel modules or drivers that use inline (i.e. copyable) kernel functions he believes they are actionable. I think there is a 50:50 chance that a judge will agree with him. I think there is also a chance that the judge will consider that since the inline functions form a part of the interface, that using them is fair-use, and rule against him.
For statically linked kernel modules he thinks they are actionable. I agree, if the module and kernel are distributed together. If the author just provides the statically linked module as some kind of patch, separate from the kernel, then it is not the module author that has created a derived work, but the user who installs it, and that is fine with the GPL.
I think his assertion that if you are "thinking of linux" when writing your module or driver, it becomes a derived work of his, is somewhat crazy.
But that's just my opinion. Linus has his, and so does everyone here probably. I'm sure that a lawyer would advise differently again. Personally I would love to see a GPL violation go to trial, for each of the cases above. Just to see what would happen. It would be interesting.
Except that for many things the hardware is (considered) pretty generic, and the companies feel their value is in the driver or other value-adding software on top. If you have written a super-duper driver for your card, you don't want another company being able to port it to their cheap knock off, but more or less identical, card.
Slashdot Mirror
Yes, of course it is. It is not however a password that a human has to remember (besides keeping it in their pocket or whatever). Any security system that relies on humans behaving un an unhumanlike way (remembering numberous frequently changing complicated passwords) is inherently broken. People just won't do it with any reliability. They will find some way around it, even if it means writing down all their passwords on a post-it stuck to their monitor.
Well, as you said yourself, the PIN is not the password, just one component of a much bigger password. If it's big enough, and if the physical card part of the system is well designed, then the only time they should change the is when it is stolen, right?
Your users shouldn't require anything more than a 4 digit pin & a magnetic card. If it's enough to protect their money, it's surely enough to protect some stupid data.
Any lame brained security system that depends on people choosing difficult to remember passwords and changing them every 3-6 months is broken by design.
It would be more interesting to know what percentage of companies see OSSing their own stuff as part of their IT strategy.
I have used OSS tools in all of the 5 companies I have worked for. All but one of them could be considered that a critical part of their business would stop working (in the short term at least) if those tools disappeared in the morning. None of them however has ever had any intention of releasing the source to anything they develop, even if they didn't make money directly from that SW.
It's a small sample I know, but I would imagine that most companies are the same as those I have worked for.
The first bid for a contract I made was for a govt. dept., I wrote it would take 30 developers a year and a half to do, way more than anybody else estimated. Needless to say it was rejected.
:-)
They bought an "off the shelf" product to do it, though luckily seeing as how we had seemed to know what we were talking about they gave us the customization work on a rolling contract.
Finally took 30 developers a year and a half to customize it
If Linux provided a stable ABI, then maybe manufacturers would be willing to support it more.
It chooses not to provide that for it's own ideological reasons.
For most of history mankind has lived close to the survival margins.
recognises that it's a job, and you don't do what you don't get paid for. That there is no excuse for any project to demand your unpaid overtime, and furthermore, that no project if it was managed properly whould ever need such contributions.
:-)
That's probably why they prefer ppl with 2 years experience
Maybe the phones could make a loud annoying noise whenever they went out of service. Problem solved ;-)
use a documentation generator, like javadoc, or doxygen, etc.. and commment your interfaces and code a lot. It has the advantage of always being relatively up to date, something your documentation doesn't seem to be.
That's probably because in most cases you can't claim to be an Engineer unless you really are one. There are professional associations and legal regulations so on. It's not the same for SW "Engineering" at all. Maybe it should be, but that's a whole 'nother discussion.
So they can show you pretty advertisements for mortgages and loans.
I agree. There was one bank that had all old green screen interface to their ATMs when I was in college, and the other's were fancy graphics. Everyone used to go to the green screen one whenever possible, because it was much faster to do anything on.
Microsoft has a monopoly in Intel based Hardware. MacOS X has a monopoly on Apple Hardware. If you produce an application for the Mac and Apple decides to ship a competing product pre-installed then you are just as dead as if Microsoft had done the same.
There are many who, though technically might be said to be speaking english, are frankly unintelligible to anybody other than themselves.
Then there are a bunch in the middle who, though they speak too fast, and stress words incorrectly, and retain the typical Indian babble, are understandable if you pay close attention.
In my opinion, the problem mostly stems from the fact that the two sets who babble have had english since they were children, but "indian english", and haven't bothered to learn any kind of standard accent, the way other non-native speakers inevitably do, but instead kept their own accent, the same way all native english speakers do. The ones who speak fine have obviously grasped that English is spoken completely differently in India to the rest of the world, and have adapted their speech accordingly.
They are all though, no more intelligent or stupid than anybody else.
You shouldn't complain about phones that are clearly not marketed towards you. Nokia, Sony Ericsson, Motorola, etc. have absolutely huge ranges of phones. They cater for just about every market niche you could concieve of. One consequence of that however it that many/most phones will have features that you have absolutely no interest in. Do you complain that trucks have way too many features, and are way too bulky, when all you want is something to pop down to the shops in? No you don't (I hope!). This is exactly the same thing however. Does this phone look like it is trying to be a solid reliable business phone? Does it look like it even knows what a solid reliable business phone is? No, but plenty of other models do.
The point of phones on cameras is that people bring their phone everywhere. People don't bring their camera everywhere, no matter how small it is. Of course a tiny fixed lens is going to be worse than one with real optical zoom, but it's plenty good enough for a lot of things.As you should. It is after all primarily a phone.People said the same about digital cameras when they first arrived, but now you are including them with film to make your point. This Nokia phone has the same resolution as the Kodak that I bought 5 years ago. That's not such a long time really. Other manufacturers have already 2 and higher megapixel phones, and I can't see them stopping competing with each other anytime soon.
So will NASA be sharing this tech with mobile phone companies anytime soon? Here's hoping...
Nobody ever said at the end of their life that they wished they had spent more time in the office.
Truisms, gotta love em.
Yes, and it caused more damage than the one that it was supposed to be protecting you against. It was the only worm/virus so far to cause a global outage in the company where I work.
What would actually happen is that there would be numerous TLDs with "cool" names selling sub-domains to just anyone, and it would be impossible for anyone to remember what any of them really meant. Much like the situation now, just more chaotic.
The first thing for the whole naming mess would be for browsers to automatically display the whois information nicely formatted on the screen for whatever website you were visiting. Then people could begin to guess whose site they were visiting. Whois should be enhanced, and linked with site certificates and so on. That would benefit the end user experience. There should be a standardised HTML element for processing transactions, and browsers should display relevant information for where that was going, who they were, etc... There should be standardised ways to query national companies register, national trademark listing, and so on, so that browesrs could automatically display this stuff, instead of people having to (and typically not) track it down themselves. Those things would be advantages. More TLDs would be just one big nothing.
I think (in my non-lawyerish way) that Linus is wrong about what a judge will consider a derived work.
For userland programs all of which dynamically use the kernel he has said that he (as the copyright holder) won't find them actionable. (even if some GPL interpreters might disagree). I agree that they are not actionable, but not just because he thinks so. I think that even if he thought they were actionable, any judge would rule against him. Otherwise the entire software industry would have no legal basis, and clearly it does. Dynamic loading or plugins just leaves a library shaped hole in your program. It could be filled by any library that matches the shape of the hole.
For dynamically loadable kernel modules or drivers he thinks they are actionable. For the same reasons as in userland above I think that just because he believes they are actionable, doesn't make it so. I think that no judge will agree with him.
For dynamically loadable kernel modules or drivers that use inline (i.e. copyable) kernel functions he believes they are actionable. I think there is a 50:50 chance that a judge will agree with him. I think there is also a chance that the judge will consider that since the inline functions form a part of the interface, that using them is fair-use, and rule against him.
For statically linked kernel modules he thinks they are actionable. I agree, if the module and kernel are distributed together. If the author just provides the statically linked module as some kind of patch, separate from the kernel, then it is not the module author that has created a derived work, but the user who installs it, and that is fine with the GPL.
I think his assertion that if you are "thinking of linux" when writing your module or driver, it becomes a derived work of his, is somewhat crazy.
But that's just my opinion. Linus has his, and so does everyone here probably. I'm sure that a lawyer would advise differently again. Personally I would love to see a GPL violation go to trial, for each of the cases above. Just to see what would happen. It would be interesting.
Except that for many things the hardware is (considered) pretty generic, and the companies feel their value is in the driver or other value-adding software on top. If you have written a super-duper driver for your card, you don't want another company being able to port it to their cheap knock off, but more or less identical, card.