TR Forums

Kiruwa wrote:

The _only_ reason to recommend even nano to a user is if X11 doesn't kick on properly at boot, and you need to fiddle with the xorg.conf.

No. You would want it if you're SSHing in.

All this talk about vi reminds me of an old post that I found quite humorous.

Most Linux Lunatics Like it in the dark. See they think its much better to telnet in on a 200 baud modem have 25 80 character lines available for your total information dispersal/viewing pleasure. That works great if you get paid by the hour, and don't care if you ever get anything done. For some reason the mythical "server" will not work if it has to put up too much information at once, or allow users to easily modify and fix things, and "servers" work different than the whole rest of the universe. where its normally better to have lots of information available to you when you are working on something, when working on a "server" its much better to work one line at a time, and don't even thing about being able to copy/paste or recall what you just did.... any self respecting "server" god wouldn't even consider doing anything other than representing with his mad 400 word per minute VI skillz. Where the whole rest of the computing universe is loving some multiple desktop/multiple terminal window multitasking nirvana, "servers" should never progress. Reading a 25,000 page MAN guide is great on a 25 line screen. I recommend it as a good waste of 8hrs anyday. Hell it wouldn't make a bit of sense to be able to have the man page in one window and your terminal in another window typing while you are reading. And just thing how freaking completely idiotic it would be to have multiple windows up with google searches, and your own repository of old cli commands where you could just copy and paste right in without mistyping anything..... Damn that man.... GUI's suck I mean why would any self respecting "server" god not want to type every command over and over. And then there is the overhead issue, these modern server processors just don't have the spare cycles to be throwing down the drain running a GUI... I mean my god it would probably take 10% of one core of a 16 core server to run just the GUI... OH hell no!!! It makes more sense to just go commando CLI on one TTY than to risk that additional .625% load crashing the almighty "server".

Kiruwa wrote:

I cannot honestly believe that someone would recommend vi to someone just starting out in linux. It's complex, arcane, and totally unnecessary for anything anyone (new) is likely to do in a modern linux distro.

You can get by in vi with only a few commands...not everyone needs to know the complex commands to make it useful for when they can't get their freakin' GPU drivers working properly.

TheWacoKid wrote:

Kiruwa wrote:

I cannot honestly believe that someone would recommend vi to someone just starting out in linux. It's complex, arcane, and totally unnecessary for anything anyone (new) is likely to do in a modern linux distro.

You can get by in vi with only a few commands...not everyone needs to know the complex commands to make it useful for when they can't get their freakin' GPU drivers working properly.

Anyone who is going to use Linux or any Unix OS should know how to do basic editing, open, edit, save, exit, in both vi and text mode Emacs. You don't have to use them for normal day to day work, but you need to be familiar enough with them to be able to change something and get out.

As far as the "arcane nature" of vi goes, how many of you use shortcut key bindings in your favorite word processor or text editor? If you do, then you are doing exactly the same thing the most used keystrokes in vi do, just with different bindings. The difference is that vi doesn't support the slower pointy clicky way of doing things too.

--SS

Anarchist wrote:

skialex25 wrote:

... what should I be aware of...?

stay away from samba. It kills brain cells.

Unfortunately Samba is a necessity if you want to have folder shares that work seamlessly between Windows and Linux. At least for basic stuff, getting it set up isn't bad -- there are some pretty reasonable GUI-based tools for configuring Samba users and simple folder shares.

If you want some *real* fun, try getting Samba to integrate with an Active Directory domain. We've got that setup at work (Linux based Samba server using the AD controller to authenticate users, since our IT infrastructure is still MS-centric). After a fair bit of pain, it finally works... most of the time. But occasionally, users just fail to authenticate; and the only diagnostic we get when this happens is "I/O error".

Ryu Connor wrote:

FWIW as part of a basic introduction to *nix the Army presents a five day course and one of those days includes lessons on vi.

General James Cartwright (vice-chairman of the Joint Chiefs of Staff) wrote:

Quite frankly, my feeling is -- at least being a never-satisfied person -- the department is pretty much in the Stone Age as far as IT is concerned.

Coincidence?

