Linux General Questions

I checked around, couldn't find it for the life of me.

On a similar but unrelated then related note, I installed Linux Mint, and I really like it. I installed Mate, and it worked fine, but then I installed Cinnamon, and I'm surprised how much I like it. I have actually gotten used to the Unity dash, but with a few tweaks, Cinnamon really works well. And all the extra effects are super smooth.

Also unrelated, but the Cairo dock, if you're into that, works amazingly well also. I tried it a few years ago and didn't like it a whole lot, but it looks and works awesomely now. I might just keep it with my taskbar up top and Cairo dock on the bottom.

Also, 10,000,000 IS working on Mint. It's probably because I didn't copy anything from my Ubuntu home directory to this one other than a few specific program folders, so that means the stupid fullscreen option is SOMEWHERE hidden, but I have no idea where. I know it's there because I copied the game install over to my 2nd hard drive where it's installed for Ubuntu, and there was no change, still a messed up fullscreen.

Edit: Another thing I like that is probably a bug/opinion of Unity. I didn't see it in every program, but Gimp had an issue I really disliked. Going to save a file, when the name of the file is clearly highlighted, if I start typing, it instead switches to search for files in a folder.
Cinnamon seems to handle this correctly, if I start typing, it changes the new file name.
Not a big deal if you're saving one image, but if you have to crop or save out 20, 50, 100 images in a day, it gets pretty tedious.

Citizen86 wrote:

Edit: Another thing I like that is probably a bug/opinion of Unity. I didn't see it in every program, but Gimp had an issue I really disliked. Going to save a file, when the name of the file is clearly highlighted, if I start typing, it instead switches to search for files in a folder.
Cinnamon seems to handle this correctly, if I start typing, it changes the new file name.
Not a big deal if you're saving one image, but if you have to crop or save out 20, 50, 100 images in a day, it gets pretty tedious.

This is a very long-standing bug with GTK that Unity seems to have unfortunately inherited.

That's strange that some DE's have fixed it though

So, I got Ubuntu 12.10 on my laptop.

But, I do seem to have trouble with my /boot partition.

It says it's too small. It's currently at 255 megs, but wanted it at least 1gig.

Or, can I delete files in the /boot ?

Manach wrote:

So, I got Ubuntu 12.10 on my laptop.

But, I do seem to have trouble with my /boot partition.

It says it's too small. It's currently at 255 megs, but wanted it at least 1gig.

Or, can I delete files in the /boot ?

I don't remember how Ubuntu does this, but you shouldn't need a very large /boot - just enough for the grub config, the initramfs, and the kernel you want to use. If it's filling up, you may have old kernels installed that you can get rid of. In Ubuntu, they *may* belong to a kernel package that you can remove rather than deleting directly (again, I'm not sure how Ubuntu handles this).

A gig for /boot? That doesn't sound right at all. Even the new GPT partitioning expects only a hundred megs at the start of the drive for the boot files. Are you certain that you're correctly specifying the / partition somewhere else, as well as /var, /tmp, and /home, if you have those in separate filesystems? (totally not necessary to do this, but many people do.)

When and where is it saying "too small"?

gore wrote:
Manach wrote:

So, I got Ubuntu 12.10 on my laptop.

But, I do seem to have trouble with my /boot partition.

It says it's too small. It's currently at 255 megs, but wanted it at least 1gig.

Or, can I delete files in the /boot ?

If it's filling up, you may have old kernels installed that you can get rid of. In Ubuntu, they *may* belong to a kernel package that you can remove rather than deleting directly (again, I'm not sure how Ubuntu handles this).

Try: sudo apt-get autoremove

So you guys still partition out separately for /boot, /var, /home, etc? Maybe it's because I joined Linux late, or because I dual or triple-boot, but I usually have one partition per Linux install and assign it /

Citizen86 wrote:

So you guys still partition out separately for /boot, /var, /home, etc? Maybe it's because I joined Linux late, or because I dual or triple-boot, but I usually have one partition per Linux install and assign it /

How you want to break it out is mostly a matter of individual taste. On my personal systems I usually just make a /boot and a huge / and run with it. On multiuser systems you might still want to keep /var separate so stuff that needs to write there won't break if e.g. a user fills up his or her home directory.

