On 11/16/2024 16:20, D wrote:
>
>
> On Sat, 16 Nov 2024, Phillip Frabott wrote:
>
>> On 11/16/2024 04:31, D wrote:
>>>
>>>
>>> On Fri, 15 Nov 2024, Phillip Frabott wrote:
>>>
>>>> nano
>>>> git
>>>> openssh
>>>> gnutls
>>>> links
>>>> bash
>>>> automake
>>>> autoconf
>>>> gcc
>>>> mutt
>>>> htop
>>>> iotop
>>>> gomuks
>>>> tmux
>>>> WordGrinder
>>>>
>>>> and that's it.
>>>>
>>>> When I'm done I go home and spend the evening with family.
>>>
>>> Wordgrinder is not a common choice. Could you please tell me a bit
>>> about it? Wat is it with wordgrinder that guys you joy when writing
>>> texts?
>>
>> I should probably note, if it's not apparent in the list above, I live
>> in bash. I do not use a WM day-to-day. I'm a purist shell-only user.
>> WordGrinder is the only shell program I was able to find that has
>> support great support for ODT, a format that I have to be able to use
>> at work since almost all of our documents are either ODT or MD (Mostly
>> ODT). It has a pretty decent spell checker that you can add to it's
>> dictionary and has pretty good formatting support within the
>> limitations of shell (You won't be adding images, but I don't get paid
>> enough to make documentation with pretty pictures anyways). It is
>> probably the most feature-rich shell application I've found so far.
>> You can look at it here if you want: https://cowlark.com/wordgrinder/
>>
>> If you have a recommendation for something other then WordGrinder that
>> works without any Xorg/X11 components installed though, I'd be happy
>> to try it out. It has to support opening and saving (or importing/
>> exporting) into ODT and MD formats and must be able to compile source-
>> only and no docker.
>>
>> Before you ask, since you'll probably find me in another thread asking
>> about Gentoo related to KDE, I do have Xorg installed on another
>> machine but it's only for the small sliver of time where I have to
>> test a desktop program I'm writing for the company I work for. And I
>> use a separate machine for that. Most of my time is in headless code
>> though so it's not often I have to boot it up.
>
> Thank you for sharing! Very interesting. What type of work do you do
> where you are able to get by with only the shell? You must have a very
> kind employer! =)

I am a headless C developer (Sometimes C++). I develop code that must
run on machines that have zero interfaces or local terminal access. I
think the new term is headless software engineer but that's just a
little too fancy of a title for me. So I stick with C developer. I code
for anything from embedded devices (the smallest was a 1" by 1" device
with 4MB of Flashable EEPROM and 1.25MB of memory on a 548MHz processor)
all the way up to large data center scale servers. I also have a Data
center background on top of that so it gives me a leg up when it comes
to understanding how an application will be used. (most developers only
learn to develop. They never go further to learn how it's going to be
implemented and used later which means they can't account for the things
their program will be demanded to do. I have the advantage of know how
data centers work so I can code accordingly.)

