okay, go ahead and shoot me, but seeking distro recommendations from your own experience

[Eyetee]

I'm looking for people who have used a wide variety of distributions in
both GUI and CLI mode and have found decent basic fallback GUI support
along with a significant level of non-server CLI functionality. Anyone
who has been an admin or a developer is especially welcome to pipe up.

Here are my criteria for my ideal distro:

1. As stated, good CLI non-server functionality with adequate GUI
fallback for when I get stuck.
2. Small install .iso that does mostly an internet-based install,
downloading packages as required.
3. Minimal bloat.
4. Minimal resource hogging even in GUI mode.
5. Good, up to date documentation that is regularly maintained.
6. Support for nvidia gpu (as I don't want to be forced to uninstall my
graphics card the way I was when I tried Debian 6.0.6).
7. Solid level 1 and 2 repositories along with some level 4 repositories
that don't cause testers' hardware to burst into flame. (Level 3
repositories are not that important.)
8. EXTREMELY IMPORTANT: Separate X11 and GUI functionalities so I'm not
forced to install a GUI just to launch a graphical application from CLI.
(To paraphrase the scroll-reading priest from _Monty Python and the Holy
Grail_, "OpenSUSE is right out!")
9. Friendliness toward separate /root, /home, /var and /tmp partitions.
(/usr is not quite so important.)
10. Access to decent development tools, including lightweight IDEs for
both programming and scripting.

What would you guys recommend?

Eyetee
--
website: www.eyetee.org

[Red Blade]

With the exception of #7 and #2, Slackware is what you're looking for.

--

Red Blade

President of alt.politics, alt.fan.rush-limbaugh, & talk.politics.misc
Fanfiction Committee Chairman of alt.tv.beavis-n-butthead

http://www.libertycolumns.com/

[Aragorn]

On Tuesday 25 December 2012 04:37, Eyetee conveyed the following to
alt.linux...

Gentoo, Arch or Slackware. Stay away from RedHat derivatives - and
especially nowadays - and from anything that rhymes with "-untu".

P.S.: Please note that /root is generally never split off from the root
filesystem - it is needed in single-user maintenance mode - and
that it's generally recommended to put /tmp on a tmpfs, rather
than on a physical disk partition.

--
= Aragorn =
(registered GNU/Linux user #223157)

[Eyetee]

On 12-12-25 12:39 AM, Red Blade wrote:
> With the exception of #7 and #2, Slackware is what you're looking for.

Can you assist me with how I can achieve some minimal level of CLI
functionality from a base Slackware 14.0 install? When I test-installed
it, I stared at "command not found" errors for an entire week before
finally giving up and flattening my Slackware partitions.

Eyetee

--
website: www.eyetee.org

[Eyetee]

On 12-12-25 02:29 AM, Aragorn wrote:

> Gentoo, Arch or Slackware. Stay away from RedHat derivatives - and
> especially nowadays - and from anything that rhymes with "-untu".

I know a bit about Gentoo and Sladkware, so please tell me a bit about Arch.

> P.S.: Please note that /root is generally never split off from the root
> filesystem - it is needed in single-user maintenance mode - and
> that it's generally recommended to put /tmp on a tmpfs, rather
> than on a physical disk partition.

Oh, I don't split off the /root fs from /, if that's what you mean.The
/tmp bit, I didn't know about. Why not put /tmp in its own partition?

Eyetee

--
website: www.eyetee.org

[Aragorn]

On Tuesday 25 December 2012 08:44, Eyetee conveyed the following to
alt.linux...

> On 12-12-25 02:29 AM, Aragorn wrote:
>
>> Gentoo, Arch or Slackware. Stay away from RedHat derivatives - and
>> especially nowadays - and from anything that rhymes with "-untu".
>
> I know a bit about Gentoo and Sladkware, so please tell me a bit about
> Arch.

I'm afraid I have no personal experience with Arch, but they do have
excellent documentation on their website.

https://www.archlinux.org/

>> P.S.: Please note that /root is generally never split off from the
>> root filesystem - it is needed in single-user maintenance mode
>> - and that it's generally recommended to put /tmp on a tmpfs,
>> rather than on a physical disk partition.
>
> Oh, I don't split off the /root fs from /, if that's what you mean.The
> /tmp bit, I didn't know about. Why not put /tmp in its own partition?

With /tmp on a tmpfs, you can rest assured that it will always be
cleaned out when the machine is shut down, because RAM is volatile.
According to the FHS 2.3, nothing in /tmp should be expected to survive
across reboots, but not all distributions clean out /tmp if you have
that on physical disk storage. Some distributions clean out /tmp on
boot via an init script, and others do it via a cron script, but the
latter relies on having /tmp mounted with "atime" or "relatime", which
you may not want, for performance reasons.

A tmpfs is an elegant solution. It lives in virtual memory, and will
only consume as much virtual memory as is needed for what it contains,
plus that the kernel can page it out partly or wholly to the swap
partition if more RAM is needed.

[J G Miller]

On Monday, December 24th, 2012, at 22:37:55h -0500, Eyetee wrote:

> What would you guys recommend?

You can do a manual (non gui) base install of Debian
and not install any X11 programs (basically a headless
server type installation).

You can then install Xorg server and whatever X11 programs
you wish.

The big advantage of Debian over other package based distribution
installations is that with Debian you start with a small base
system and add what you want, whereas with others you have to
install the distribution plus desktop and then remove what you
do not want, some of which is entirely pointless for most users.

You also have forgotten that not all GUI programs are X dependent
eg those programs which use the frame buffer, the most promising
interface library being directfb

<http://directfb.ORG/>

[Eyetee]

On 12-12-25 03:30 AM, Aragorn wrote:

> With /tmp on a tmpfs, you can rest assured that it will always be
> cleaned out when the machine is shut down, because RAM is volatile.
> According to the FHS 2.3, nothing in /tmp should be expected to survive
> across reboots, but not all distributions clean out /tmp if you have
> that on physical disk storage. Some distributions clean out /tmp on
> boot via an init script, and others do it via a cron script, but the
> latter relies on having /tmp mounted with "atime" or "relatime", which
> you may not want, for performance reasons.
>
> A tmpfs is an elegant solution. It lives in virtual memory, and will
> only consume as much virtual memory as is needed for what it contains,
> plus that the kernel can page it out partly or wholly to the swap
> partition if more RAM is needed.

What about RAM-thin hardware and devices with drivers that bloat /tmp
when the device is in use? I can see the performance advantages, just
not the resource advantages.

Eyetee

--
website: www.eyetee.org

[Eyetee]

Shameful admission: I have a Nvidia 8040GS graphics card, and Debian
does not support it. I'd need a different graphics card (but I guess I
should get a 64-bit card anyway for my 64-bit architecture; the 8040GS
was just a steal at the price I bought it for, so I bit the bullet and
bought it).