As for /boot, I still always make it out of habit, but technically you only need it if your / partition is unsupported by your boot loader (last I checked for grub, that'd include LVM, zfs, etc). If you're just using a well supported filesystem on a normal partition scheme you don't need it but I suspect most installers still create it by default just to be safe.

Ah interesting, I didn't think about support for the boot loader. Very interesting!

It depends on what I'm planning to do with the box or VM.

On servers, I usually break /, /boot, /usr, /var, /tmp, and /home into their own filesystems, which helps me isolate services like Apache into non-essential areas. Filling the /home partition will potentially cause havoc in a user-level app, but shouldn't crash the server, or allow it to get to a state where you can't log in remotely and fix it.

The old standard was that everything essential to launch the Linux kernel was kept in a small /boot partition, formatted with the simplest available filesystem, usually ext2, and stuck at the very start of the drive, so that the BIOS could always find it.

Then, everything the kernel needed to bring the machine to a state where it was reachable for administration work was in the / partition, mostly stored in the /sbin subdirectory. (not a separate mountpoint). /boot and / were always enough to get the machine up far enough so that you could fix anything that needed fixing. /usr was for binaries, often NFS-mounted in big clusters; this was where all your network service programs lived, and then /var, /tmp, and /home were where those programs stored their data. The separate /usr mount is becoming difficult to justify anymore, as many distros have decreed that the contents are required even to boot up. Separate /var, /tmp, and /home still make a fair bit of sense.

For machines that will be desktops, I usually dedicate 100 megs to /boot, some swap space, 10 to 50 gigs for /, and the balance of the disk for /home. This makes it very easy to upgrade the machine later; you wipe out the / and /boot partitions, leaving /home untouched, which will preserve all user data. But note that if you go on the small side for /, you may need to prune out update directories, as Ubuntu in particular tends to load up /var/cache/apt/archives with a hurricane of patches, over the lifespan of the box. An aptitude clean command will clear out that directory for you.

Thanks malor, your posts are always pretty in-depth and very helpful

Also, thought I'd mention, I emailed the 10,000,000 guy, he finally replied, said he would look into it, then he replied again and gave me the directory of the config file. ~/.config/unity3d/EightyEightGames/10000000/prefs, not sure why I couldn't find it. I thought I searched for 10000000, but there is another folder as well. I assume I skipped the unity3d folder since the game is 2D....

The other consideration when partitioning is how much you "lose" due to required free overhead for having multiple partitions. If you anticipate storage being tight (e.g. on an SSD), you might want to keep the number of partitions lower so you don't waste as much "free" space.

Course, we have LVM thin provisioning these days, so the overhead of additional volumes doesn't necessarily need to be as high.

If /boot is filling up, look for old kernel packages like this:

dpkg -l linux-image-*

Do this in a very wide terminal window, to make sure the full contents of the "Name" column, which contains the package name for the kernel, is revealed. Any version other than the one you're currently running (you can check that by running "uname -r) is probably fair game for removal, though if it turns out you're not running the most recent installed version, I'd reboot in to that first and then remove all the older ones.

You can remove them with apt-get like -- you can specify a bunch of kernel package names in the one command to remove them all at once, eg:

sudo apt-get --purge remove linux-image-3.5.0-22-generic linux-image-3.5.0-23-generic linux-image-3.5.0-24-generic

Speaking of kernels, is there a good current guide to compiling a kernel? I've traditionally just run Slackware with the "huge" kernel with whatever standard modules Slackware decides I need. I don't do loads of intensive stuff, though perhaps Minecraft qualifies. I'm not sure how much gain there is in rummaging through all the components, removing what I'm not using, and then loading the remaining as modules.

I did once or twice compile my own kernel but somehow fell down between that part and actually using it. This was just a few years ago, and at the time it was easy to find comments regarding the sorry state of documentation on kernel compilation.

muraii wrote:

Speaking of kernels, is there a good current guide to compiling a kernel? I've traditionally just run Slackware with the "huge" kernel with whatever standard modules Slackware decides I need. I don't do loads of intensive stuff, though perhaps Minecraft qualifies. I'm not sure how much gain there is in rummaging through all the components, removing what I'm not using, and then loading the remaining as modules.

I did once or twice compile my own kernel but somehow fell down between that part and actually using it. This was just a few years ago, and at the time it was easy to find comments regarding the sorry state of documentation on kernel compilation.

Arch has a decent, general guide.

In most cases there's little reason to build your own kernel these days, though. If I needed something specific (e.g. a patch that wasn't merged) I'd probably grab a working config from a mainstream distro as a base and modify it as minimally as possible to meet the requirements.

For general performance, is there much benefit to compiling the kernel closer to your specific CPU, rather than generic and compatible i386/x86_64?

I've seen specific big load apps vastly improve in some scenarios, but I wouldn't of though overall OS performance would improve that much.