Since the binary programs have to run headless, I code with shell access
only. So I'm in a near comparable environment to how the program would
be run. Limiting myself to only having shell access helps to put me (and
my team of 11 which also work in shell only) in the mental state of how
the program will operate. So if we can't do it from shell, then the
headless binary won't be able to either. In fact, it's a requirement we
code in shell only. Company law (I may or may not have been responsible
for it. But I'll plead the 5th if you ask me.)

>
> As for word processing, the usual suspects are vim, groff, latex and for
> converting documents back and forth, I think that pandoc is very common.
>
> But this is all hearsay, so I am sure there are others here in this
> group who know much more about it than I do.

While I'm sure that Vim an Groff and others are capable of
converting/using these formats back and forth, WordGrinder is a more
dedicated purpose application. Trying to use multi-purpose editors just
adds more complexity not to mention the fact that you have to build
additional addons and configurations to get the feature set that
WordGrinder provides out of the box. So that's why it was ultimately chosen.

--
Phillip Frabott
----------
- Adam: Is a void really a void if it returns?
- Jack: No, it's just nullspace at that point.
----------

On 11/17/24 14:33, Phillip Frabott wrote:
> On 11/16/2024 16:20, D wrote:
>>
>>
>> On Sat, 16 Nov 2024, Phillip Frabott wrote:
>>
>>> On 11/16/2024 04:31, D wrote:
>>>>
>>>>
>>>> On Fri, 15 Nov 2024, Phillip Frabott wrote:
>>>>
>>>>> nano
>>>>> git
>>>>> openssh
>>>>> gnutls
>>>>> links
>>>>> bash
>>>>> automake
>>>>> autoconf
>>>>> gcc
>>>>> mutt
>>>>> htop
>>>>> iotop
>>>>> gomuks
>>>>> tmux
>>>>> WordGrinder
>>>>>
>>>>> and that's it.
>>>>>
>>>>> When I'm done I go home and spend the evening with family.
>>>>
>>>> Wordgrinder is not a common choice. Could you please tell me a bit
>>>> about it? Wat is it with wordgrinder that guys you joy when writing
>>>> texts?
>>>
>>> I should probably note, if it's not apparent in the list above, I
>>> live in bash. I do not use a WM day-to-day. I'm a purist shell-only
>>> user. WordGrinder is the only shell program I was able to find that
>>> has support great support for ODT, a format that I have to be able to
>>> use at work since almost all of our documents are either ODT or MD
>>> (Mostly ODT). It has a pretty decent spell checker that you can add
>>> to it's dictionary and has pretty good formatting support within the
>>> limitations of shell (You won't be adding images, but I don't get
>>> paid enough to make documentation with pretty pictures anyways). It
>>> is probably the most feature-rich shell application I've found so
>>> far. You can look at it here if you want:
>>> https://cowlark.com/wordgrinder/
>>>
>>> If you have a recommendation for something other then WordGrinder
>>> that works without any Xorg/X11 components installed though, I'd be
>>> happy to try it out. It has to support opening and saving (or
>>> importing/ exporting) into ODT and MD formats and must be able to
>>> compile source- only and no docker.
>>>
>>> Before you ask, since you'll probably find me in another thread
>>> asking about Gentoo related to KDE, I do have Xorg installed on
>>> another machine but it's only for the small sliver of time where I
>>> have to test a desktop program I'm writing for the company I work
>>> for. And I use a separate machine for that. Most of my time is in
>>> headless code though so it's not often I have to boot it up.
>>
>> Thank you for sharing! Very interesting. What type of work do you do
>> where you are able to get by with only the shell? You must have a very
>> kind employer! =)
>
> I am a headless C developer (Sometimes C++). I develop code that must
> run on machines that have zero interfaces or local terminal access. I
> think the new term is headless software engineer but that's just a
> little too fancy of a title for me. So I stick with C developer.

Backend developer, or driver/service/server developer as opposed to
frontend, GUI, or UI developer. Never heard headless developer.

> I code
> for anything from embedded devices (the smallest was a 1" by 1" device
> with 4MB of Flashable EEPROM and 1.25MB of memory on a 548MHz processor)
> all the way up to large data center scale servers. I also have a Data
> center background on top of that so it gives me a leg up when it comes
> to understanding how an application will be used. (most developers only
> learn to develop. They never go further to learn how it's going to be
> implemented and used later which means they can't account for the things
> their program will be demanded to do. I have the advantage of know how
> data centers work so I can code accordingly.)
>
> Since the binary programs have to run headless, I code with shell access
> only. So I'm in a near comparable environment to how the program would
> be run. Limiting myself to only having shell access helps to put me (and
> my team of 11 which also work in shell only) in the mental state of how
> the program will operate. So if we can't do it from shell, then the
> headless binary won't be able to either. In fact, it's a requirement we
> code in shell only. Company law (I may or may not have been responsible
> for it. But I'll plead the 5th if you ask me.)
>

That is bizarre. It is much easier to code, debug, test in a good
graphical IDE, even if you are developing console apps.

On 2024-11-17, Pancho <Pancho.Jones@proton.me> wrote:

> On 11/17/24 14:33, Phillip Frabott wrote:
>
>> I am a headless C developer (Sometimes C++).

Is that like Roland the headless Thompson gunner? :-)
(Thank you, Warren Zevon.)

> That is bizarre. It is much easier to code, debug, test in a good
> graphical IDE, even if you are developing console apps.

