The Big Linux Distro Thread

[Gibbo3771]

@princec

Snip

Pretty much why I have a love hate relationship with Linux, things like this.

I love booting into Linux just for the pure reason of arsing about, nothing really practical.

I did develop on it for a month but due to Linux crappy drivers with nVidia optimus enabled laptops, I was forced to go back to Windows as I was not certain if the performance issues were related to using an intergrated card, bad drivers or my code.

[Roquen]

@gene9

• The GUI window for the shell is all crappy and cmd.exe style. To resize the shell window, I have to right click -> props and futz with GUI settings.

I’ve already explained that. If you don’t want a command.com GUI, then run the console app under something else: emacs, mintty, rxvt, etc. etc.

…but it’s less integrated into the rest of the OS.

They are all user-space programs…there is no OS integration on any system.

I mentioned the hassle in copy/pasting paths.

Come on…that’s very minor.

But Linux is fundamentally designed around a shell something like a bash shell, in Windows it’s a foreign transplant.

Nonsense.

I haven’t tried to use Bash more seriously on Windows to articulate more specific details. If I did, I probably would try cygwin instead of msys bash and I would try soft links, which I know exist on Windows with NTFS.

Well I use it extensively. Soft links were broken in the sense that they were only visible to cygwin compiled apps…I have no idea if that has been corrected (I haven’t looked in years). The previously mentioned ‘rxvt’ hasn’t been ported to the 64-bit disto the last I looked. Also in the 64-bit disto emacs is flaky the last I looked, but I use a native build so it’s of no concern to me.

@Roquen

There’s no such animal as a “linux shell”. There are POSIX shells and there are UNIX shells. Linux is a kernel…

You are pedantic, but right. Most people call casually call bash a Linux shell because it is a common default, but you are more technically specific.

Well the mac shell is Turing complete, has auto-completion of commands and arguments, user-definable keybinding, most of emac’s line mode editing commands, a yank buffer, persistent history of last ‘N’ commands accessible by number or pattern matching, etc. etc. Pedantic is correctness for correctness sake. We’re both assuming there are some people unfamiliar with UNIX shells reading this thread…otherwise why we would be talking about basic features like auto-completion?

[princec]

FWIW I use the bash shell all the time. Puppygames runs on a Rackspace Ubuntu cloud server. I just generally hate using it for mundane tasks.

Cas

[CodeHead]

@princec

… Arch sounds like an interesting concept, though I have my beady eye on an exercise in self-flagellation called “Linux From Scratch”.

I compiled/ran a LFS system on three separate occasions. It was definitely a learning experience. Things tend to go fairly smoothly so long as you stick to the exact versions of the libraries and applications listed on the site. It can get frustrating when you hit a compilation/configuration error, but a little persistence with Google will usually get you past most roadblocks. Proceeding from LFS to BLFS is where the true frustration begins with partial instructions and dependency hell becoming more frequent.

I would say Arch is probably the closest to the LFS philosophy of “install only what you want to” without making you compile everything yourself. Reading through the Arch wiki pages also feels a lot like reading through the LFS site. Both provide fairly good descriptions of packages and detailed instructions on how to get things configured.

[Slyth2727]

Hell, I tried LFS once and quit because I had to go somewhere… I was in the middle of downloading, compiling, and running all those C packages for the system. Never even got the login to the partition part

I need to try again sometimes.

[CodeHead]

Don’t try to rush it. There are instructions on the site that tell you how to get back to the chroot environment after a shutdown. Pretty much just resetting a couple environment variables, some remounting of partitions, then the chroot itself. I did my first build over the course of a few days using VirtualBox and never had problems getting back to where I was in the build process.