gore wrote:
muraii wrote:

Speaking of kernels, is there a good current guide to compiling a kernel? I've traditionally just run Slackware with the "huge" kernel with whatever standard modules Slackware decides I need. I don't do loads of intensive stuff, though perhaps Minecraft qualifies. I'm not sure how much gain there is in rummaging through all the components, removing what I'm not using, and then loading the remaining as modules.

I did once or twice compile my own kernel but somehow fell down between that part and actually using it. This was just a few years ago, and at the time it was easy to find comments regarding the sorry state of documentation on kernel compilation.

Arch has a decent, general guide.

In most cases there's little reason to build your own kernel these days, though. If I needed something specific (e.g. a patch that wasn't merged) I'd probably grab a working config from a mainstream distro as a base and modify it as minimally as possible to meet the requirements.

Obliged. I figured we were in the "no need to bother" realm but I don't track in knowledgeable circles and like to check periodically.

Here's a question back on the partitioning. Can you share the /home directory between distro's? I would assume there wouldn't be a problem between say Ubuntu and Mint, but what about if it was Ubuntu 12.04 and a Mint version based on 12.10? What about a different distro altogether, like Arch?

Scratched wrote:

For general performance, is there much benefit to compiling the kernel closer to your specific CPU, rather than generic and compatible i386/x86_64?

I've seen specific big load apps vastly improve in some scenarios, but I wouldn't of though overall OS performance would improve that much.

If you're on a 64-bit system, then I'd definitely recommend running a 64-bit kernel and userspace, due to the performance boost the extra registers and such in AMD64 bring, but apart from that, I don't think building for your specific CPU is going to make much of a difference. It's one of those things we all used to do, maybe a decade ago, as a matter of course, but I never noticed a difference back then, either -- it was just something we did

Citizen86 wrote:

Here's a question back on the partitioning. Can you share the /home directory between distro's? I would assume there wouldn't be a problem between say Ubuntu and Mint, but what about if it was Ubuntu 12.04 and a Mint version based on 12.10? What about a different distro altogether, like Arch?

Fundamentally, yep, you can, but having different versions of apps or your desktop on the different distros can cause problems, depending on the app or desktop in question. As long as the differences aren't too huge, you're probably fine.

x86_64 has a high enough baseline that the additional features that have come out since aren't as important. i386 evolved a great deal over the years, and i686 code could be much faster, but all compilers can assume a broad range of ancillary features if they're targeting 64-bit x86. I think, for instance, they can all assume SSE2. They can't assume SSE4, but going from 2->4 is much less of a boost than going from nothing to 2.

However, if you're doing a lot of encryption work (like running high-performance VPNs), and you're on a recent-enough CPU, then the AES New Instructions can be quite helpful, and you might want to look into getting a kernel and/or userland encryption software compiled with that support. The speed boost can be quite dramatic.

Here's a question back on the partitioning. Can you share the /home directory between distro's? I would assume there wouldn't be a problem between say Ubuntu and Mint, but what about if it was Ubuntu 12.04 and a Mint version based on 12.10? What about a different distro altogether, like Arch?

That's usually not a good idea, because the distros will have different versions of the desktop software. Most programs will happily upgrade older versions of a config, so you can usually bring an old config to a new install, but very few (none?) can safely go backward.

What you'd probably want to do is set up a separate volume that you could use to transfer files back and forth, perhaps even a server, rather than trying to share a /home between disparate OSes.

pneuman wrote:

If /boot is filling up, look for old kernel packages like this:

You can remove them with apt-get like -- you can specify a bunch of kernel package names in the one command to remove them all at once, eg:

sudo apt-get --purge remove linux-image-3.5.0-22-generic linux-image-3.5.0-23-generic linux-image-3.5.0-24-generic

That last Sudo command seems to do the trick.. freeing up over 200 megs.

Will see out it goes out.

Ok, I was able to install Netflix desktop on my Ubuntu install.

Yay me!

Now, to find a way with iTunes, and soon, I'll drop windows for a lot of little things...

Yeah, the Netflix Desktop works pretty well. It actually works better for me in Linux Mint with Cinnamon, surprisingly enough. On 12.04, full-screen doesn't quite work, it keeps the window border. In Cinnamon, the Netflix fullscreen button actually makes the video fullscreen.

I assume many of you use terminal windows. Currently, my main UI is such:

