The following quote illustrates the major problem I have witnessed with all software projects that fail:
An outside computer analyst who has studied the FBI's technology efforts said the agency's problem is that its officials thought they could get it right the first time. "That never happens with anybody," he said.
When will people learn: with extremely complicated systems that humans have to interact with you can not specify it 100% correctly the first time?
Experience in building such systems has lead many of us to realize you must use an iterative approach that allows the end users to be part of the feedback loop.
Release early and release often, let your users use and break the application, and come closer to the ideal system with each iteration.
Now, I wouldn't blame the FBI for the problem completely - after all, they are not software developers. A portion of blame should go toward the contractor for failing to realize the issues surrounding development of such a complex system and taking appropriate actions to determine and meet the needs of their clients. Their contract should have been written to a) specify customer satisfaction as the key measurable for success, and payment of the contract b) put in a rider that basically states any functionality needed to bring the application to minimal usability as discovery occurs will be part of the first contract (this is negotiable - some things are really enhancements and new functionality - and some are required, even though not originally discovered in the first iteration - this allows both parties to recognize up front that 100% discovery of requirements does not take place in practice).
This approach has worked extremely well for me as a manager of vendor development (I have been extremely lucky to have vendors who understand what I am talking about), as well as for my own projects that I develop and implement. While there is a bit of risk involved in negotiating key usability issues discovered late in the development cycle - going out of the gate with an iterative approach ameliorates much of that - and is certainly less risky than giving someone $100,000,000 before I see the first line of code...
I am not saying I have faith in the process (I assume you mean to bring the right candidates to the fore) - what I am saying is that is the process - good, bad, or indifferent.
As for the lying weasles: that is exactly what happens in many cases - to the eventual regret of the hiring manager and everyone who works with said weasel. This is particularly true if the hiring manager does not have a clue as to what the position actually requires (skills, knowledge, experience - wise). This is also why a recommendation holds more weight than a resume in most cases.
I can't find any of the posts or newsgroups for my computer science classes back in the late '80s/early '90s...some interesting and useful info there; I remember using the first Mozaic(sic) in the CS Lab - and we used elm and pine to read newsgroups and mail to read email via command line. Those were the days.
One thing that is interesting if you search the archive is that the amount of spam just grows and grows until usenet is useless - and less general purpose as it was back in the day - becoming handfuls of islands of special interest in a sea of spam. I stopped using it, opting instead for special interest bulletin boards - such as slashdot).
In the early days it was a great communications medium for groups of people; from an archival standpoint it has limited usefulness as it stands (until someone takes the raw data and does a thorough job of indexing it - which given the size of the archive probably won't happen except for small pieces - like this timeline).
What does the future hold? More message boards, or something more intriguing?
You also have to understand most large corporations have human resources people who have to rubber stamp everything - so the description of the job and the requirements could be totally out of whack with reality.
Go ahead and put in for it anyway, because they will use the certs and education to make the first cull (so, in your example: if no one can have 5 years of.NET experience - then no one will, unless they are lying), then the resumes will go to the hiring manager who will make further cullings to get an interview list. If you are the best candidate, you will get an interview.
One other important factor you should not overlook: in all of the salaried jobs I have achieved, I always had recommendations from people inside the organization, or people outside who had relationships with those on the inside. Hiring managers put stock in what others they trust think of you - more so than just skills alone.
I have stock options that have vested that I can't exersize because the bottom fell out (i.e. lets say I got options at $20, and now the stock is selling for $10).
The last stock options that were issued by my company was several years ago. Since then they have been issueing cash bonuses instead - which those of us holding worthless options welcomed.
(I am hoping the stock market will climb again so I can exersize the options I am holding, but I doubt it will go high enough for those options there were given in recent years - when the stock price was inflated. There is a time limit on how long you can hold them once they vest - so having stock options is a big gamble for you)
You are aware, I hope, that all of those 'other' devices you mentioned have a computer inside of them (defined by central processing unit {variation on Von Neumann machine}, random access memory, read only memory, stored programs {in rom or ram}, and some form of input/output {usb, ethernet, serial, etc..} - writable storage medium - aka harddrive - is optional).
The terms, 'mainframe', 'mini', 'micro' (aka 'personal computer' or 'pc'), are all just marketing terms. A computer is a computer, some are just more specialized in one form or another; at the heart of all of the different types is the basic components of a stored program computer. The newer crop of devices, while having features that are primarily oriented to a specific non-computer area (wireless telephony, washing machine, refrigerator, etc) are still at their core computers.
Marketers love to hawk their wares as the latest thing since sliced bread; at the heart of all the 'new' technology is old technology (in this case technology at least 50 years old) - just a variation on a theme. That is not bad, in fact it is very useful to find new ways to use old technology - to extend its usefulness. Lets just not get too carried away and make sweeping statements - like PCs (computers) are not needed for the internet to function. On the contrary, they always will be needed in one form or another (perhaps they will be analog computers in some far distant future) in order for an internet to exist simply because of the processing required (pattern matching, counting and arithmatic operations at its lowest level).
Furthermore, personal devices that can be dynamically programmed and physically modified to create new interfaces and uses will always be in demand because of their utility and personalization. They certainly won't go away. Will they look like the monstrosities we have sitting under our desks now - no. Will they serve the same functions - yes and more that we haven't even thought of yet. 'Personal Computer' is just that - a computer for the person; today that can be a desktop computer, a personal digital assistant, a cell phone/PDA, or a wearable computer integrated into clothing. The PC will be with us long after you and I are dead.
On the off chance that you are not pulling my leg, I will explain why you got the error message.
I didn't mean for you to literally enter the path I listed in the chmod command. I thought it was obvious what I meant, but let me explain anyway:
In the command, "chmod 700/directory/path/where/mozilla/keeps/the/files/*" you need to replace the "/directory/path/where/mozilla/keeps/the/files/" part with the actual directory path to the files used by Mozilla Firefox.
I used this shorthand because a) the files can be in different locations depending on how you installed your browser, and b) I didn't have time to actually research the details and present a full 'howto' document in these forums - I left that as an exersize for the user.
I appologize if I wasn't clear enough on that. However most application documentation, howtos, and computer books use similar methodology - so my assumption that it would be understandable without further explanation.
I always give myself execute permissions on all of my files - no telling if one is a script or not... (I've seen utility scripts embedded in application folders that contained cache/state and other configuration data).
Additionally, it really doesn't matter for yourself, because if someone manages to login as you, they will be able to change all of the permissions to anything they want anyway. Irrelevant.
How does using IE make it any more likely that this trojan will work?
Because if someone has enabled unsecured (ActiveX) scipting technology on their IE browser, malicious code can execute the trojan after it is on disk. Not so for the Firefox browser - which has no means of accessing the disk via Jscript/Java, etc...
My 2nd point holds: an approximation of zero can in effect be zero for all intents and purposes.
My 3rd point holds: the point was made that a user on a multiuser machine could read the files created by your browser; my answer was to change the permissions on the file to only allow the user to access said files. Why doesn't that work?
You could syncronize the feeds using NTP (network time protocol). Here is how I envision it working:
All of your nodes have a computer connected; all of these nodes get thier timing via NTP from the same clock (doesn't matter which clock, as long as it was one such clock - in fact you could use your master node machine as the master clock, as well).
When the data is sent to the nodes it has time hash information embedded with the music data. The master node would offset the time hash so that the master node and all other nodes broadcast the music simultaneously.
Software would have to be developed to upload, decode, and transmit consistent sized chunks of music data; all of the systems on the array would use this software.
This is the 'what' to do - now someone just needs to determine 'how' to do it and implement it:)
What average windoze user encrypts his filesystem? (show of hands!)
I didn't think so. Divide the small number of users who probably encrypt their filesystem, lets say 20,000, by the count of the total number of Windows users (all operating system versions in use, a number hear infinity - lets say several billion).
Grid computing (or a Beowulf cluster; I had to throw that in) also offers some options for leveraging concurrency, and much of the work done to make these systems work could be leveraged within the operating system to do similar things on multi-cpu machines.
I agree - its not there now. I am not so sure an example of the solution won't be here in short order - considering the brick wall that many companies (particularly computer game companies, who are always pushing the edge of the envelope) will be hitting.
Saying it won't happen, is as bad, or worse than saying it will happen on January 7th at 2200 GMT...
Create a long URL and the downloading box will only display its ending (Mozilla and Firefox).
Click 'cancel' if you are not sure about what you are downloading; Addtionally, you should be able to hover the mouse over a link and see the actual URL in the display bar at the bottom of the window. I do this all the time because I want to be sure where my browser will be connecting when I click anything. Of course, if you go to sites that don't use standard HTML for their links, you could be scammed. Generally speaking, unless you are running IE, downloading a trojan isn't going to be that bad - as long as you don't then try to run it. If you were expecting a picture, or a zip file, and got an executable instead, that could also tip you off. This is probably the worse problem of the three - but nothing to lose sleep over.
The second issue was created by the way that Mozilla's browsers handle news:// links to newsgroups, hackers can easily create false links and create a buffer overflow (Mozilla 1.7.5 and below, Firefox versions before 1.0).
If you aren't using the latest version of the browser - you are wrong. Additionally, who reads news groups anymore? I gave up wading through all the spam and flame wars long ago...
The third exploit affects machines with multiple users. The way that Firefox and Thunderbird store files allows every user to see them and to probably catch the other user's surfing habits (Firefox and Thunderbird). Let's hope that these will be fixed soon!
- should do the trick on most unix/linux systems. I can't see this breaking the browser, because presumably it is being run by you as you. This is irrelevant on a Windoze machine because it is not truely multi-user (and I can slap a knoppix disk into your windows machine, reboot linux, and read all your files provided I have physical access anyway - which is how most people 'share' a windows box).
Seriously though, the article recommends building applications concurrently. Short-term this may be the case on a small scale (and really already is the case).
The fundamental paradigm shift that will occur will be when we build our operating systems to handle concurrency for us; the advent of 4GLs will help move this forward.
In this model, you would program normally, not worrying about concurrency at all. The OS would do all the dirty work of breaking up your application into pieces that can run concurrently for you. Are we there yet? No. Will we be there? Yes - particularly if you want to keep productivity at high levels. You will have to abstract concurrency from the day to day programmer for this to happen.
Why was it wrong to say the tool should not be compared to the atom bomb? The interviewer created a logical fallacy which he addressed in a more diplomatic way than I would have.
This is like blaming all knife makers, gun makers, shovel makers, car makers, etc. for all the destruction and death caused by these devices when misused. It is rediculous - and does not hold legal water. The interviewer's assumption was right up this alley - and Mr. Cohen's response appropriate.
Slashdot Mirror
Bingo!
Ah - It just snapped when you said 'laptop'...and I am looking at one attached to my mini-atx workstation right now - lol.
Not so sinister after all.
When will people learn: with extremely complicated systems that humans have to interact with you can not specify it 100% correctly the first time?
Experience in building such systems has lead many of us to realize you must use an iterative approach that allows the end users to be part of the feedback loop.
Release early and release often, let your users use and break the application, and come closer to the ideal system with each iteration.
Now, I wouldn't blame the FBI for the problem completely - after all, they are not software developers. A portion of blame should go toward the contractor for failing to realize the issues surrounding development of such a complex system and taking appropriate actions to determine and meet the needs of their clients. Their contract should have been written to a) specify customer satisfaction as the key measurable for success, and payment of the contract b) put in a rider that basically states any functionality needed to bring the application to minimal usability as discovery occurs will be part of the first contract (this is negotiable - some things are really enhancements and new functionality - and some are required, even though not originally discovered in the first iteration - this allows both parties to recognize up front that 100% discovery of requirements does not take place in practice).
This approach has worked extremely well for me as a manager of vendor development (I have been extremely lucky to have vendors who understand what I am talking about), as well as for my own projects that I develop and implement. While there is a bit of risk involved in negotiating key usability issues discovered late in the development cycle - going out of the gate with an iterative approach ameliorates much of that - and is certainly less risky than giving someone $100,000,000 before I see the first line of code...
What is the 'Security Slot' used for?
:)
(sounds a bit sinister, like the thing will bite me if I try to open the case)
This could be my first MAC (I can see a beowulf cluster of these
Just for that - I will have to put you on my friends list... :p
Playing the devils advocate, I would say it is not the interest of government to protect anyone - or apply moral imperatives that do.
However it is in government's interest to protect the institutions that exist for the greater 'good' (business and government).
It just so happens that the richest people control and benefit from both...
I am not saying I have faith in the process (I assume you mean to bring the right candidates to the fore) - what I am saying is that is the process - good, bad, or indifferent.
As for the lying weasles: that is exactly what happens in many cases - to the eventual regret of the hiring manager and everyone who works with said weasel. This is particularly true if the hiring manager does not have a clue as to what the position actually requires (skills, knowledge, experience - wise). This is also why a recommendation holds more weight than a resume in most cases.
I can't find any of the posts or newsgroups for my computer science classes back in the late '80s/early '90s...some interesting and useful info there; I remember using the first Mozaic(sic) in the CS Lab - and we used elm and pine to read newsgroups and mail to read email via command line. Those were the days.
One thing that is interesting if you search the archive is that the amount of spam just grows and grows until usenet is useless - and less general purpose as it was back in the day - becoming handfuls of islands of special interest in a sea of spam. I stopped using it, opting instead for special interest bulletin boards - such as slashdot).
In the early days it was a great communications medium for groups of people; from an archival standpoint it has limited usefulness as it stands (until someone takes the raw data and does a thorough job of indexing it - which given the size of the archive probably won't happen except for small pieces - like this timeline).
What does the future hold? More message boards, or something more intriguing?
You also have to understand most large corporations have human resources people who have to rubber stamp everything - so the description of the job and the requirements could be totally out of whack with reality.
.NET experience - then no one will, unless they are lying), then the resumes will go to the hiring manager who will make further cullings to get an interview list. If you are the best candidate, you will get an interview.
Go ahead and put in for it anyway, because they will use the certs and education to make the first cull (so, in your example: if no one can have 5 years of
One other important factor you should not overlook: in all of the salaried jobs I have achieved, I always had recommendations from people inside the organization, or people outside who had relationships with those on the inside. Hiring managers put stock in what others they trust think of you - more so than just skills alone.
I have stock options that have vested that I can't exersize because the bottom fell out (i.e. lets say I got options at $20, and now the stock is selling for $10).
The last stock options that were issued by my company was several years ago. Since then they have been issueing cash bonuses instead - which those of us holding worthless options welcomed.
(I am hoping the stock market will climb again so I can exersize the options I am holding, but I doubt it will go high enough for those options there were given in recent years - when the stock price was inflated. There is a time limit on how long you can hold them once they vest - so having stock options is a big gamble for you)
You are aware, I hope, that all of those 'other' devices you mentioned have a computer inside of them (defined by central processing unit {variation on Von Neumann machine}, random access memory, read only memory, stored programs {in rom or ram}, and some form of input/output {usb, ethernet, serial, etc..} - writable storage medium - aka harddrive - is optional).
The terms, 'mainframe', 'mini', 'micro' (aka 'personal computer' or 'pc'), are all just marketing terms. A computer is a computer, some are just more specialized in one form or another; at the heart of all of the different types is the basic components of a stored program computer. The newer crop of devices, while having features that are primarily oriented to a specific non-computer area (wireless telephony, washing machine, refrigerator, etc) are still at their core computers.
Marketers love to hawk their wares as the latest thing since sliced bread; at the heart of all the 'new' technology is old technology (in this case technology at least 50 years old) - just a variation on a theme. That is not bad, in fact it is very useful to find new ways to use old technology - to extend its usefulness. Lets just not get too carried away and make sweeping statements - like PCs (computers) are not needed for the internet to function. On the contrary, they always will be needed in one form or another (perhaps they will be analog computers in some far distant future) in order for an internet to exist simply because of the processing required (pattern matching, counting and arithmatic operations at its lowest level).
Furthermore, personal devices that can be dynamically programmed and physically modified to create new interfaces and uses will always be in demand because of their utility and personalization. They certainly won't go away. Will they look like the monstrosities we have sitting under our desks now - no. Will they serve the same functions - yes and more that we haven't even thought of yet. 'Personal Computer' is just that - a computer for the person; today that can be a desktop computer, a personal digital assistant, a cell phone/PDA, or a wearable computer integrated into clothing. The PC will be with us long after you and I are dead.
commodoresloat,
/directory/path/where/mozilla/keeps/the/files/*" you need to replace the "/directory/path/where/mozilla/keeps/the/files/" part with the actual directory path to the files used by Mozilla Firefox.
On the off chance that you are not pulling my leg, I will explain why you got the error message.
I didn't mean for you to literally enter the path I listed in the chmod command. I thought it was obvious what I meant, but let me explain anyway:
In the command, "chmod 700
I used this shorthand because a) the files can be in different locations depending on how you installed your browser, and b) I didn't have time to actually research the details and present a full 'howto' document in these forums - I left that as an exersize for the user.
I appologize if I wasn't clear enough on that. However most application documentation, howtos, and computer books use similar methodology - so my assumption that it would be understandable without further explanation.
"You can download the fix
- here
..." - Any Linux website within a days (perhaps hours) of the report.It is like the clipper chip in this regard: centralized control to protect the interests of the state/big buisness at the expense of the individual.
That is the point I was making, which is not wrong by any twist of the imagination.
I always give myself execute permissions on all of my files - no telling if one is a script or not... (I've seen utility scripts embedded in application folders that contained cache/state and other configuration data).
Additionally, it really doesn't matter for yourself, because if someone manages to login as you, they will be able to change all of the permissions to anything they want anyway. Irrelevant.
How does using IE make it any more likely that this trojan will work?
Because if someone has enabled unsecured (ActiveX) scipting technology on their IE browser, malicious code can execute the trojan after it is on disk. Not so for the Firefox browser - which has no means of accessing the disk via Jscript/Java, etc...
My 2nd point holds: an approximation of zero can in effect be zero for all intents and purposes.
My 3rd point holds: the point was made that a user on a multiuser machine could read the files created by your browser; my answer was to change the permissions on the file to only allow the user to access said files. Why doesn't that work?
You could syncronize the feeds using NTP (network time protocol). Here is how I envision it working:
:)
All of your nodes have a computer connected; all of these nodes get thier timing via NTP from the same clock (doesn't matter which clock, as long as it was one such clock - in fact you could use your master node machine as the master clock, as well).
When the data is sent to the nodes it has time hash information embedded with the music data. The master node would offset the time hash so that the master node and all other nodes broadcast the music simultaneously.
Software would have to be developed to upload, decode, and transmit consistent sized chunks of music data; all of the systems on the array would use this software.
This is the 'what' to do - now someone just needs to determine 'how' to do it and implement it
Can anyone say 'Clipper Chip'?
Remember what happened to that brilliant idea? This is it in a new guise, this time reborn to lock-in traditional media.
Never fear, either too many objections will be raised to make it viable in the marketplace, or some smart person will figure out how it tics...
And you, too will be marginalized as the cows are herded into the new pasture...
What average windoze user encrypts his filesystem? (show of hands!)
I didn't think so. Divide the small number of users who probably encrypt their filesystem, lets say 20,000, by the count of the total number of Windows users (all operating system versions in use, a number hear infinity - lets say several billion).
20,000/2,000,000,000 = 2/200,000 = 1/100,000 ~ 0 (an approximation of zero)
And, I was being generous with the number of windows 'encrypters'.
Grid computing (or a Beowulf cluster; I had to throw that in) also offers some options for leveraging concurrency, and much of the work done to make these systems work could be leveraged within the operating system to do similar things on multi-cpu machines.
I agree - its not there now. I am not so sure an example of the solution won't be here in short order - considering the brick wall that many companies (particularly computer game companies, who are always pushing the edge of the envelope) will be hitting.
Saying it won't happen, is as bad, or worse than saying it will happen on January 7th at 2200 GMT...
Click 'cancel' if you are not sure about what you are downloading; Addtionally, you should be able to hover the mouse over a link and see the actual URL in the display bar at the bottom of the window. I do this all the time because I want to be sure where my browser will be connecting when I click anything. Of course, if you go to sites that don't use standard HTML for their links, you could be scammed. Generally speaking, unless you are running IE, downloading a trojan isn't going to be that bad - as long as you don't then try to run it. If you were expecting a picture, or a zip file, and got an executable instead, that could also tip you off. This is probably the worse problem of the three - but nothing to lose sleep over.
The second issue was created by the way that Mozilla's browsers handle news:// links to newsgroups, hackers can easily create false links and create a buffer overflow (Mozilla 1.7.5 and below, Firefox versions before 1.0).
If you aren't using the latest version of the browser - you are wrong. Additionally, who reads news groups anymore? I gave up wading through all the spam and flame wars long ago...
The third exploit affects machines with multiple users. The way that Firefox and Thunderbird store files allows every user to see them and to probably catch the other user's surfing habits (Firefox and Thunderbird). Let's hope that these will be fixed soon! - should do the trick on most unix/linux systems. I can't see this breaking the browser, because presumably it is being run by you as you. This is irrelevant on a Windoze machine because it is not truely multi-user (and I can slap a knoppix disk into your windows machine, reboot linux, and read all your files provided I have physical access anyway - which is how most people 'share' a windows box).
The only expectation of privacy I have is what goes through my head - and even that is suspect...
Why was it wrong to say the tool should not be compared to the atom bomb? The interviewer created a logical fallacy which he addressed in a more diplomatic way than I would have.
This is like blaming all knife makers, gun makers, shovel makers, car makers, etc. for all the destruction and death caused by these devices when misused. It is rediculous - and does not hold legal water. The interviewer's assumption was right up this alley - and Mr. Cohen's response appropriate.