Linux General Questions

muraii wrote:

What's your method for ensuring transitioning to newer OS versions is smooth, in the case that you can't upgrade directly?

Run Arch Linux, and never have to transition to a newer version again

Full disclosure: you do occasionally have pains with a rolling release too, but you address them individually as they trickle in rather than having to do the equivalent of a dist-upgrade.

I've considered it but I'm so used to Slackware's conventions that I'm not enthused about learning another set. It would be useful, but as I mentioned, it's been a month or two that I've had this machine largely stabilized and yet I still haven't started tuning Slackware. Also, if I wanted a rolling release, I'd just go Slackware-current. +)

muraii wrote:

What's your method for ensuring transitioning to newer OS versions is smooth, in the case that you can't upgrade directly?

If you don't have your /home directory on a separate partition, I'd recommend doing that -- that way, even if you blow away your OS install and reinstall, you retain all your own files. That doesn't cover everything, of course (ie: stuff under /etc) but it does handle the bulk of things.

Looking at news on the 14.04 release, I notice that the btrfs filesystem and user tools are now included by default.

I've been wanting to switch to btrfs for some time now on my media volumes as they are too big to backup and I'd like the additional protection against data corruption that btrfs offers. Really excited about this release now.

muraii wrote:

What's your method for ensuring transitioning to newer OS versions is smooth, in the case that you can't upgrade directly?

I bounce everything (documents, photos, videos, steam folder, WoW folder) to my Popoplug rig, then nuke the old install from orbit.

/me scribbles all the notes.

pneuman wrote:
muraii wrote:

What's your method for ensuring transitioning to newer OS versions is smooth, in the case that you can't upgrade directly?

If you don't have your /home directory on a separate partition, I'd recommend doing that -- that way, even if you blow away your OS install and reinstall, you retain all your own files. That doesn't cover everything, of course (ie: stuff under /etc) but it does handle the bulk of things.

Also, if you can't do the same for /opt and /usr/local, make a spot in the /home partition for them and use symbolic links so that anything installed there is also retained.

Kurrelgyre wrote:
pneuman wrote:
muraii wrote:

What's your method for ensuring transitioning to newer OS versions is smooth, in the case that you can't upgrade directly?

If you don't have your /home directory on a separate partition, I'd recommend doing that -- that way, even if you blow away your OS install and reinstall, you retain all your own files. That doesn't cover everything, of course (ie: stuff under /etc) but it does handle the bulk of things.

Also, if you can't do the same for /opt and /usr/local, make a spot in the /home partition for them and use symbolic links so that anything installed there is also retained.

Dang, these are good ideas, I'll need to give it a try next time

I used to be this granular about partitions but then didn't do anything to take advantage of it. Not sure what I store in /usr/local or /opt that I'd need to back up.

And if you do decide you want or need multiple partitions, make them LVM logical volumes instead. Under-commit your disk at first, then you can hot-resize filesystems as you discover your space requirements over time. Much nicer than making static, upfront decisions about how many gigs /var is going to need in 6 months.

Jarpy wrote:

And if you do decide you want or need multiple partitions, make them LVM logical volumes instead. Under-commit your disk at first, then you can hot-resize filesystems as you discover your space requirements over time. Much nicer than making static, upfront decisions about how many gigs /var is going to need in 6 months.

Until a distribution update goes wrong and LVM no longer functions. Use caution.

I don't think they've bollixed up LVM like that for many years. It's a pretty standard part of the system now, very broadly used, so any screwups there are likely to be noticed in early testing, well before general availability.

I still tend to like to allocate all my space ahead of time, for a cleaner layout and better consistency. I don't usually even use LVM... usually only when I'm doing disk encryption. What I normally do is allocate the great majority of storage into /home, and then if I need more space somewhere else, I'll do symlinks.

The biggest reason to use /usr/local/bin for local system binaries was for when you were A) sharing a system with multiple people, so you could share local binaries, and B) when you were running your root filesystem from NFS, using a collective system image across multiple machines, and then had local system changes mounted on a local drive.

With the use patterns that most people have these days, making a bin directory in your homedir, and then adding it to your path in the rc file for your chosen shell, is typically just as good. You can normally avoid /usr/local altogether, unless you have binaries that need to be usable by other user accounts ... which might be system accounts, like Apache or Postgres or something like that. If it's just for your own use, a personal bin folder is very easy, and works beautifully.

Malor wrote:

If it's just for your own use, a personal bin folder is very easy, and works beautifully.

...and it makes a lovely Git repo

Jarpy wrote:
Malor wrote:

If it's just for your own use, a personal bin folder is very easy, and works beautifully.

...and it makes a lovely Git repo :)

Seems like it would get rather large quickly, installing all of your apps in a repo.

Well my ~/bin is mostly scripts that I got sick of rewriting.

Having said that, disk is cheap.

Jarpy wrote:

Well my ~/bin is mostly scripts that I got sick of rewriting.

Having said that, disk is cheap.

That's true. And I guess people can host their own Git repo's. I'm used to using Github or Bitbucket. But then again, I don't think there is a size limit on either of those so.... point is kind of moot.

Yeah, Git is cool in that there is no need for an authortiative repo. At work, I have two personal systems, so each has ~/bin as a Git repo, with the other system set as a remote. I guess I'm not achieving much that I wouldn't get with Rsync or Unison, but it works for me

