News for nerds, stuff that matters
Sections
About
Slashdot Log In
CleverNickName (129189)
Journal of CleverNickName (129189)
More Computer Fun
Yesterday, I met Chris D for breakfast, joked about Maisy, got to meet his really cool wife and adorable daughter. The plan was to eat, and then head to my house so he could help me with some computer problems I've been having.
After breakfast, I tell him to just follow me there, but he tells me the he only needs the address, because he can input that info into his car, and it will just tell him where to go, like Knight Rider, or something.
Okay, Chris has this car that's like the freakin' Enterprise, man. It's got this integrated GPS system, and I'm pretty sure there are photon torpedoes under the hood, but I didn't get a chance to look. The thing is sleek and black, with tinted windows and leather seats. My little Golf TDI is like Rocketship-XM to his Battle Star Galactica.
We get to my house, and I'm a little embarrassed, to be honest...the technology level in my house is just lame. Most of my stuff is really out of date, and I'm nowhere near the cutting edge. Since I got married, and became responsible for providing for 3 other people, I haven't been able to buy as many toys as I once did.
Anyway, Chris sits down at my desk, and 30 minutes later, my two computers are talking to my WAP and getting online, I'm planning on warchalking my driveway, and everything is right with the world.
It felt odd to me, sitting here with one of the most well-known members of the OS community, while he fixed my lame computer problems. It got me thinking about how the Linux world has welcomed me in so graciously and made me feel so at home, and so many people are asking me to be a spokesman and stuff, and I don't even know how to set up a network printer.
I said that I want to be the world's biggest Linux cheerleader, right?
Damn, I have a long way to go.
Linux users being helpful (Score:2)
I did eventually learn the system, and try to help anyone that asks questions. I hope this is a sign that things are turned around. But, then again, you are a celebrity that most linux users know, and would help without issue.
Not trying to troll or anything, just what I went through to learn linux.
Re:Linux users being helpful (Score:2)
When I was installing a new system a few months ago, I came upon some issues I thought I knew how to deal with, but was at a loss and unable to work things out. Five minutes talking with the guys in #debian and I had things up and running.
In other words, I've found the user base great and support very fast and helpful. Very few people get ridiculed for not knowing something (although sometimes someone says something which just begs for a snappy retort).
Before you go anywhere and start asking questions, I highly recommend you read ESR's HOWTO ask smart questions [tuxedo.org]. Most of his comments are obvious, but there are subtle things many people forget. It really makes a difference, both in the ability for you to get a speedy and accurate response, or for you to provide an accurate reponse to someone else.
Re:Linux users being helpful (Score:2)
If there was anything behind the rationale for me to start doing Ask Slashdot, it was this. I gotta tell you it has been one bittersweet ride. Fortunately more sweet, than bitter, and even saying that, it's been the best experience of my life.
Enough navel gazing now... me go back to playing with my new Titanium Powerbook.
Don't worry about it (Score:1)
Seriously, don't worry about the learning curve. Anybody who claims they don't have a ton of things to learn about linux (and associated utilities) in general is lying.
Keep plugging away and you'll get there. 8)
And you should know... (Score:4, Funny)
And? (Score:2)
If not... Maybe I could lure you into the wonderful world of FreeBSD ;-)
Celebrity Status Hurts (Score:2)
That said, IMHO, manually setting up a printer (correctly) is probably the single most complex task in Unix. Ghostscript can be one big pain in the ass.
Although, Linux does not seem to be focusing on the knowledgable users... it seems to be a holy war being waged against M$ on the "Easy for Joe Sixpack to Use"-front.
But, if you are looking for something simple (*Ahem*) use one of the BSDs (OpenBSD recomend)... It's much less complex. You have to edit (less than a handful of) text files yourself, but that's much simpler than learning the quirks of 50 different configurations tools that each only partially work anyhow...
Re:Celebrity Status Hurts (Score:2)
I guess great minds think alike...rofl. One thing, though,
While I very much agree with you in *BSD's coolness, Linux is based on a handful of config files as well; "Joe Sixpack" distros simply provide gui bindings to them. Of course, Mandrake's gui tools are very intuitive. Anyways, if you go with a more hacker-oriented distro like Debian, Gentoo (if some of their users could stop being so obnoxious :), Crux, etc, you'll find vi to be just as essential. Well, actually I have nano on my system, but then again I'm not terribly 'l337.'
Re:Celebrity Status Hurts (Score:2)
Umm, no. Linux is based on a truckload of config files. I don't have a linux system on hand to locate them all, the SysV scripts come to mind... (/etc/rc.*) which is all just one very simple file on the BSDs (Change YES to NO or vise versa).
BSDs are PnP so you don't have to detect, configure and load modules, so no modules.conf. Depending on the distro, you may have an
And BTW, Mandrake's tools aren't too bad (interface-wise), but they are far from intuitive, are far more complicated than they need to be (why is setting an IP address a 20 step process?), and I've come across several instances (on just one system) where they just didn't make the configuration changes needed. Those included NOT sticking the NIC module in
Re:Celebrity Status Hurts (Score:2)
My system, which I set up myself [linuxfromscratch.org], had well under 12 (handful) config files to set up, the rest coming from differen apps I chose to install on top of the base system. Most distros just have really bad taste. One argument this certainly is pertenint is the fact that different apps have different syntaxes for config files.
BTW Sys5 are not the only way to go--my system has 2 bootscripts, rc.up and rc.down--even simpler that *BSD! Again, some find Sys5 to be elegant. My point is that none of your claims are Linux's "fault," though there is a definate problem of Distros taking too much creative liberty and making things suit their (often) far fetched ideas.
I don't recall now, but there's a Linux distro that has a /server dir, and all sorts of server apps, apache, etc, are placed in their own subdirs, and $PATH includes all of them!
Re:Celebrity Status Hurts (Score:2)
It may as few as OpenBSD (depending on how you look at it) I'd be willing to bet that reconfiguration is far more complex for you than with OpenBSD.
See, this is a problem... What do you consider a config that comes with the base system? How about
That was the very reason I avoided a blow-by-blow description.
I can assure you, just the few config files required by the Linux kernel, outnumbers the total files needed in OpenBSD for boot-up, shutdown, and configuration of both.
Re:Celebrity Status Hurts (Score:2)
Re:Celebrity Status Hurts (Score:1)
Also, shoving everything into one central Registry ensures that some sort of GUI had to be wrapped around it all, no other way to work it, heh.
Seriously though, even in DOS setting up a printer just meant plugging it in, heh. Of course that was for Text only printing, anything more complicated then that and some sort of printer driver was needed (which of course, being DOS, was provided on a Per Program basis, heh).
Now days in Windows, just plug it in. Most printers from the major manufacturers have been able to latch onto some sort of minimalistic basic driver set for awhile now, so at bare minimum getting a printer up and running under Windows 98 or newer means plugging it in and, err, well. That is pretty much it. Period. Heh.
(Rosia was fairly amazed when XP didn't even bother to install drivers and just kind of chucked the printer up onto the listing, lol. I use 2K/98 myself and both handle my constant printer plugging and unplugging quite graciously. ^_^ )
Re:Celebrity Status Hurts (Score:2)
Re:Celebrity Status Hurts (Score:1)
Fairly simple configuration files, but even for an expert user they could take a few hours to get tweaked properly.
Now days if I want to change the settings on something I have to pop into the registry at worst. Text editor? Sure in Windows 98 a little bit, and in Windows95 a fair bit more, but since Windows 2k. Sorry to say it, but nope. I had to drop to DOS a few times to fix some, err, "issues" I was having with my video card (thankfully Matrox provides command line tools for exactly those occasions when the user flummoxes their dual head config and gets the settings panel waaaay off of anything resembling usable screen real estate. ^_^ ) but besides that, it was all configurable through a nice GUI.
The issue is that there are configuration options to throw around. Hardly any *nix programs come with built in configuration utilities, heck even in DOS applications where expected to have some sort of front-end for configuring them. Just because the configuration is stored in a Human Readable format does not mean that there is an excuse not to write some sort of front end for that file in the bare minimum.
Optimally if the current mixed bag configuration file format was to be kept, it would be done so in some sort of a standardized way that a simple spidering application could crawl through and the configuration files would have line by line help built into them as well as specified variable ranges of some sort where appropriate.
Hey, I did not believe it either when the idea was first suggested to me, but having a coordinated centralized standardized configuration scheme for everything on the computer is a more efficent way to operate.
Re:Celebrity Status Hurts (Score:2)
Autoexec.bat and Config.sys are very simple. The people that have a hard time with it, are certainly not the ones who edit the registry with ease.
Besides... going into
It's cleaner, it's neater, it's easier, it's more flexible, it can be better secured, etc, etc.
trust me. Your talking to someone who's spent thousands of hours tweaking Windows registries, boot.ini files, ini files, permissions, etc. on hundreds of Windows machines, workstations, servers, all just to try make a Windows machine last one day longer before having to be reloaded from scratch, or being a little more stable while it was running. Not a job I'd even consider doing again, and one that is ultimately futile.
Re:Celebrity Status Hurts (Score:1)
.
.
.
Your talking to someone who's spent thousands of hours tweaking Windows registries, boot.ini files, ini files, permissions, etc. on hundreds of Windows machines, workstations, servers, all just to try make a Windows machine last one day longer before having to be reloaded from scratch,
Use any of the number of registry freezing tools to ensure that once a workstation has been setup stable that it does not change configuration from reboot to reboot. Get all of your applications installed right the first time (no duplicate entries and all that, ick), and get everything setup, and then freeze the darn thing in its tracks.
My favorite setup is actually the ones that load the hard drive from a network image upon each boot, though I think that storing the image file in a hidden partition in some format that Windows cannot touch would be a far better way of achieving the same goal.
A lot of the registry's[*1} problems are do to poorly designed 3rd party software that does not completely remove itself from the registry, sometimes by design! Some programs keep a log in the registry if a piece of demo software has been installed before, others keep track of the date that they where last ran at, so as to ensure that if the user changes the date back a bit that the program will be able to detect it if it does a compare of the stored date vs the current date.
Those are all inappropriate (not to mention, *cough cough easily bypassed) uses of the registry. In my experience 3rd party software is the primary cause of registry bloat.
Though I will admit that Windows will at times make, err, random changes to the registry, heh. Weird stuff like randomly deciding that a printer should no longer be default, in situations where the administrator has privileges locked down so that no user could have possibly have changed it from being the default, but as I said, just freezing the status of the registry after the machine has reached its designed working status should do just fine for those situations.
The thing about the registry as a central storage location for data is that it makes software authors go about and implement some sort of front end for configuring their software. Even a Window's administrator would not put up with having to edit a thousand and one configuration files all full of little bits of data that could have very easily had a nice GUI front end wrapped around them.
The main advantage of a GUI front-end is that it consolidates what might be multiple configuration files into one grouped together location where all of the configuration variables can be easily viewed together as a group and problems amongst the configuration variables may be easily spotted just by doing a quick visual comparison.
"Well checkbox Enable Feature is checked, but ah! That feature has a dependency feature that has to be enabled, *click* Ok it should work now!"
This is versus reading through two separate configuration files line by line trying to find out why Feature A is not working even though it was set to enabled in Configuration File A.
Depends on how well documented it has been, and how lazy the programer has been. Kinda the same as the registry really, heh. The programer is the one who decides how clean and neat any given system of storing configuration data is, I am just saying that I believe the registry forces programers to at least spend an extra second or two thinking about how the user is going to access that configuration data.
.
.
.
Your talking to someone who's spent thousands of hours tweaking Windows registries, boot.ini files, ini files, permissions, etc. on hundreds of Windows machines, workstations, servers, all just to try make a Windows machine last one day longer before having to be reloaded from scratch,
Use any of the number of registry freezing tools to ensure that once a workstation has been setup stable that it does not change configuration from reboot to reboot. Get all of your applications installed right the first time (no duplicate entries and all that, ick), and get everything setup, and then freeze the darn thing in its tracks.
My favorite setup is actually the ones that load the hard drive from a network image upon each boot, though I think that storing the image file in a hidden partition in some format that Windows cannot touch would be a far better way of achieving the same goal.
A lot of the registry's[*1} problems are do to poorly designed 3rd party software that does not completely remove itself from the registry, sometimes by design! Some programs keep a log in the registry if a piece of demo software has been installed before, others keep track of the date that they where last ran at, so as to ensure that if the user changes the date back a bit that the program will be able to detect it if it does a compare of the stored date vs the current date.
Those are all inappropriate (not to mention, *cough cough easily bypassed) uses of the registry. In my experience 3rd party software is the primary cause of registry bloat.
Though I will admit that Windows will at times make, err, random changes to the registry, heh. Weird stuff like randomly deciding that a printer should no longer be default, in situations where the administrator has privileges locked down so that no user could have possibly have changed it from being the default, but as I said, just freezing the status of the registry after the machine has reached its designed working status should do just fine for those situations.
The thing about the registry as a central storage location for data is that it makes software authors go about and implement some sort of front end for configuring their software. Even a Window's administrator would not put up with having to edit a thousand and one configuration files all full of little bits of data that could have very easily had a nice GUI front end wrapped around them.
The main advantage of a GUI front-end is that it consolidates what might be multiple configuration files into one grouped together location where all of the configuration variables can be easily viewed together as a group and problems amongst the configuration variables may be easily spotted just by doing a quick visual comparison.
"Well checkbox Enable Feature is checked, but ah! That feature has a dependency feature that has to be enabled, *click* Ok it should work now!"
This is versus reading through two separate configuration files line by line trying to find out why Feature A is not working even though it was set to enabled in Configuration File A.
Depends on how well documented it has been, and how lazy the programer has been. Kinda the same as the registry really, heh. The programer is the one who decides how clean and neat any given system of storing configuration data is, I am just saying that I believe the registry forces programers to at least spend an extra second or two thinking about how the user is going to access that configuration data.
.
.
.
Your talking to someone who's spent thousands of hours tweaking Windows registries, boot.ini files, ini files, permissions, etc. on hundreds of Windows machines, workstations, servers, all just to try make a Windows machine last one day longer before having to be reloaded from scratch,
Use any of the number of registry freezing tools to ensure that once a workstation has been setup stable that it does not change configuration from reboot to reboot. Get all of your applications installed right the first time (no duplicate entries and all that, ick), and get everything setup, and then freeze the darn thing in its tracks.
My favorite setup is actually the ones that load the hard drive from a network image upon each boot, though I think that storing the image file in a hidden partition in some format that Windows cannot touch would be a far better way of achieving the same goal.
A lot of the registry's[*1} problems are do to poorly designed 3rd party software that does not completely remove itself from the registry, sometimes by design! Some programs keep a log in the registry if a piece of demo software has been installed before, others keep track of the date that they where last ran at, so as to ensure that if the user changes the date back a bit that the program will be able to detect it if it does a compare of the stored date vs the current date.
Those are all inappropriate (not to mention, *cough cough easily bypassed) uses of the registry. In my experience 3rd party software is the primary cause of registry bloat.
Though I will admit that Windows will at times make, err, random changes to the registry, heh. Weird stuff like randomly deciding that a printer should no longer be default, in situations where the administrator has privileges locked down so that no user could have possibly have changed it from being the default, but as I said, just freezing the status of the registry after the machine has reached its designed working status should do just fine for those situations.
The thing about the registry as a central storage location for data is that it makes software authors go about and implement some sort of front end for configuring their software. Even a Window's administrator would not put up with having to edit a thousand and one configuration files all full of little bits of data that could have very easily had a nice GUI front end wrapped around them.
The main advantage of a GUI front-end is that it consolidates what might be multiple configuration files into one grouped together location where all of the configuration variables can be easily viewed together as a group and problems amongst the configuration variables may be easily spotted just by doing a quick visual comparison.
"Well checkbox Enable Feature is checked, but ah! That feature has a dependency feature that has to be enabled, *click* Ok it should work now!"
This is versus reading through two separate configuration files line by line trying to find out why Feature A is not working even though it was set to enabled in Configuration File A.
Depends on how well documented it has been, and how lazy the programer has been. Kinda the same as the registry really, heh. The programer is the one who decides how clean and neat any given system of storing configuration data is, I am just saying that I believe the registry forces programers to at least spend an extra second or two thinking about how the user is going to access that configuration data.
.
.
.
Your talking to someone who's spent thousands of hours tweaking Windows registries, boot.ini files, ini files, permissions, etc. on hundreds of Windows machines, workstations, servers, all just to try make a Windows machine last one day longer before having to be reloaded from scratch,
Use any of the number of registry freezing tools to ensure that once a workstation has been setup stable that it does not change configuration from reboot to reboot. Get all of your applications installed right the first time (no duplicate entries and all that, ick), and get everything setup, and then freeze the darn thing in its tracks.
My favorite setup is actually the ones that load the hard drive from a network image upon each boot, though I think that storing the image file in a hidden partition in some format that Windows cannot touch would be a far better way of achieving the same goal.
A lot of the registry's[*1} problems are do to poorly designed 3rd party software that does not completely remove itself from the registry, sometimes by design! Some programs keep a log in the registry if a piece of demo software has been installed before, others keep track of the date that they where last ran at, so as to ensure that if the user changes the date back a bit that the program will be able to detect it if it does a compare of the stored date vs the current date.
Those are all inappropriate (not to mention, *cough cough easily bypassed) uses of the registry. In my experience 3rd party software is the primary cause of registry bloat.
Though I will admit that Windows will at times make, err, random changes to the registry, heh. Weird stuff like randomly deciding that a printer should no longer be default, in situations where the administrator has privileges locked down so that no user could have possibly have changed it from being the default, but as I said, just freezing the status of the registry after the machine has reached its designed working status should do just fine for those situations.
The thing about the registry as a central storage location for data is that it makes software authors go about and implement some sort of front end for configuring their software. Even a Window's administrator would not put up with having to edit a thousand and one configuration files all full of little bits of data that could have very easily had a nice GUI front end wrapped around them.
The main advantage of a GUI front-end is that it consolidates what might be multiple configuration files into one grouped together location where all of the configuration variables can be easily viewed together as a group and problems amongst the configuration variables may be easily spotted just by doing a quick visual comparison.
"Well checkbox Enable Feature is checked, but ah! That feature has a dependency feature that has to be enabled, *click* Ok it should work now!"
This is versus reading through two separate configuration files line by line trying to find out why Feature A is not working even though it was set to enabled in Configuration File A.
Depends on how well documented it has been, and how lazy the programer has been. Kinda the same as the registry really, heh. The programer is the one who decides how clean and neat any given system of storing configuration data is, I am just saying that I believe the registry forces programers to at least spend an extra second or two thinking about how the user is going to access that configuration data.
.
.
.
Your talking to someone who's spent thousands of hours tweaking Windows registries, boot.ini files, ini files, permissions, etc. on hundreds of Windows machines, workstations, servers, all just to try make a Windows machine last one day longer before having to be reloaded from scratch,
Use any of the number of registry freezing tools to ensure that once a workstation has been setup stable that it does not change configuration from reboot to reboot. Get all of your applications installed right the first time (no duplicate entries and all that, ick), and get everything setup, and then freeze the darn thing in its tracks.
My favorite setup is actually the ones that load the hard drive from a network image upon each boot, though I think that storing the image file in a hidden partition in some format that Windows cannot touch would be a far better way of achieving the same goal.
A lot of the registry's[*1} problems are do to poorly designed 3rd party software that does not completely remove itself from the registry, sometimes by design! Some programs keep a log in the registry if a piece of demo software has been installed before, others keep track of the date that they where last ran at, so as to ensure that if the user changes the date back a bit that the program will be able to detect it if it does a compare of the stored date vs the current date.
Those are all inappropriate (not to mention, *cough cough easily bypassed) uses of the registry. In my experience 3rd party software is the primary cause of registry bloat.
Though I will admit that Windows will at times make, err, random changes to the registry, heh. Weird stuff like randomly deciding that a printer should no longer be default, in situations where the administrator has privileges locked down so that no user could have possibly have changed it from being the default, but as I said, just freezing the status of the registry after the machine has reached its designed working status should do just fine for those situations.
The thing about the registry as a central storage location for data is that it makes software authors go about and implement some sort of front end for configuring their software. Even a Window's administrator would not put up with having to edit a thousand and one configuration files all full of little bits of data that could have very easily had a nice GUI front end wrapped around them.
The main advantage of a GUI front-end is that it consolidates what might be multiple configuration files into one grouped together location where all of the configuration variables can be easily viewed together as a group and problems amongst the configuration variables may be easily spotted just by doing a quick visual comparison.
"Well checkbox Enable Feature is checked, but ah! That feature has a dependency feature that has to be enabled, *click* Ok it should work now!"
This is versus reading through two separate configuration files line by line trying to find out why Feature A is not working even though it was set to enabled in Configuration File A.
Depends on how well documented it has been, and how lazy the programer has been. Kinda the same as the registry really, heh. The programer is the one who decides how clean and neat any given system of storing configuration data is, I am just saying that I believe the registry forces programers to at least spend an extra second or two thinking about how the user is going to access that configuration data.
.
.
.
Your talking to someone who's spent thousands of hours tweaking Windows registries, boot.ini files, ini files, permissions, etc. on hundreds of Windows machines, workstations, servers, all just to try make a Windows machine last one day longer before having to be reloaded from scratch,
Use any of the number of registry freezing tools to ensure that once a workstation has been setup stable that it does not change configuration from reboot to reboot. Get all of your applications installed right the first time (no duplicate entries and all that, ick), and get everything setup, and then freeze the darn thing in its tracks.
My favorite setup is actually the ones that load the hard drive from a network image upon each boot, though I think that storing the image file in a hidden partition in some format that Windows cannot touch would be a far better way of achieving the same goal.
A lot of the registry's[*1} problems are do to poorly designed 3rd party software that does not completely remove itself from the registry, sometimes by design! Some programs keep a log in the registry if a piece of demo software has been installed before, others keep track of the date that they where last ran at, so as to ensure that if the user changes the date back a bit that the program will be able to detect it if it does a compare of the stored date vs the current date.
Those are all inappropriate (not to mention, *cough cough easily bypassed) uses of the registry. In my experience 3rd party software is the primary cause of registry bloat.
Though I will admit that Windows will at times make, err, random changes to the registry, heh. Weird stuff like randomly deciding that a printer should no longer be default, in situations where the administrator has privileges locked down so that no user could have possibly have changed it from being the default, but as I said, just freezing the status of the registry after the machine has reached its designed working status should do just fine for those situations.
The thing about the registry as a central storage location for data is that it makes software authors go about and implement some sort of front end for configuring their software. Even a Window's administrator would not put up with having to edit a thousand and one configuration files all full of little bits of data that could have very easily had a nice GUI front end wrapped around them.
The main advantage of a GUI front-end is that it consolidates what might be multiple configuration files into one grouped together location where all of the configuration variables can be easily viewed together as a group and problems amongst the configuration variables may be easily spotted just by doing a quick visual comparison.
"Well checkbox Enable Feature is checked, but ah! That feature has a dependency feature that has to be enabled, *click* Ok it should work now!"
This is versus reading through two separate configuration files line by line trying to find out why Feature A is not working even though it was set to enabled in Configuration File A.
Depends on how well documented it has been, and how lazy the programer has been. Kinda the same as the registry really, heh. The programer is the one who decides how clean and neat any given system of storing configuration data is, I am just saying that I believe the registry forces programers to at least spend an extra second or two thinking about how the user is going to access that configuration data.
Of course some data just should not be stored in the registry, but that is a whole separate problem. ^_^ I do like INI files, heh. But I like them stored in my individual program directories, *shrugs* I remember the move towards shoving all configuration files in the C:\windows directory (and at times some other directories, yeesh, they keep on jumping around, lol), but I think that placing them in the individual programs directory is far more intuitive. But that was back when 8.3 files where still common place, so having even a few dozen ini files in the same directory made sorting out which file belonged to which program a bit difficult at times.
Personal help is a double edged sword... (Score:2)
Well, being that you're famous (especially amongst geeks), you'll find lots of help available most of us didn't get when we all started: I'm sure you know the phrase 'rtfm.'
This silly infantile utterance is a rite of passage into the geek world for most of us: gaining self reliance. While it is really cool that you are getting this personal help, "hand holding" may hinder your learning curve. RTFM'ing really does help you gain self-reliance and independence, which should be a new-ish users ultimate goal.
That said, there are so many realms of 'n00bishness,' and there are certainly plenty of more 'l337' users than me (even saying that is a leap; but excessive humility is often hubris in disguise).
I wish you luck; stick with it, be prepared to get down'n'dirty with man pages, READMEs, and, of course, google.
WineX (Score:2)
I have it. I love it. It plays Civ3 for me pretty much perfectly, at least once I turned the sound off. However, you should be aware that if a game isn't rated at 4 or 5, it isn't likely to work very well. Furthermore, even some games rated at 4 or higher won't work for you.
WineX is never going to be as good as a direct port (such as what Lokigames used to do...) but for some specific games, it's really useful.