Horses for courses. Never underestimate the value of a
few printf()s sprinkled here and there (or log file writes
if you're really headless). I'm still a fan of makefiles.

--
/~\ Charlie Gibbs | Growth for the sake of
\ / <cgibbs@kltpzyxm.invalid> | growth is the ideology
X I'm really at ac.dekanfrus | of the cancer cell.
/ \ if you read it the right way. | -- Edward Abbey

On 17/11/2024 15:18, Pancho wrote:
> It is much easier to code, debug, test in a good graphical IDE, even if
> you are developing console apps.

Not if the target machine doesn't have a GUI or a console at all.

--
Socialism is the philosophy of failure, the creed of ignorance and the
gospel of envy.

Its inherent virtue is the equal sharing of misery.

Winston Churchill

On 11/17/24 17:17, Charlie Gibbs wrote:
> On 2024-11-17, Pancho <Pancho.Jones@proton.me> wrote:
>
>> On 11/17/24 14:33, Phillip Frabott wrote:
>>
>>> I am a headless C developer (Sometimes C++).
>
> Is that like Roland the headless Thompson gunner? :-)
> (Thank you, Warren Zevon.)
>
>> That is bizarre. It is much easier to code, debug, test in a good
>> graphical IDE, even if you are developing console apps.
>
> Horses for courses. Never underestimate the value of a
> few printf()s sprinkled here and there (or log file writes
> if you're really headless). I'm still a fan of makefiles.
>

Not really, people who use IDE's still use loggers.

People who use IDEs, use build automation scripts: Gradle, Mavern. It is
rude to force people to use a specific IDE, so some kind of IDE
independent (cross compatible) project definition build script is needed.

Caveat: I don't really remember make.

On 11/17/24 17:47, The Natural Philosopher wrote:
> On 17/11/2024 15:18, Pancho wrote:
>> It is much easier to code, debug, test in a good graphical IDE, even
>> if you are developing console apps.
>
> Not if the target machine doesn't have a  GUI or a console at all.
>

Even then, develop in an IDE, run on the target machine.

I never really believed Linus' assertion that developers needed to
develop on the same OS that the software was going to run on. As soon as
Microsoft Visual Studio came out, mid 1990s, we used it on PCs to
develop programs that ran on Solaris servers. We probably retained the
capability to make final adjustments on the Sparc, but that wasn't where
the main bulk of the work was done. I seem to remember we had the
capability to build from makefiles, but I can't remember if we loaded
the makefiles into Visual Studio or generated them from Visual Studio,
or both.

Visual Studio was just better than vi, I find it strange to even have to
debate that point.

On Sun, 17 Nov 2024 17:17:37 GMT, Charlie Gibbs wrote:

> Horses for courses. Never underestimate the value of a few printf()s
> sprinkled here and there (or log file writes if you're really headless).
> I'm still a fan of makefiles.

I'm a dinosaur so my preferred technique is either printf or log files.
For production code I've sometimes created a sequence of log statements
that can be turned on with a flag that are a narrative of what's going on.
My goal is a support person can read the file and see where the problem
occurs. Often it is a configuration issue they can fix.

The nice part is the technique can be used with any language and is
effective where a debugger isn't available.

On Sun, 17 Nov 2024 18:06:31 +0000, Pancho wrote:

> ... I can't remember if we loaded
> the makefiles into Visual Studio or generated them from Visual Studio,
> or both.

Visual Studio has never had the capability to work with *nix-style
Makefiles. That’s one reason why “meta-build” systems (my term) like CMake
were invented: their build scripts are higher-level wrappers that will
generate, for example, Makefiles or Ninja control files on *nix, and
Visual Studio project files on Windows.

On Sun, 17 Nov 2024 17:17:37 GMT, Charlie Gibbs wrote:

> Never underestimate the value of a few printf()s
> sprinkled here and there (or log file writes if you're really headless).

I don’t really see that much difference. On *nix systems, service managers
can redirect stdout or stderr to logfiles anyway, so I can run my code
directly from a terminal for testing, and then in the background via a
service definition for production use, without having to make any code
changes.

> I'm still a fan of makefiles.

Automated build scripts certainly. Ninja seems to be a common alternative
to make nowadays. But you need a higher-level wrapper to generate the
control files: e.g. Autotools, Meson, CMake etc.

On 11/17/2024 10:18, Pancho wrote:
>
> That is bizarre. It is much easier to code, debug, test in a good
> graphical IDE, even if you are developing console apps.
>
>

Your assuming that a debugger can even run on such limited memory on the
specific CPU being used. Most of my work involves very limited memory
constraints. And these aren't x86 compatible processors so it's not like
I can debug on the local dev machine. It all has to run on the hardware.
so printf() and the occasional rawdump file being stored on an SD card
if your lucky enough to get access to a device with an SD card reader is
the only real option. Obviously this wouldn't be true for the larger
headless systems but I'm not going to have 2 different development
configurations for coding embedded devices vs large servers. And GUI's
just become distractions anyways. Everything I need is in bash. So if I
was to use a GUI I'd be right back into multiple bash windows with no
desktop apps anyways, so why waste the resources of GUI when I'm never
going to utilize it the way it was meant to be used?

It's just a different breed of development here. We are very uncommon.
But we love it.

--
Phillip Frabott
----------
- Adam: Is a void really a void if it returns?
- Jack: No, it's just nullspace at that point.
----------

On 11/17/24 2:52 PM, Phillip Frabott wrote:
> On 11/17/2024 10:18, Pancho wrote:
>>
>> That is bizarre. It is much easier to code, debug, test in a good
>> graphical IDE, even if you are developing console apps.
>>
>>
>
> Your assuming that a debugger can even run on such limited memory on the
> specific CPU being used. Most of my work involves very limited memory
> constraints. And these aren't x86 compatible processors so it's not like
> I can debug on the local dev machine. It all has to run on the hardware.
> so printf() and the occasional rawdump file being stored on an SD card
> if your lucky enough to get access to a device with an SD card reader is
> the only real option. Obviously this wouldn't be true for the larger
> headless systems but I'm not going to have 2 different development
> configurations for coding embedded devices vs large servers. And GUI's
> just become distractions anyways. Everything I need is in bash. So if I
> was to use a GUI I'd be right back into multiple bash windows with no
> desktop apps anyways, so why waste the resources of GUI when I'm never
> going to utilize it the way it was meant to be used?
>
> It's just a different breed of development here. We are very uncommon.
> But we love it.

Microcontrollers or similar ? LOVE 'em. Also love
the DISCIPLINE required to program in super-limited
speed/mem environments ... something the younger
set rarely even considers.

Every "Intro To Computers" should at least require
an "Arduino Uno" lab :-)

Ok ... PIC 12x if you REALLY want them to suffer :-)

For a time I often used PIC 12x to emulate some of
those CD4000 chips you could buy at Radio Shack ...
esp counters, if extreme speed wasn't required.
Almost as cheap, and if you wanted them to do
something a little different then you just changed
the pgm a little. Needed a DIV7 on inputs for one
app, and the PIC made it all so easy. If the need
changed to DIV9, again super-easy. Even a pin or
two left over to xmit a serial stream to some
other chips, smarter hardware :-)