I use Openbox with tint2 and, I think, lxdepanel. No desktop image, no icons on the desktop, no desktop to speak of. In my rc.xml settings file, I define all manner of keybindings. Five concern xterm windows. One creates a fullscreen xterm and each of the other four create xterm windows sitting in a quadrant of the screen. At one time I wanted to create them such that all four invoked (and if above other app windows) would completely cover the screen without overlapping, but I think I gave up on that for 80x25 reasons.

This all runs in Slackware 13.37. As I'm about to (finally) build my machine, one with a bit more GPU room to spare, I'm thinking of going at least to a full DE in Slackware if not to something at the other end of the curmedgeon spectrum like Linux Mint. I'm curious what kind of setups people are using, in terms of UI responsiveness, maximizing utility of terminal windows, and ease of assigning keybindings. I suppose I could go to, say, KDE and use Openbox as its window manager, capitalizing on my familiarity with rc.xml. But it feels like maybe it's time to look around and see if something fits a little better.

Is that open-ended and vague enough? Internet!

I use GNOME Shell. A great deal of my daily use is in Chromium and gnome-terminal. I like Shell very much because it gets out of my way and lets me work.

I use the Meta key to access the "Activities" view. I start typing the name of the thing I want. I hit enter. I have that thing, and all that's left of Shell on my screen is the menu bar at top. No docks, no nothing. Gimme thing and go away. Thank you.

I typically have everything running maximized unless I have a particular need for it to not be. At work I use two monitors, on the righthand monitor I leave Chromium open to my corporate webmail. I have at most two "virtual desktops" the second of which is sometimes used as a place to dump stuff; however I feel less need for virtual desktops with Shell than with most other DEs I have used. I typically only have one gnome-terminal window, maximized, but I make extensive use of tabs and tmux for multitasking therein.

A lot of people hate Shell because it is not like GNOME 2, but I find it superior to GNOME 2 and indeed it is the most pleasing desktop environment I have used.

My main remaining gripe with Shell is notifications, which have gone through several iterations and I still feel suffer from poorly considered design goals which favor "cleanliness" over usability.

gore wrote:

I use GNOME Shell. A great deal of my daily use is in Chromium and gnome-terminal. I like Shell very much because it gets out of my way and lets me work.

I use the Meta key to access the "Activities" view. I start typing the name of the thing I want. I hit enter. I have that thing, and all that's left of Shell on my screen is the menu bar at top. No docks, no nothing. Gimme thing and go away. Thank you.

...

I typically only have one gnome-terminal window, maximized, but I make extensive use of tabs and tmux for multitasking therein.

I use screen all the time, and use bashrun similarly to how you use the "Activities" view. Between bashrun and keybindings I get to almost everything I need. One small but great thing about bashrun is that there's no need to append " &" to your command.

I assume you're in Ubuntu. Is that accurate?

My main remaining gripe with Shell is notifications, which have gone through several iterations and I still feel suffer from poorly considered design goals which favor "cleanliness" over usability.

This is the kind of thing I'm evaluating against. My setup is very clean but there are some cases in which I have to do some hunting. I have no (graphical) central list of what's installed in my current setup, for instance, and don't like the alternatives: I don't like other panels and using KDE or even Xfce is both kinda fugly and taxes my resources noticeably if only just.

I guess I'll install Ubuntu or Mint and jiggle around with it before installing Slackware 14.

Thank ye.

I'm enjoying Cinnamon on Linux Mint. I do the same thing I do in Unity and Windows 7/8 to open a program: special key, type the program name until it's first in the list, press enter. Kablam.

muraii wrote:

I assume you're in Ubuntu. Is that accurate?

I use Arch on my PCs. I know a lot of people really like Ubuntu, but Unity never grabbed me. Personally I'd rather just run upstream Debian if I wanted an apt based distribution since I don't care for the Ubuntu value add (Unity, Upstart, Mir?).

I really favor a rolling release on a PC since there's always software I want to be bleeding edge with, and waiting for releases of even a "fast" distribution like Ubuntu can feel really slow. I used to use Debian Unstable and Gentoo for that reason, but Arch really suits me well.

gore wrote:
muraii wrote:

I assume you're in Ubuntu. Is that accurate?

I use Arch on my PCs. I know a lot of people really like Ubuntu, but Unity never grabbed me. Personally I'd rather just run upstream Debian if I wanted an apt based distribution since I don't care for the Ubuntu value add (Unity, Upstart, Mir?).

I really favor a rolling release on a PC since there's always software I want to be bleeding edge with, and waiting for releases of even a "fast" distribution like Ubuntu can feel really slow. I used to use Debian Unstable and Gentoo for that reason, but Arch really suits me well.

Now I'm going to think about trying Arch. Poverty of riches.