(linkage)

BobbinThreadbare wrote:

flip-mode wrote:

But it will continue to be a problematic platform for as long as many major mainstream applications continue to ignore it. Adobe. Autodesk. Turbo Tax. And so on. The open source community cannot replace those. It's too high of a wall to climb. It'd take millions of programmer-days to do it. There aren't enough open source programmers to go around, and most of the best programmers are already working for Adobe, Autodesk, Microsoft, Apple, Google, and so on.

This is only a problem if you need those apps though. I can't imagine a high percentage of people use Autocad on their personal computers.

...but if you add up *all* the people who use *something* that doesn't have a Linux port or equivalent Linux app, that's a pretty substantial percentage of computer users. What percentage of people use TurboTax? It's a lot!

Even where equivalents exist, inter-operability issues may make switching to Linux "cold turkey" problematic. Office apps are a case in point. For many people, OpenOffice/LibreOffice (plus an e-mail client of your choice) are a great replacement for MS Office from a functionality standpoint. But if you are in a MS-centric work environment, you may have problems. If your e-mail server is Exchange-based, you're pretty much hosed (yes Evolution supports Exchange integration, but it is buggy as all get-out); and if you routinely collaborate on editing of complex documents with co-workers (something that happens a *lot* in some work environments), repeatedly importing/exporting MS Office documents to/from LibreOffice is *guaranteed* to mess up the formatting. Document compatibility is one of these chicken-and-egg situations where everything would be fine if you could get the people you work with to switch, but until *everyone* switches it just isn't practical.

I run Linux on my work desktop because I prefer it to Windows, and I'd need to run VMs either way since there are things I need Linux for as well (one of our products is Linux based). To address the inter-operability issues noted above, I also leave a Windows VM running all the time (on one of the GNOME virtual desktops, so I can access it instantly via a hotkey). Pretty much the whole purpose of the Windows VM is to host MS Office. (And yes, I also tried ditching the VM and running MS Office under Wine; it more or less worked, but was flaky enough that I went back to the VM approach after a few days.)

bthylafh wrote:

Kiruwa wrote:

The _only_ reason to recommend even nano to a user is if X11 doesn't kick on properly at boot, and you need to fiddle with the xorg.conf.

No. You would want it if you're SSHing in.

True. But if you're doing that (and trying to edit files over said SSH connection), IMO you've already graduated to at least "intermediate" level Linux geekiness, and should probably learn at least the rudiments of vi anyway!

OTOH, unless you're on a dial-up modem (or horribly congested public WiFi), you could also use SSH's X forwarding option to run remote copies of gedit or something... (For those who are unfamiliar, X forwarding is a feature of SSH which allows you to run an arbitrary GUI-based app on the remote machine, and have its window appear on your local desktop. This is completely different from typical "remote desktop" solutions in that you're forwarding just a single app, not the entire desktop. The remote system doesn't even need to have a desktop environment running!)

just brew it! wrote:

If you want some *real* fun, try getting Samba to integrate with an Active Directory domain. We've got that setup at work (Linux based Samba server using the AD controller to authenticate users, since our IT infrastructure is still MS-centric). After a fair bit of pain, it finally works... most of the time. But occasionally, users just fail to authenticate; and the only diagnostic we get when this happens is "I/O error".

:snarl: After I upgraded my fileserver to Debian 6, Samba will periodically lose the mapping between AD groups and their numeric IDs. I had to cron a fix script to reapply group permissions and ACLs to the /srv/samba hierarchy daily, and even then it'll still crap out sometimes. The ACL now has 20 entries of numeric IDs, getting incremented by a random number (30-some) each time.

I have not seen anybody else having this problem so it must be a weird corner case with the upgrade, but oy is it maddening. Just as well that It's Been Decided that the new fileserver's going to run Server '08 R2.

bthylafh wrote:

just brew it! wrote:

If you want some *real* fun, try getting Samba to integrate with an Active Directory domain. We've got that setup at work (Linux based Samba server using the AD controller to authenticate users, since our IT infrastructure is still MS-centric). After a fair bit of pain, it finally works... most of the time. But occasionally, users just fail to authenticate; and the only diagnostic we get when this happens is "I/O error".