Look into supported hardware platforms for OpenElec and the Flirc. There are trade-offs to be considered over using Plex, which puts most of the fiddly bits on the end that can bear it. Also.

Aha! Now why didn't that thread show up in my searchings on here?

That's probably a much better place for my questions! I'll repost it there, with apologies.

*snip*

I've moved this to a more appropriate thread.

I asked this in IRC but would like to head off as much DDGing and reading through StackedOverflow and LinuxQuestions as I can. I have an AMD Radeon HD 6450. I'm currently pushing three displays with it in Win7. I want to do this on a dual-boot machine, with Linux as the primary OS and Win7 just as a safeguard. That is, I want to run three displays in Linux with this GPU. I've done a little hunting thus far and seems AMD's fglrx will support this with their driver GUI. I will also need to make sure Xorg knows about the displays.

My question here is: which of you have 2-3 displays running in Linux, what is your distro, and what are your experiences? I won't be gaming or such, and could probably drop down to 2 if it's inordinately more difficult to get three running for some reason. I want to run Slackware but may choose Linux Mint for ease of setup, i.e., if three displays Just Works on Mint.

muraii wrote:

I asked this in IRC but would like to head off as much DDGing and reading through StackedOverflow and LinuxQuestions as I can. I have an AMD Radeon HD 6450. I'm currently pushing three displays with it in Win7. I want to do this on a dual-boot machine, with Linux as the primary OS and Win7 just as a safeguard. That is, I want to run three displays in Linux with this GPU. I've done a little hunting thus far and seems AMD's fglrx will support this with their driver GUI. I will also need to make sure Xorg knows about the displays.

My question here is: which of you have 2-3 displays running in Linux, what is your distro, and what are your experiences? I won't be gaming or such, and could probably drop down to 2 if it's inordinately more difficult to get three running for some reason. I want to run Slackware but may choose Linux Mint for ease of setup, i.e., if three displays Just Works on Mint.

I don't know about AMD cards... haven't had one in years. I just recently upgraded though, as I had an older GTX 580 + a GTX 260 for 3+ monitors, but that was pretty difficult in Linux as I needed to have multiple X screens, which is not exactly true multi-monitor support. This setup ran without issue in Windows though.

I upgraded to a GTX 770 which can do 4 monitors out, and in Linux it can all be on one X screen.

You can definitely try different distro's though. With the first setup, I had to completely ditch Mint + Cinnamon, as Cinnamon just flat out wouldn't run with it. Mate was better, but I think Xubuntu had the best support for it. Best being it was two X screens, but it was functional.

I just installed Ubuntu 14.04 and it seems to be relatively nice. I haven't used Unity in quite a while.

Yeah I didn't want to maintain three separate X configs and servers. This would mean an inability to spread something across multiple monitors, right?

I run Arch with a crummy Radeon HD and the proprietary Radeon drivers. I use two monitors.

There's no trouble with this setup. I used the amd setup tool (something like "amdcccle") to generate an xorg conf.

I've read that there's some kind of intentional crippling of some GPUs to not support more than two monitors. I can't speak to that.

muraii wrote:

Yeah I didn't want to maintain three separate X configs and servers. This would mean an inability to spread something across multiple monitors, right?

No, I wouldn't suggest it. Did you use the binary AMD drivers?

I'm currently running s Windows box. I'll be moving to Linux soon. Glad to hear it's going to be relatively smooth.

Counterpoint: trying to run something that requires root access in cygwin is a joke. You can use "cygstart --action = runas " but it wouldn't ever take the drive letter nor cygwin path.

I can't wait to get onto a Linux system for work.

muraii wrote:

I can't wait to get onto a Linux system for work.

Best decision I've made for work.

I'm in a position in which I could easily make a case for a Mac. My CIO suggested it just today. And everyone else in my ops crew is using Apple machines. I'd take it as a compromise but want to have all my Openbox keymaps and easy and reliable bash scripting and sane application management I have in my personal Slackware environment.

Next week!

Honestly, OS X has enough polish that you may prefer it to Linux. Things like multimonitor just work, it comes with bash built in, and application management mostly consists of dragging icons to the Applications folder.

The command-line utilities that Apple uses can be a little outdated, but the brew system has a nice clean setup, and will let you stay on top of the most current releases of an awful lot of free software. It's all command-line, but it's very comfortable and easy to use. It probably scares off a lot of Mac users, but if you're a Unix geek, it's a fantastic utility.

Malor wrote:

Honestly, OS X has enough polish that you may prefer it to Linux. Things like multimonitor just work, it comes with bash built in, and application management mostly consists of dragging icons to the Applications folder.

The command-line utilities that Apple uses can be a little outdated, but the brew system has a nice clean setup, and will let you stay on top of the most current releases of an awful lot of free software. It's all command-line, but it's very comfortable and easy to use. It probably scares off a lot of Mac users, but if you're a Unix geek, it's a fantastic utility.

It's funny, I got used to Linux before using a Mac at work. Honestly, it is polished, but there is enough that is different or off that turned me off. I guess I've just gotten used to Linux and like it that way.

Only thing I miss is a few of the apps, like Sequel Pro.