Thanks for the information, tho. :)

Eyetee

--
website: www.eyetee.org

[J G Miller]

On Tuesday, December 25th, 2012, at 10:25:12h -0500, Eyetee wrote:

> I have a Nvidia 8040GS graphics card, and Debian
> does not support it.

What exactly do you mean by "support"?

If you mean hardware acceleration support, is this not available in
the proprietary nVidia kernel blob?

If so, that is easy enough to install even through the Debian packaging system
via the non-free repository.

[Aragorn]

On Tuesday 25 December 2012 16:21, Eyetee conveyed the following to
alt.linux...

Common sense dictates that anything that writes more than a few KB worth
of data in /tmp is broken by design. Yes, Adobe Flashplayer does it,
but, well, I rest my case. :p

If a user needs to buffer more than just a few KB, then he should use
~/tmp instead of /tmp - this can be set through variables such as
$TMPDIR. The system-wide /tmp, although it has 1777 permissions, is for
things like sockets.

The beauty of UNIX (and thus GNU/Linux) is that it's a multi-user
operating system, but too many developers have their mind still stuck in
the (Microsoft) single-user paradigm.

[ray]

On Mon, 24 Dec 2012 22:37:55 -0500, Eyetee wrote:

Debian testing (wheezy) net install would seem to fulfill most of your
criteria.

[Eyetee]

The problem is getting initial display on my first Debian 6.0.6 bootup.
It's very hard to access the repository when your display screams "no
signal." What I guess I could do is write some sort of script to stick
on a flash drive along with a downloaded copy of the blob and call the
script through the initial installer configuration, but that seems like
it's pretty far and snakey. If you have other suggestions, I'm all ears.

Eyetee

--
website: www.eyetee.org

[Eyetee]