After consideration ...... you only install WHAT YOU ARE
LIKELY TO *NEED*. That will vary from person to person,
app to app, year to year. The more shit you install the
more complicated things get.

Just make sure 'nano' is there. There's a trick to
setting the default editor to nano, find it. I know
Manjaro doesn't just assume this - loves to default
to the horrible 'vi' or 'vim'. Nano makes things
SO much nicer - like kinda up to 1984 :-)

On Sun, 17 Nov 2024, Phillip Frabott wrote:

>> Thank you for sharing! Very interesting. What type of work do you do where
>> you are able to get by with only the shell? You must have a very kind
>> employer! =)
>
> I am a headless C developer (Sometimes C++). I develop code that must run on
....
> law (I may or may not have been responsible for it. But I'll plead the 5th if
> you ask me.)

Thank you very much for sharing, sounds like a very nice job given
todays sh*tty development environments and "devops"-tooling.

>>
>> As for word processing, the usual suspects are vim, groff, latex and for
>> converting documents back and forth, I think that pandoc is very common.
>>
>> But this is all hearsay, so I am sure there are others here in this group
>> who know much more about it than I do.
>
> While I'm sure that Vim an Groff and others are capable of converting/using
> these formats back and forth, WordGrinder is a more dedicated purpose
> application. Trying to use multi-purpose editors just adds more complexity
> not to mention the fact that you have to build additional addons and
> configurations to get the feature set that WordGrinder provides out of the
> box. So that's why it was ultimately chosen.

Makes sense.

On Sun, 17 Nov 2024, rbowman wrote:

> On Sun, 17 Nov 2024 17:17:37 GMT, Charlie Gibbs wrote:
>
>> Horses for courses. Never underestimate the value of a few printf()s
>> sprinkled here and there (or log file writes if you're really headless).
>> I'm still a fan of makefiles.
>
> I'm a dinosaur so my preferred technique is either printf or log files.
> For production code I've sometimes created a sequence of log statements
> that can be turned on with a flag that are a narrative of what's going on.
> My goal is a support person can read the file and see where the problem
> occurs. Often it is a configuration issue they can fix.
>
> The nice part is the technique can be used with any language and is
> effective where a debugger isn't available.
>

I'm a printf-man, and since I've mostly worked with systems and not mainly
code logfiles have been essential for me. Have never had the need to go
deeper than that.

186282@ud0s4.net <186283@ud0s4.net> wrote:
> After consideration ...... you only install WHAT YOU ARE
> LIKELY TO *NEED*. That will vary from person to person,
> app to app, year to year.
True, but probably you will keep using the same stuff year after
year, unless your job changes.

> The more shit you install the
> more complicated things get.
Not really, you just waste some space for something you installed but don't
use and then forget about.
> Just make sure 'nano' is there. There's a trick to setting the default
> editor to nano, find it. I know Manjaro doesn't just assume this - loves to
> default to the horrible 'vi' or 'vim'. Nano makes things SO much nicer -
> like kinda up to 1984 :-)

Not nicer, easier for someone that doesn't use text editor often and has to
make a small change in a config file. Fedora switched its default editor to
Nano for this reason time ago. If you use a text editor for programming using
Nano instead of vim (or emacs) would be a nightmare.

As for the "Subject", I usally install Fedora with the "netinstall" disc so I
can choose from the start what I want and I have a system with KDE, vim,
gnuplot, gcc, gdb, LaTeX, Libreoffice ready, I have to add very little:
xmgrace and agrmerge, plus a few utilities I use, like ncdu, htop and bpytop,
ag, pdfshuffler...

G

On 11/18/2024 00:42, 186282@ud0s4.net wrote:
> Just make sure 'nano' is there. There's a trick to
> setting the default editor to nano, find it.

I usually just symlink vi and vim to nano. Never had problems with it.

--
Phillip Frabott
----------
- Adam: Is a void really a void if it returns?
- Jack: No, it's just nullspace at that point.
----------

On 18/11/2024 14:36, Phillip Frabott wrote:
> On 11/18/2024 00:42, 186282@ud0s4.net wrote:
>> Just make sure 'nano' is there. There's a trick to
>> setting the default editor to nano, find it.
>
> I usually just symlink vi and vim to nano. Never had problems with it.
>
Year of using vi have made me ok with it. For small jobs.
For bigger jobs I either use s GUI editor or joe.
Geany is my coding app of choice.

--
"Strange as it seems, no amount of learning can cure stupidity, and
higher education positively fortifies it."

- Stephen Vizinczey

On Mon, 18 Nov 2024 09:36:17 -0500, Phillip Frabott wrote:

> I usually just symlink vi and vim to nano.

You can just set the $EDITOR and $VISUAL environment variables, and leave
it at that.

<https://manpages.debian.org/1/sensible-editor.1.en.html>

On 11/18/2024 18:15, Lawrence D'Oliveiro wrote:
> On Mon, 18 Nov 2024 09:36:17 -0500, Phillip Frabott wrote:
>
>> I usually just symlink vi and vim to nano.
>
> You can just set the $EDITOR and $VISUAL environment variables, and leave
> it at that.
>
> <https://manpages.debian.org/1/sensible-editor.1.en.html>

Yeah, but not all programs use those variables. So to catch everything a
symlink works. Not to mention that running the ln command is a little
faster then editing the bash scripts. But envvars works for 90% of cases
so it's a great option for programs that use it.

--
Phillip Frabott
----------
- Adam: Is a void really a void if it returns?
- Jack: No, it's just nullspace at that point.
----------

On Mon, 18 Nov 2024 21:39:18 -0500, Phillip Frabott wrote:

> On 11/18/2024 18:15, Lawrence D'Oliveiro wrote:
>
>> You can just set the $EDITOR and $VISUAL environment variables, and
>> leave it at that.
>>
>> <https://manpages.debian.org/1/sensible-editor.1.en.html>
>
> Yeah, but not all programs use those variables.

Which ones don’t?

On Mon, 18 Nov 2024 21:39:18 -0500, Phillip Frabott wrote:

> On 11/18/2024 18:15, Lawrence D'Oliveiro wrote:
>
>> You can just set the $EDITOR and $VISUAL environment variables, and
>> leave it at that.
>>
>> <https://manpages.debian.org/1/sensible-editor.1.en.html>
>
> Yeah, but not all programs use those variables.

Which ones don’t?

On 11/18/2024 21:45, Lawrence D'Oliveiro wrote:
> On Mon, 18 Nov 2024 21:39:18 -0500, Phillip Frabott wrote:
>
>> On 11/18/2024 18:15, Lawrence D'Oliveiro wrote:
>>
>>> You can just set the $EDITOR and $VISUAL environment variables, and
>>> leave it at that.
>>>
>>> <https://manpages.debian.org/1/sensible-editor.1.en.html>
>>
>> Yeah, but not all programs use those variables.
>
> Which ones don’t?

