Some Athlon, some Duron. That was the question. I compiled some kernels a few years ago and was daunted by the number of choices I had to go through. And some choices left me wondering if I was choosing correctly, such as, if I was selecting 386, did that really mean a 386 pre-486, or did that mean a x86?
There's usually no need to even worry about these things; Debian should just use the most compatible version on any machine installed as an x86 (386, 486, pentium 1,mmx,2,3,4, k6, k6-2, athlon, duron, athlonxp, athlon64, emt64). If you wanted to roll your own, I think the documentation during a make config is pretty clear:
This is the processor type of your CPU. This information is used for optimizing purposes. In order to compile a kernel that can run on all x86 CPU types (albeit not optimally fast), you can specify "386" here.
Put a little window at the top of the gui that shows the underlying file settings/changes. That's the fastest way to learn something. Reading books on the subject or text file comments by themselves just isn't enough for some applications. Learning by doing is better.
In a production environment, where it matters if something breaks or secrets are disclosed? Granted, config tools are a good way to get your feet wet with a new service you haven't used before, but system operators are doing their users a huge disservice if they take the easy way out and don't read some decent documentation on whatever they're administering. This is especially the case when sensitive information is at stake, which is usually the case with LDAP and almost always the case with NFS. I've seen the shotgun approach to system administration: try as many different things as you can until it works. Things always break later.
This is why for the community or others to suggest that "Linux is ready for the desktop", I have an issue with this. I was saying this myself, as I have been using it on the desktop for a number of years now. But I like to tinker with my systems. Someone who doesn't, is this really accurate? Can you really expect someone switching from Windows to select and install a different kernel because the default kernel breaks your cdburner?
I would be surprised if a distribution geared towards novices like Lindows, Fedora Core or Ubuntu had these things broken out of the box. Debian appears to have a different set of goals, but I haven't had any hardware recognition problems with it.
Thanks to Yast, it was possible for me to set up NFS, NIS, and other services and get them working in a safe manner.
I find this humorous; there is no way to make NFS3 or NIS secure. The GUIs won't tell you that.
An administrator's dream! Tons of new features, with each one more likely to break something than the last!
Some of us simply don't require the constant barrage of new features a distribution like Ubuntu or Debian Unstable offers. Although any Linux distribution can be adapted to fit almost any market, not all of us require the latest wireless adapters or version of openoffice to fulfill our needs.
Other problems? Sarge installed a generic 386 kernel I think, instead of one for my AMD cpu. Now I have to figure out how to upgrade a kernel even though I planned to stick with the stable one Sarge gave me, 2.6.8-2-386.
Just run apt-get install kernel-image-2.6-k7 kernel-image-2.6-k7, assuming by "AMD processor," you mean AMD Athlon. I've found this site to be more helpful than the apt utilties at times when I'm looking for a specific package.
Wishes? Yast on Debian. So I can more easily configure OpenLDAP. Tried without Yast, didn't work.
I guess if you've got large enough of a site for LDAP, you should probably have a standard ldap.conf, which I believe resides in/etc/ldap/ldap.conf on Debian. Just copy it from a working machine. That should be enough to at least get the openldap tools working. This sort of illustrates why I don't like YaST or other GUI administrative tools: they hide too much from me, and I don't really know what's going on under the hood. If I know how the package works, I don't need to worry about the packaging.
We're still dealing with this sort of short-sightedness. Instead of just turning the damn things off, or restricting access, we have firewalls.
I know this is slashdot, but have you compared the free competion? Like the standard Unix network file system, NFS? It strictly depends on a secure network in order to be secure. All you have to do is claim that you're UID (insert number here) and you have full access to someone's files! Even with a firewall, port security and root squashing, it's essentially a three-step process to owning most UNIX networks deploying NFS3 if you have physical access:
Get the IP and MAC of the host you want to emulate.
Set the IP and MAC of your notebook to this host. Connect the cable to your notebook.
Mount nfs shares, and change your UID.
Granted, things like NFS4 and AFS can require authentication for access, but the number of sites using these file systems seems rather small, and NFS4 is a rather recent development. Windows got their shit together first and the free OS's are just catching up now.
Seems to me you just set a lower bound and cut out 13^128 possibilities for a cracker:-p
More like 128^13 (off by a factor of 115 orders of magnitude).
What an attacker can glean from this bit of information is that users (his kids) probably won't use a random password. So, a modified dictionary attack may be effective. Regardless, there aren't any Windows services requiring a password that he should be offering to the Internet anyway, so the point is essentially moot.
If you have 200+ desktops you must have means of propagating unified network filesystem view to them otherwise your support will go mad.
If you have 200+ desktops, you must have means of modifying any configuration file across your network. You don't need LDAP, automounter or whatever is in vogue to modify a flat file like fstab if you want to change something like nfs shares. You just need ssh keys and moderate scripting abilities, which you should already have if you're managing a network that large.
Slashdot Mirror
But ALSA does support mixing, even on cards that don't support it in hardware.
Some of us simply don't require the constant barrage of new features a distribution like Ubuntu or Debian Unstable offers. Although any Linux distribution can be adapted to fit almost any market, not all of us require the latest wireless adapters or version of openoffice to fulfill our needs.
- Get the IP and MAC of the host you want to emulate.
- Set the IP and MAC of your notebook to this host. Connect the cable to your notebook.
- Mount nfs shares, and change your UID.
Granted, things like NFS4 and AFS can require authentication for access, but the number of sites using these file systems seems rather small, and NFS4 is a rather recent development. Windows got their shit together first and the free OS's are just catching up now.