:snarl: After I upgraded my fileserver to Debian 6, Samba will periodically lose the mapping between AD groups and their numeric IDs. I had to cron a fix script to reapply group permissions and ACLs to the /srv/samba hierarchy daily, and even then it'll still crap out sometimes. The ACL now has 20 entries of numeric IDs, getting incremented by a random number (30-some) each time.

I have not seen anybody else having this problem so it must be a weird corner case with the upgrade, but oy is it maddening. Just as well that It's Been Decided that the new fileserver's going to run Server '08 R2.

Some distros have better AD support then others. OpenSUSE has great AD support, and so does Openfiler. We've been running Openfiler for a few years now, and only had a few problems. Both problems were related to our Server 2008 R2 upgrade. We needed to updated Samba so the non-domain member PCs, Macs and Linux test boxes, could authenticate, and we set Samba server to use the DCs as NTP servers to keep them in time and authenticating.

Flatland_Spider wrote:

bthylafh wrote:

:snarl: After I upgraded my fileserver to Debian 6, Samba will periodically lose the mapping between AD groups and their numeric IDs. I had to cron a fix script to reapply group permissions and ACLs to the /srv/samba hierarchy daily, and even then it'll still crap out sometimes. The ACL now has 20 entries of numeric IDs, getting incremented by a random number (30-some) each time.

I have not seen anybody else having this problem so it must be a weird corner case with the upgrade, but oy is it maddening. Just as well that It's Been Decided that the new fileserver's going to run Server '08 R2.

Some distros have better AD support then others. OpenSUSE has great AD support, and so does Openfiler. We've been running Openfiler for a few years now, and only had a few problems. Both problems were related to our Server 2008 R2 upgrade. We needed to updated Samba so the non-domain member PCs, Macs and Linux test boxes, could authenticate, and we set Samba server to use the DCs as NTP servers to keep them in time and authenticating.

Ooohh... maybe I'd better bookmark this thread now!

(We're likely moving to a mixed Server 2008 / Debian 6 environment within the next year...)

Interesting point on the time sync issue as well; I know I've read somewhere that Kerberos-based authentication services can have problems if clocks aren't in sync. AFAIK all the Linux desktops use the Linux server as their NTP source; I'll bet the Windows desktops are either syncing to the AD server, the default Windows time server, or nothing at all. IIRC the Linux server syncs to the public NTP pool; I have no idea what the AD server is syncing to (and may not have the ability to change it, as I've only got full admin rights over the Linux half of the infrastructure). I'll definitely look into this when I get back into the office (I'm off for a couple of weeks now).

just brew it! wrote:

Interesting point on the time sync issue as well; I know I've read somewhere that Kerberos-based authentication services can have problems if clocks aren't in sync.

They get hella fussy when not in sync, and AD is no exception.

AFAIK all the Linux desktops use the Linux server as their NTP source; I'll bet the Windows desktops are either syncing to the AD server, the default Windows time server, or nothing at all. IIRC the Linux server syncs to the public NTP pool; I have no idea what the AD server is syncing to (and may not have the ability to change it, as I've only got full admin rights over the Linux half of the infrastructure). I'll definitely look into this when I get back into the office (I'm off for a couple of weeks now).

The Windows clients use the PDC emulator as their time source, and the Win DCs should sync to an outside server, time.windows.com is the default, I think. You can setup the Win DCs to use whatever NTP source you want, but you have to adjust the domain controller group policy, which requires at least Domain Admin rights.

Too keep this short, I tried to add redundancy to our time keeping by adding several different NTP servers. That caused one of the two sides to get out of time randomly, but I'm not sure which side. The solution, for me, was to set the Win DCs to use one NTP server and the Linux servers to use the DCs. This previously wasn't a problem with 2003, so I kind of think it was 2008 R2.

As long as you use the same NTP server for all of your DC's you should be good. I ran into this issue once with our mixed clients. We ended up using Likewise with the few Lin servers we had. It made joining a snap and the servers read off the time from the DC's just like Win Clients do.