I don't run into to it very often. Usually it's smaller less known
projects or older programs. I'm not going to remember exactly what
programs they were because it only happens here and there and it's
likely I haven't used a program like that in a while. But they still
exist. Either when a dev doesn't do the right thing or if they are doing
cross-platform where not all platforms use it. (Windows for example).
But I've just always done `ln` all the way back to the 80's so it's just
habit for me.

--
Phillip Frabott
----------
- Adam: Is a void really a void if it returns?
- Jack: No, it's just nullspace at that point.
----------

On Mon, 18 Nov 2024 22:20:45 -0500, Phillip Frabott wrote:

> Either when a dev doesn't do the right thing or if they are doing
> cross-platform where not all platforms use it. (Windows for example).

If it’s open source, submit a patch to fix it.

All the cross-platform open-source software should have learned to respect
common *nix conventions by now.

On 11/18/2024 23:59, Lawrence D'Oliveiro wrote:
> On Mon, 18 Nov 2024 22:20:45 -0500, Phillip Frabott wrote:
>
>> Either when a dev doesn't do the right thing or if they are doing
>> cross-platform where not all platforms use it. (Windows for example).
>
> If it’s open source, submit a patch to fix it.
>
> All the cross-platform open-source software should have learned to respect
> common *nix conventions by now.

It's not that big of a deal really. And to be honest, when I go home
from work, I don't touch a computer.

--
Phillip Frabott
----------
- Adam: Is a void really a void if it returns?
- Jack: No, it's just nullspace at that point.
----------

On 11/18/24 4:46 AM, G wrote:
> 186282@ud0s4.net <186283@ud0s4.net> wrote:
>> After consideration ...... you only install WHAT YOU ARE
>> LIKELY TO *NEED*. That will vary from person to person,
>> app to app, year to year.
> True, but probably you will keep using the same stuff year after
> year, unless your job changes.

As said ... "what you need".

There isn't a gigabyte set of utilities/apps
that everyone HAS to have. If you are doing
terminal-only then that list can be quite small.
If you are not doing much dev work then a lot
of stuff can be ignored. All in all, less is
better, even with Linux.

>> The more shit you install the
>> more complicated things get.
> Not really, you just waste some space for something you installed but don't
> use and then forget about.
>
>> Just make sure 'nano' is there. There's a trick to setting the default
>> editor to nano, find it. I know Manjaro doesn't just assume this - loves to
>> default to the horrible 'vi' or 'vim'. Nano makes things SO much nicer -
>> like kinda up to 1984 :-)
>
> Not nicer, easier for someone that doesn't use text editor often and has to
> make a small change in a config file. Fedora switched its default editor to
> Nano for this reason time ago. If you use a text editor for programming using
> Nano instead of vim (or emacs) would be a nightmare.

Anything less than nano IS a nightmare ... remind me
of the horrific 'edlin' that came with early DOS. At
least nano kinda gets you into the 1980s ......

Long back wrote an ASM app that was a full-screen
editor like nano - using the IBM-PC BIOS routines
made it a lot easier. I did it because I *hated*
edlin so much (and writing ASM was a buzz). Recently
found the code for an early version of it in my
archives ... maybe I'll re-do/finish, but for 32 bit.

>
> As for the "Subject", I usally install Fedora with the "netinstall" disc so I
> can choose from the start what I want and I have a system with KDE, vim,
> gnuplot, gcc, gdb, LaTeX, Libreoffice ready, I have to add very little:
> xmgrace and agrmerge, plus a few utilities I use, like ncdu, htop and bpytop,
> ag, pdfshuffler...

I'm not a fanatic, indeed almost always install a GUI
for convenience. Do NOT always set it to autostart
however, depending. For SOME things those GUI file
managers/editors make life SO much easier. Fooling
with the latest FreeBSD right now ... XFCE installed
but does NOT autostart.

Depending on YOUR wants and needs even LibreOffice
might be a good addition. It IS just HUGE though
with massive dependencies.

It's the "dependencies" issue that most peeves me
about Linux. Maybe seemed OK long long back but
it's become a DRAG ... an impediment to "doing
stuff" as it's hard to find the EXACT right versions
of lib files and such. For all its evil, M$ is MUCH
better at this stuff. Time for a new paradigm
for Linux.

But how to get SO many developers on-board at
the same time ???