See my discussion with J G Miller in a separate subthread. When I
installed Debian 6.0.6, on initial bootup, my display whined about no
signal. Of course, at the time, I was using a really crappy 1024x768
limited TV set, while now I have a proper 16:9 1920x1080 monitor that
can make proper use of my graphics card's hdmi output. If I can get some
assurance from Debian people that the problem was Debian defaulting to
the maximum resolution my graphics card is capable of (and my old
display wasn't) or even merely forcing the use of HDMI output, I'll give
Debian another try. Otherwise, it's a matter of my graphics card not
being supported any more than ext4 is.

Eyetee

--
website: www.eyetee.org

[J G Miller]

On Tuesday, December 25th, 2012, at 16:42:30h -0500, Eyetee wrote:

> It's very hard to access the repository when your display screams "no
> signal."

Only difficult to impossible if you do not know your way around.

What you need to be aware of, and in fact no distribution
I know of, actually tells you (the newbie) up front, is that there are
virtual consoles (vc1 - vc10) on your system, with the login program
usually running on vc1-vc6 after the kernel has booted and that most
usually the X11 server runs on vc7 (or sometimes due to a misbehaving
display manager, vc10 or possibly even vc6).

Thus although your screen is black because the X11 server will not
start, you should be able to do <ALT><CTL><F1> to change to vc1
or <ALT><CTL><V2>to to change to vc2, where there will be a login
prompt and you will be able to login, look at /var/log/Xorg.0.log
to find out why the X11 server failed to start, and also install
other packages with dselect or if you prefer aptitude or synaptic.

[J G Miller]

On Tuesday, December 25th, 2012, at 16:46:3h -0500, Eyetee wrote:

> Of course, at the time, I was using a really crappy 1024x768
> limited TV set, while now I have a proper 16:9 1920x1080 monitor that
> can make proper use of my graphics card's hdmi output.

What the problem is is that for some time the Xorg sever no longer
comes with a configuration file to provide a default low resolution
X11 screen because newer versions query the EDID of the monitor to
ask it what is its maximum resolution.

Of course if the monitor is flakey and does not response appropriately
or is hidden behind a KVM switch or is not a PC monitor at all but a
TV screen which does not engage conform to the required DDC conversation
level required by Xorg, a black screen is the most likely outcome.

Then looking at the Xorg log file is the only way to see the cause of
the problem and probably requires handcrafting an xorg.conf file.

In my opinion having a carefully written xorg.conf is the best way with
the same monitor always in use of getting the best results, because how
else can you guarantee the optimum modeline for the monitor and parameters
for your particular video card?

> Otherwise, it's a matter of my graphics card not
> being supported any more than ext4 is.

Not it is a problem of your monitor not be recognised/supported
out of the box.

[J G Miller]

On Wednesday, December 26th, 2012, at 00:35:33h +0000, J G Miller wrote:

> Thus although your screen is black because the X11 server will not
> start, you should be able to do <ALT><CTL><F1> to change to vc1
> or <ALT><CTL><V2>to to change to vc2, where there will be a login
> prompt and you will be able to login

Something I forgot about is this -- kernel mode setting.

Becuase the screen going blank from the initial booting mode
to the starting of the Xorg server was deemed to be aesthetically
unpleasant, modern kernels with the appropriate graphics card
now try to put the screen into the optimum resolution even in
non X11 mode as determined by interrogating the EDID or from the
kernel command line parameters passed by GRUB.

So in some cases the user may just get a blank "no signal" screen
on vc1 - vc6 as well as a non functional X11 server.

The way around this is with radeon cards to add radeon.modeset=0
to the linux parameters on the GRUB boot screen.

Is it possible to still boot nVidia systems with user mode though?

Also take note that if the system is not booted with KMS, then
hardware acceleration direct rendering (DRI + AIGLX) will not
be available.

[Eyetee]

J G,

Since I've upgraded my display from a crappy TV set to an actual circa
2012 high res computer monitor, I'll give the Debian install another
try, keeping your suggestions about console switching in mind. I'll
report back here on what I find. Thanks for your help.

Eyetee

--
website: www.eyetee.org

[ray]

I'd strongly suggest wheezy (testing) instead of squeeze (stable). It is
my understanding that wheezy will be replacing squeeze as the stable
branch in the near future and it supports a lot of new features.

[Eyetee]

Thanks for telling me that before I actually did the install. The term
"testing" always scares me, but, considering how anal Debian is about
testing and debugging, the Debian term "testing" is probably the same
thing as most other distributions' term "stable." I'll give Wheezy a try. :)

Eyetee

--
website: www.eyetee.org

[Red Blade]

Huh? Did you mess with the PATH? I know root user doesn't include certain
directories (/usr/games, etc) by default.

Or are there certain packages you're looking for? Slackware only has "the
basics", most everything you need requires either compiling from source
or going to SlackBuilds.org.

But almost all of the basic CLI programs are included aren't they? For
me, it's everything I need except for ncurses games. What software are
you looking for?

[Red Blade]

On Thu, 27 Dec 2012 19:51:56 +0000, Red Blade wrote:

> On Tue, 25 Dec 2012 02:40:47 -0500, Eyetee wrote:
>
>> On 12-12-25 12:39 AM, Red Blade wrote:
>>> With the exception of #7 and #2, Slackware is what you're looking for.
>>
>> Can you assist me with how I can achieve some minimal level of CLI
>> functionality from a base Slackware 14.0 install? When I test-installed
>> it, I stared at "command not found" errors for an entire week before
>> finally giving up and flattening my Slackware partitions.
>>
>> Eyetee
>
> Huh? Did you mess with the PATH? I know root user doesn't include
> certain directories (/usr/games, etc) by default.
>
> Or are there certain packages you're looking for? Slackware only has
> "the basics", most everything you need requires either compiling from
> source or going to SlackBuilds.org.
>
> But almost all of the basic CLI programs are included aren't they? For
> me, it's everything I need except for ncurses games. What software are
> you looking for?

Should mention, "the basics" also include the KDE suite and its
dependencies.