Often the user doesn't even see txt.pif! The Windows default is to hide extentions. The average user sees a.txt file, but its really.txt.pif or txt.vbs or even txt.exe!
So what's to stop him from stealing our new "portable supernova" with box-cutters? And how much technical skill is needed to introduce bugs into Windows?
I need to know certain things about my car. I need to know where the gas/brake pedals are, how to steer, and when to change the oil. I DON'T need to know how to fix the damn thing - that's what professionals are for. The same thing is true for computers. The end user should know certain things, but to him/her the computers just a tool. S/he can't be expected to have the same knowhow managing the computer that I do. Systems need to be easier for the nurses, the accountants, the lawyers (scratch that last one, let them suffer)
"The trouble is that developers typically see things differently from users. Things of critical importance to someone working deep in the bowels of code may not matter at all to someone who just calls it through an API or who uses the program. "
BINGO!!! A few years ago, I had to redo some really crappy documentation which, IMO, missed both target audiences. I looked at it and said "WTF! I can get this info by looking at the ***king source". My boss looked at it and said "WTF! What is this gobledy-gook!". When I rewrote it I concentrated on WHAT the program was doing, not HOW it was doing it.
I actually thought the concept was cool, but, IMHO, Microsoft Bob bombed for several reasons. It required 8 Megs Ram at a time when a 4 meg machine cost $2500. That killed it for the casual user. It was also inflexible. That killed it for the power user.
The best tool I know of to navigate my HD is Midnight Commander under Linux. It's much faster than the GUI and doesn't require a rodent, and you can actually see where you are and what files/directories are there, unlike bash.
"The whole issue has been studied to death. CLI users are *not* more efficient or quicker, except for some edge case tasks. There is the significant disadvantage of memorizing commands. Unless you are doing system administration or heavy file manipulation, there's absolutely no reason to use a CLI. "
Well, I AM more efficient typing commands on a good CLI than I am wiggling a GUI mouse. The need to memorize the commands is a problem (to a newbie) and, IMO, is the main reason users gravitated to GUI's, but someone who knows what they're doing can be more productive on a CLI than on any GUI that I know of.
I've never used PayPal, but to give anybody access to my bank account would require a VERY high level of trust. Simply hearing from 5 Anonymous Cowards that it was hard to phone them would be enough for me to say "NO WAY!!!" Not only can I phone my bank, but I can also stop in personally and talk to someone resembling a human being. Until PayPal is comparable, I say NO!
Good point! I just backup my/home stuff, my/var/mail, and a few selected files. I use my windows partition for quick & dirty backups (it's pretty reliable as long as Windows isn't running), and my 100M IoMega for safer backups. Anything else, I can restore off my Linux CD.
I frequently use upgradepkg to upgrade my Slack software. And I seldom have any problem breaking things. In contrast, the last time I tried Debian, an attempt to upgrade Debian stale (stable?) to woody broke X, broke my online access, and probably broke a bunch of other stuff too. I said bad words, and returned to Slack. It may be a bit cumbersome at times, but it doesn't break.
This is proof that there's life on Mars. Everyone knows the real cause of global warming is farting cows! There must be cows on Mars. BTW, there also used to be vast herds on Venus, standing around cuttin the cheese. You can see the result.
"What mistake did borland make with Turbo Pascal? Turbo Pascal had a long and fruitful life. Have you ever heard of Delphi? It's a language based on pascal go look into it some day. "
Turbo Pascal was a great product for its day, but IIRC, it couldn't handle large scale programs (>64K) as well as C. By the time Borland corrected that error, everyone else was using C. Maybe, if Borland had acted sooner, Delphi wouldn't be "that other language". Also, every other Windows based C++ vendor (Watcom, Symatic) standardized on MFC (Microsoft Frustration Classes), with Borland as the only one using its OWL classes (superior framework, but MFC became the standard).
One way to keep your car from getting stolen is to put a sign on it that says "Steal me please!". I did that with one of my cars, and it never got stolen. Of course, it was a POS!
99% of the time, I worked with the existing code. But there was one program that was so GD awful, everyone was afraid to touch it. So, during a slow period, I tried rewriting it from the specs. When I unit-tested it, it didn't work right (the specs sucked), but since the working version was still running in production, I had time to research and track down the problems. When I got it past my tests, I consulted with the lead programmer on that project, and we ran additional tests. When we were satisfied, we went to the boss, and after he warned the users (it was in-house so we could talk directly to the end-users) to check the reports extra-close, we released it. If there had been any problems, we were in a position to re-run with the old software. Rewrites are risky, but can be done if you're careful.
But what if you get email that you expect with a virus that you didn't?
Often the user doesn't even see txt.pif! The Windows default is to hide extentions. The average user sees a .txt file, but its really .txt.pif or txt.vbs or even txt.exe!
Uranus is one of the watery twins? Maybe the sumerians just had the runs!
KDE runs reasonably well on my K6 450 with 64 Meg Ram. It's no speed demon, but it's tolerable.
So what's to stop him from stealing our new "portable supernova" with box-cutters? And how much technical skill is needed to introduce bugs into Windows?
That's EXACTLY what's wrong with Windows. It tries to help but it's not smart enough, so I'm better off doing it myself.
I need to know certain things about my car. I need to know where the gas/brake pedals are, how to steer, and when to change the oil. I DON'T need to know how to fix the damn thing - that's what professionals are for. The same thing is true for computers. The end user should know certain things, but to him/her the computers just a tool. S/he can't be expected to have the same knowhow managing the computer that I do. Systems need to be easier for the nurses, the accountants, the lawyers (scratch that last one, let them suffer)
WIN-D doesn't seem to do anything on my NT system at work. WIN-E, WIN-R, and WIN-M work right.
"The trouble is that developers typically see things differently from users. Things of critical importance to someone working deep in the bowels of code may not matter at all to someone who just calls it through an API or who uses the program. "
BINGO!!! A few years ago, I had to redo some really crappy documentation which, IMO, missed both target audiences. I looked at it and said "WTF! I can get this info by looking at the ***king source". My boss looked at it and said "WTF! What is this gobledy-gook!". When I rewrote it I concentrated on WHAT the program was doing, not HOW it was doing it.
I actually thought the concept was cool, but, IMHO, Microsoft Bob bombed for several reasons. It required 8 Megs Ram at a time when a 4 meg machine cost $2500. That killed it for the casual user. It was also inflexible. That killed it for the power user.
The best tool I know of to navigate my HD is Midnight Commander under Linux. It's much faster than the GUI and doesn't require a rodent, and you can actually see where you are and what files/directories are there, unlike bash.
Anybody who sends Chinese spam to America is stupid! Of course, the ones who send American spam to America are stupid too.
Really! I thought 2.4.15 was a 2.5 kernel in disguise!
6. But I just compiled $KERNEL_VERSION - 1!
I bet 2.5.1 is better than 2.4.15-dead-duck!
But is it any good on an i386/586?
"The whole issue has been studied to death. CLI users are *not* more efficient or quicker, except for some edge case tasks. There is the significant disadvantage of memorizing commands. Unless you are doing system administration or heavy file manipulation, there's absolutely no reason to use a CLI. "
Well, I AM more efficient typing commands on a good CLI than I am wiggling a GUI mouse. The need to memorize the commands is a problem (to a newbie) and, IMO, is the main reason users gravitated to GUI's, but someone who knows what they're doing can be more productive on a CLI than on any GUI that I know of.
I've never used PayPal, but to give anybody access to my bank account would require a VERY high level of trust. Simply hearing from 5 Anonymous Cowards that it was hard to phone them would be enough for me to say "NO WAY!!!" Not only can I phone my bank, but I can also stop in personally and talk to someone resembling a human being. Until PayPal is comparable, I say NO!
Good point! I just backup my /home stuff, my /var/mail, and a few selected files. I use my windows partition for quick & dirty backups (it's pretty reliable as long as Windows isn't running), and my 100M IoMega for safer backups. Anything else, I can restore off my Linux CD.
"Who out there is afraid of setting the gaps on their spark plugs and changing their oil?"
I am! I'm a software guy, I don't do hardware.
"How about cooking?"
My cookings fine, just don't make me eat the stuff!
I frequently use upgradepkg to upgrade my Slack software. And I seldom have any problem breaking things. In contrast, the last time I tried Debian, an attempt to upgrade Debian stale (stable?) to woody broke X, broke my online access, and probably broke a bunch of other stuff too. I said bad words, and returned to Slack. It may be a bit cumbersome at times, but it doesn't break.
This is proof that there's life on Mars. Everyone knows the real cause of global warming is farting cows! There must be cows on Mars. BTW, there also used to be vast herds on Venus, standing around cuttin the cheese. You can see the result.
"What mistake did borland make with Turbo Pascal? Turbo Pascal had a long and fruitful life. Have you ever heard of Delphi? It's a language based on pascal go look into it some day. "
Turbo Pascal was a great product for its day, but IIRC, it couldn't handle large scale programs (>64K) as well as C. By the time Borland corrected that error, everyone else was using C. Maybe, if Borland had acted sooner, Delphi wouldn't be "that other language". Also, every other Windows based C++ vendor (Watcom, Symatic) standardized on MFC (Microsoft Frustration Classes), with Borland as the only one using its OWL classes (superior framework, but MFC became the standard).
One way to keep your car from getting stolen is to put a sign on it that says "Steal me please!". I did that with one of my cars, and it never got stolen. Of course, it was a POS!
99% of the time, I worked with the existing code. But there was one program that was so GD awful, everyone was afraid to touch it. So, during a slow period, I tried rewriting it from the specs. When I unit-tested it, it didn't work right (the specs sucked), but since the working version was still running in production, I had time to research and track down the problems. When I got it past my tests, I consulted with the lead programmer on that project, and we ran additional tests. When we were satisfied, we went to the boss, and after he warned the users (it was in-house so we could talk directly to the end-users) to check the reports extra-close, we released it. If there had been any problems, we were in a position to re-run with the old software. Rewrites are risky, but can be done if you're careful.