And by that, I mean the call from the Windows User to the Computer Person to fix something undetermined. And she was cute, so one will agree and mentally review the steps involved in hopefully saving the day. It's a 2-yr-old-ish Vista laptop and this time, I'm not just doing updates but expecting the worst in the way of poorly written Russian adverts and so on. I'm picking it up on Thursday but forged ahead by downloading a new build of Trinity Rescue Kit.
TRK 3.4 is a Linux distro with a payload of tools aimed at Windows repair. The star of the show is a command-line version of ClamAV. I'm assuming viruses have set up housekeeping, so I'll give it the full treatment (boot from the TRK cd and go online for latest signatures, then run against HDD for three or four hours). But after that's done, the usual list will kick in:
0. Ideally, do backups as soon as one gets to a stable desktop (hope springs eternal)
1. Disk Cleanup and chkdisk (file integrity check)
2. Defrag
3. update and run the anti-junkware (Spyware Blaster, SuperAntiSpyware or whatever)
4. update and run any onboard brand-name Antivirus (or download AVG or something if there's nothing already there)
5. OS updates
6. browser updates
7. Flash update
8. Acrobat reader update
9. any other app updates available
That's the seat-of-the-pants list. Better lists exist; this one's probably all I'll have time for this week. Unless she's really persuasive.
RESULT: The laptop didn't even boot, so she let me have the carcass for parts and the effort (I got an HDD and some memory out of it) and she went with a new netbook. Good to reacquaint myself with TRK, though.
Wednesday, February 16, 2011
Tuesday, November 2, 2010
Hardware Adventures
I just got a two-year-old off-lease Dell Optiplex GX520 (one of that boxy-looking line of desktops) and when it arrived I prepared to blow away the included build of WinXP for something else, since I already run that system for purely educational purposes and didn't need another instance of it. I got a surprise as I ran the system before erasing it. The DVD-ROM drive didn't work. So how to load a new system onto the box - not to mention finding the solution to the malfunction (assuming no flash drive load or network install)?
This is an important question for the open source community, inveterate OS reloaders that we are. The Optiplex line is huge and it appears to me that there might be a motherboard issue here that will be an issue in Linux loading - but I'm getting ahead of myself. Here's what happened as I examined XP performance and loaded (full disclosure here) Win7. [Again, for educational purposes! You can't criticize if you're not experienced.]
From an educational source I'd gotten the Win7 upgrade disc and it was to load on top of the XP load present on the 520. Remember, XP either didn't have a driver for the DVD-ROM or there was a plain hardware failure (a Dell driver CD was not provided with the purchase). I proceeded with the Win7 loading by using a USB outboard DVD burner (with proper BIOS setting for boot-from-disc) and then did the updates. The original inboard DVD-ROM still didn't work after a few reboots.
But after a few MORE reboots and the phone ringing in the other room, I returned to see a word balloon in the bottom right corner of the screen announcing a driver update from somewhere (presumably Windows/MS Update). I allowed it and the inboard transport instantly worked.
If a particular piece of software is needed for the box to see and run the ROM drive, this may indicate a need for the open source OS's to be amended accordingly. On the other hand, maybe there exists in the Linux, BSD and/or OSX worlds a generic driver that works just fine. I don't know. What I do know experimentally is that Win7 eventually recognized and updated the issue itself, without my consulting the Dell site for drivers... which I might still need to do for other issues.
I don't recommend staying away from Optiplexes. I'm just putting this your-mileage-may-vary note out there. It's very possible that the problem has already been solved by all concerned parties and there really aren't any reloading problems here. I'm just surprised that Win7 either knew what to do or figured it out. I hereby grudgingly give credit where credit is due.
(Update of 11/8)
So the driver still appears, goes away and then reappears. But the cause is now known. I looked up the Optiplex model on Dell's support site and it turns out that there is no official Windows 7 driver for this model's transport - but that doesn't keep Windows Update from trying. So I'll just continue to use the outboard unit for burning and trust in some programmer in Austin or somewhere to come through for me eventually...
This is an important question for the open source community, inveterate OS reloaders that we are. The Optiplex line is huge and it appears to me that there might be a motherboard issue here that will be an issue in Linux loading - but I'm getting ahead of myself. Here's what happened as I examined XP performance and loaded (full disclosure here) Win7. [Again, for educational purposes! You can't criticize if you're not experienced.]
From an educational source I'd gotten the Win7 upgrade disc and it was to load on top of the XP load present on the 520. Remember, XP either didn't have a driver for the DVD-ROM or there was a plain hardware failure (a Dell driver CD was not provided with the purchase). I proceeded with the Win7 loading by using a USB outboard DVD burner (with proper BIOS setting for boot-from-disc) and then did the updates. The original inboard DVD-ROM still didn't work after a few reboots.
But after a few MORE reboots and the phone ringing in the other room, I returned to see a word balloon in the bottom right corner of the screen announcing a driver update from somewhere (presumably Windows/MS Update). I allowed it and the inboard transport instantly worked.
If a particular piece of software is needed for the box to see and run the ROM drive, this may indicate a need for the open source OS's to be amended accordingly. On the other hand, maybe there exists in the Linux, BSD and/or OSX worlds a generic driver that works just fine. I don't know. What I do know experimentally is that Win7 eventually recognized and updated the issue itself, without my consulting the Dell site for drivers... which I might still need to do for other issues.
I don't recommend staying away from Optiplexes. I'm just putting this your-mileage-may-vary note out there. It's very possible that the problem has already been solved by all concerned parties and there really aren't any reloading problems here. I'm just surprised that Win7 either knew what to do or figured it out. I hereby grudgingly give credit where credit is due.
(Update of 11/8)
So the driver still appears, goes away and then reappears. But the cause is now known. I looked up the Optiplex model on Dell's support site and it turns out that there is no official Windows 7 driver for this model's transport - but that doesn't keep Windows Update from trying. So I'll just continue to use the outboard unit for burning and trust in some programmer in Austin or somewhere to come through for me eventually...
Thursday, September 30, 2010
"A man's gotta know his limitations." - a famous Clint Eastwood character
Radio ads are now being heard in my area touting something called "Xfinity Home Security" from Comcast cable. The idea is that it would be really great to be able to control a home security system from your smart phone. I'm afraid this indicates that online convenience will soon prove more popular than security, even within the security products market - truly a new irony. If Comcast saw a potential market for such a thing, consider the possibilities...
Assume that the application security issues are solved (the code is secure). That leaves out any problems with the remote interface and the installed app at home. Let's also assume that the Internet Service Provider's servers are properly maintained and in secure configuration. And since this is an extension of ADT home security, we'll assume that there are no problems on their end (any and all physical and software interfaces). What does that leave? Well, at home, it leaves the thing that the (secure in this example) stuff is installed TO, namely the home computer. This is a computer not maintained by Comcast or by ADT or by the ISP (although their systems are possibly impeachable in other examples). This computer's Administrator Of Record is Joe Sixpack, probably with a few wife/kid computers on a $79 router. The last such computer that I looked at for somebody was as secure as a screen door on a submarine.
[Observe: To get into secure app XYZ on user's computer, obtain access to the base Operating System. Since this machine is running a series of security devices, assume 24/7 online stance. This gives you lots of time to run a... "password recovery program". Or to look for cached login info from OS to app. Bingo. You get into the secure app from the OS that the home user failed to configure correctly or patch regularly. This resembles the MANY examples of an outfit getting invaded through a telecommuter workstation left up and online.]
{Another aside: If you replaced the user machine in the above scheme with an appliance, that would eliminate my main objection. Not that appliances haven't had updating and hardening problems, though...}
The larger point? We from the Unix/open source side would not immediately have these problems since all the linking apps aren't available for Linux, Solaris or such. But the problem that remote access for home security poses is that it's not the systems that pose the biggest chance for failure. It's the judgment of the user. It's what the user has authorized to run locally. It's whether or not one should have remote access to things like history logs that record when a door was opened/closed over the last 60 days. Or streaming video in the garage or kitchen. Linux or OpenWhatever can solve lots of problems when replacing systems less secure, but it can't make the user smarter. This is our Limitation as open source advocates: open source can't fix everything. Not only must we evangelize about some system choice where possible; we must warn against giving out one's email address too much, or clicking on a strange web link, or opening that attachment. Those are problems in any system configuration, use or policy stance.
Assume that the application security issues are solved (the code is secure). That leaves out any problems with the remote interface and the installed app at home. Let's also assume that the Internet Service Provider's servers are properly maintained and in secure configuration. And since this is an extension of ADT home security, we'll assume that there are no problems on their end (any and all physical and software interfaces). What does that leave? Well, at home, it leaves the thing that the (secure in this example) stuff is installed TO, namely the home computer. This is a computer not maintained by Comcast or by ADT or by the ISP (although their systems are possibly impeachable in other examples). This computer's Administrator Of Record is Joe Sixpack, probably with a few wife/kid computers on a $79 router. The last such computer that I looked at for somebody was as secure as a screen door on a submarine.
[Observe: To get into secure app XYZ on user's computer, obtain access to the base Operating System. Since this machine is running a series of security devices, assume 24/7 online stance. This gives you lots of time to run a... "password recovery program". Or to look for cached login info from OS to app. Bingo. You get into the secure app from the OS that the home user failed to configure correctly or patch regularly. This resembles the MANY examples of an outfit getting invaded through a telecommuter workstation left up and online.]
{Another aside: If you replaced the user machine in the above scheme with an appliance, that would eliminate my main objection. Not that appliances haven't had updating and hardening problems, though...}
The larger point? We from the Unix/open source side would not immediately have these problems since all the linking apps aren't available for Linux, Solaris or such. But the problem that remote access for home security poses is that it's not the systems that pose the biggest chance for failure. It's the judgment of the user. It's what the user has authorized to run locally. It's whether or not one should have remote access to things like history logs that record when a door was opened/closed over the last 60 days. Or streaming video in the garage or kitchen. Linux or OpenWhatever can solve lots of problems when replacing systems less secure, but it can't make the user smarter. This is our Limitation as open source advocates: open source can't fix everything. Not only must we evangelize about some system choice where possible; we must warn against giving out one's email address too much, or clicking on a strange web link, or opening that attachment. Those are problems in any system configuration, use or policy stance.
Sunday, September 26, 2010
User Experience Report: OpenSUSE LINUX 11.3
Briefly, here's how I've spent some of the last two days: on a 2004-vintage 2.7ghz Celeron (HP) with 3/4 gig of ram, I've kicked the tires on openSuse.org's latest offering and there's good news and bad.
On the bad side, around a half dozen reboots were required for all the hardware detection to appear to have completed satisfactorily. Also, in spite of the networking section getting out to the internet after a boot or two, the app that looks for updates still hasn't seemed to have found any. I'll try the many command-line options soon out of impatience.
On the good side, the interface is slick and many included apps perform acceptably well. Audio CD played back with no reconfiguration, startup chimes and confirm tones were present and consistent, reboot time sped up after a few instances (it might be saving last-known-good-state info in many places), and OpenOffice was pretty quick and stable even during first use setup.
Too early to tell, really, but at the moment it looks like I'd rate 11.3 as similar to other recent offerings from the Novell/SUSE camp: a worthy contender but needs polish. I've not had quite this many bumps even from recent Fedoras, let alone Linux Mint or other Ubuntu variants. Another thing: I'm covering the simple desktop stuff for a reason. If one wants to impress the Windows people who are coming over out of curiosity, the simple stuff has to work. I realize that I could use rpm or yum command lines and that it might be better to do so. But if an Updater Applet is right there in the tray waiting to be used, it should work. And in 11.2, it DID.
Next project will probably be to get the newer laptop thrown together and install BackTrack 4 to the HD and frolic through that famous and extensive tool collection. Oh, and the Celeron 2.7? Back to CentOS!
On the bad side, around a half dozen reboots were required for all the hardware detection to appear to have completed satisfactorily. Also, in spite of the networking section getting out to the internet after a boot or two, the app that looks for updates still hasn't seemed to have found any. I'll try the many command-line options soon out of impatience.
On the good side, the interface is slick and many included apps perform acceptably well. Audio CD played back with no reconfiguration, startup chimes and confirm tones were present and consistent, reboot time sped up after a few instances (it might be saving last-known-good-state info in many places), and OpenOffice was pretty quick and stable even during first use setup.
Too early to tell, really, but at the moment it looks like I'd rate 11.3 as similar to other recent offerings from the Novell/SUSE camp: a worthy contender but needs polish. I've not had quite this many bumps even from recent Fedoras, let alone Linux Mint or other Ubuntu variants. Another thing: I'm covering the simple desktop stuff for a reason. If one wants to impress the Windows people who are coming over out of curiosity, the simple stuff has to work. I realize that I could use rpm or yum command lines and that it might be better to do so. But if an Updater Applet is right there in the tray waiting to be used, it should work. And in 11.2, it DID.
Next project will probably be to get the newer laptop thrown together and install BackTrack 4 to the HD and frolic through that famous and extensive tool collection. Oh, and the Celeron 2.7? Back to CentOS!
Thursday, September 23, 2010
This Is What I'm Talking About
Here's a quote from Chapter 5 of the Eric Raymond book (The Art Of Unix Programming) that I'm reading without actually being a programmer:
"In the following discussion, when we refer to “traditional Unix tools” we are intending the combination of grep(1), sed(1), awk(1), tr(1), and cut(1) for doing text searches and transformations. Perl and other scripting languages tend to have good native support for parsing the line-oriented formats that these tools encourage."
This is from the 'Data File Metaformats' heading in the chapter entitled "Textuality", touting the value of things being done as widely-understood text streams as opposed to the use of relatively more cryptic closed methods.
Simply referring to such a concept of "traditional Unix tools" helps reinforce what newcomers to Unix methodology are seeking to learn. This would also hold up in greater relief the point of contact between the Windows command line and Unix, as tools have been ported from one world to the other, and can be available for use in both.
"In the following discussion, when we refer to “traditional Unix tools” we are intending the combination of grep(1), sed(1), awk(1), tr(1), and cut(1) for doing text searches and transformations. Perl and other scripting languages tend to have good native support for parsing the line-oriented formats that these tools encourage."
This is from the 'Data File Metaformats' heading in the chapter entitled "Textuality", touting the value of things being done as widely-understood text streams as opposed to the use of relatively more cryptic closed methods.
Simply referring to such a concept of "traditional Unix tools" helps reinforce what newcomers to Unix methodology are seeking to learn. This would also hold up in greater relief the point of contact between the Windows command line and Unix, as tools have been ported from one world to the other, and can be available for use in both.
Tuesday, August 10, 2010
Some Resource Links For Yez
Dell Vostro V13 laptop (Ubuntu option available):
Click!
System76 desktop, laptop and server models w/Ubuntu:
Click!
Are you a business and want SUSE with support included (BYO hardware)?
Click!
Note: I hold no stock or other financial interest in any of these concerns BUT I WISH I DID.
Click!
System76 desktop, laptop and server models w/Ubuntu:
Click!
Are you a business and want SUSE with support included (BYO hardware)?
Click!
Note: I hold no stock or other financial interest in any of these concerns BUT I WISH I DID.
Sunday, August 8, 2010
Kinda Linux But More Of An Open Source Posting (as usual lately)
...But linux IS involved! My past as a users' group president in Linux Land is not at all being denied here; I just digress lots. See what you think:
Our pals at LINUX JOURNAL put out this word about the OpenSolaris issue not long ago. It's not an alarmist article; it raises legit questions about whether Oracle values Unix dreadnought Sun's legacy or not. Well, aside from the decision whether or not to continue making certain code chunks widely available through OpenSolaris, Oracle seems to be trumpeting the virtues of the main event clearly enough.
Now there's this. The Illumos initiative may save the day.
My take on all this is that within the OpenSolaris orbit, projects like Nexenta were valuable to Solaris for general Unix PR, as well as for its own products. Nexenta in particular could get Linux people interested in toying with things like ZFS if only due to the Debian tools included, not the least of which is apt-get (and it works!! at least on SOME of my loads). This appeals to my if-it's-Unix-it's-cool ethic. The problem with continuation of the OpenSolaris project would be that Oracle might not be so forthcoming with the big section of proprietary code that's in OpenSolaris and that Oracle now owns. Illumos would solve that quandary if successful. I usually worry about distro forks, but this might be a good one - if one can even call it a fork.
ON A RARE PERSONAL NOTE: Some of you know that I work for an outfit that has a "boonies" location and a "Central" location and that I've been in the boonies for awhile. I AM NOW at Central! Thank you for your discretion.
Our pals at LINUX JOURNAL put out this word about the OpenSolaris issue not long ago. It's not an alarmist article; it raises legit questions about whether Oracle values Unix dreadnought Sun's legacy or not. Well, aside from the decision whether or not to continue making certain code chunks widely available through OpenSolaris, Oracle seems to be trumpeting the virtues of the main event clearly enough.
Now there's this. The Illumos initiative may save the day.
My take on all this is that within the OpenSolaris orbit, projects like Nexenta were valuable to Solaris for general Unix PR, as well as for its own products. Nexenta in particular could get Linux people interested in toying with things like ZFS if only due to the Debian tools included, not the least of which is apt-get (and it works!! at least on SOME of my loads). This appeals to my if-it's-Unix-it's-cool ethic. The problem with continuation of the OpenSolaris project would be that Oracle might not be so forthcoming with the big section of proprietary code that's in OpenSolaris and that Oracle now owns. Illumos would solve that quandary if successful. I usually worry about distro forks, but this might be a good one - if one can even call it a fork.
ON A RARE PERSONAL NOTE: Some of you know that I work for an outfit that has a "boonies" location and a "Central" location and that I've been in the boonies for awhile. I AM NOW at Central! Thank you for your discretion.
Subscribe to:
Posts (Atom)