Who was the genius that decided that system-config-network-tui should NOT be part of the base CentOS 6.3 install ??
Not to mention it has insane deps like wifi firmware packages... not really if all you want to do is configure eth0 from the command line...
FC
On 23/07/2012 04:40, Fernando Cassia wrote:
Who was the genius that decided that system-config-network-tui should NOT be part of the base CentOS 6.3 install ??
Not to mention it has insane deps like wifi firmware packages... not really if all you want to do is configure eth0 from the command line...
/sbin/ifconfig eth0 w.x.y.z netmask v.v.v.0 /sbin/route add default gw a.b.c.d echo nameserver e.f.g.h > /etc/resolv.conf echo nameserver i.j.k.l >> /etc/resolv.conf
On Thu, Jul 26, 2012 at 8:00 AM, Giles Coochey giles@coochey.net wrote:
echo nameserver e.f.g.h > /etc/resolv.conf echo nameserver i.j.k.l >> /etc/resolv.conf
Yes I know BUT for that I have to THINK. Screens and input fields ie type tab tab tab enter type tab tab tab enter are what is known as "user friendly" since the MS-DOS 5.0 setup.exe onwards...
;)
FC PS: I had forgotten about echo >> ... good enough for saving me from the vi madness. (I know, I know, esc i blah blah esc :w but still, I REFUSE -it's a matter of principle not to use vi ;-)
On 26/07/2012 12:34, Fernando Cassia wrote:
On Thu, Jul 26, 2012 at 8:00 AM, Giles Coochey giles@coochey.net wrote:
echo nameserver e.f.g.h > /etc/resolv.conf echo nameserver i.j.k.l >> /etc/resolv.conf
Yes I know BUT for that I have to THINK. Screens and input fields ie type tab tab tab enter type tab tab tab enter are what is known as "user friendly" since the MS-DOS 5.0 setup.exe onwards...
After having built a number of machines, I kind of rattle off that by heart, just enough to then do a:
yum install system-config-network-tui after a minimal install.
But, yes, you're right, it was a minor annoyance.
On Thu, Jul 26, 2012 at 6:34 AM, Fernando Cassia fcassia@gmail.com wrote:
PS: I had forgotten about echo >> ... good enough for saving me from the vi madness. (I know, I know, esc i blah blah esc :w but still, I REFUSE -it's a matter of principle not to use vi ;-)
How can anyone deal with command lines and not love vi? Think of it as a set of commands to change text. Even what most people call insert 'mode' is a command that takes an optional repeat count: try 20i -<escape> to get a dashed line. Maybe being old enough to have used keyboards without arrows or function keys helps, though...
On Thu, Jul 26, 2012 at 12:07 PM, Les Mikesell lesmikesell@gmail.com wrote:
Even what most people call insert 'mode' is a command that takes an optional repeat count: try 20i -<escape> to get a dashed line. Maybe being old enough to have used keyboards without arrows or function keys helps, though...
Sorry, I grew with DR-DOS and the Wordstar hotkeys. ie Ctrl-K-B Ctrl-K-K (mark text block). It's engraved in my brain cells.
That's why I use Joe... or "pico" back in the days of Caldera OpenLinux 2.3...
FC
Fernando Cassia wrote:
On Thu, Jul 26, 2012 at 12:07 PM, Les Mikesell lesmikesell@gmail.com wrote:
Even what most people call insert 'mode' is a command that takes an optional repeat count: try 20i -<escape> to get a dashed line. Maybe being old enough to have used keyboards without arrows or function keys helps, though...
Sorry, I grew with DR-DOS and the Wordstar hotkeys. ie Ctrl-K-B Ctrl-K-K (mark text block). It's engraved in my brain cells.
Gag. I loathed Wordstar. The first word processor I ever voluntarily used, and still prefer to Dirt, er, Word, was WordPerfect 5. That was *useable*.*
That's why I use Joe... or "pico" back in the days of Caldera OpenLinux 2.3...
<alt.religion.editors> vi. emacs is a great (I suppose) windowing operating system masquerading as a text editor. </alt.religion.editors>
Wonder if I could configure the *best* text editor ever to run under wine: brief.
mark
* My old criteria for evaluating a word processor: since the primary function of a word processor is to replace a typewriter, if I couldn't sit down and write and print out a letter inside of 5 min, then its interface and bells & whistles have overwhelmed its primary function.
Btw, in ->'95<-, in a review of word processors, PC Mag noted that 90% of the users, *then*, never used more than 10% of the capabilities, and of the remaining 10%, they used some of them no more than 10% of the time.
But we need 100M+ word processors....
On Thu, Jul 26, 2012 at 12:39 PM, m.roth@5-cent.us wrote:
Wonder if I could configure the *best* text editor ever to run under wine: brief.
Brief was nice. Under OS/2 I also used QEdit which could also... mimic the Wordstar keystrokes. ;)
FC
On 2012-07-23, Fernando Cassia fcassia@gmail.com wrote:
Who was the genius that decided that system-config-network-tui should NOT be part of the base CentOS 6.3 install ??
Not to mention it has insane deps like wifi firmware packages... not really if all you want to do is configure eth0 from the command line...
Wouldn't both of these decisions have been made upstream?
--keith
On 07/26/2012 06:59 PM, Keith Keller wrote:
Who was the genius that decided that system-config-network-tui should NOT be part of the base CentOS 6.3 install ??
Not to mention it has insane deps like wifi firmware packages... not really if all you want to do is configure eth0 from the command line...
Wouldn't both of these decisions have been made upstream?
yes and no. We have some liberty to change / adapt the install class's based on what comes down stream ( remember, we normalise the distro core to remove variant specific / pricing specific options from upstream ).
The install classes and groups are things that we build, locally, in CentOS - in an attempt to match what is pushed downstream. If there are issues, its certainly worth testing to see if its a centos induced issue or not.
On 2012-07-26, Karanbir Singh mail-lists@karan.org wrote:
On 07/26/2012 06:59 PM, Keith Keller wrote:
Who was the genius that decided that system-config-network-tui should NOT be part of the base CentOS 6.3 install ??
Not to mention it has insane deps like wifi firmware packages... not really if all you want to do is configure eth0 from the command line...
Wouldn't both of these decisions have been made upstream?
yes and no. We have some liberty to change / adapt the install class's based on what comes down stream ( remember, we normalise the distro core to remove variant specific / pricing specific options from upstream ).
The install classes and groups are things that we build, locally, in CentOS - in an attempt to match what is pushed downstream. If there are issues, its certainly worth testing to see if its a centos induced issue or not.
That sounds reasonable enough (and I wondered about that for the first question).
What about the second issue? Would CentOS change RPM dependencies from upstream (if it were possible)? That seems a lot less likely to me.
--keith
On 07/26/2012 08:41 PM, Keith Keller wrote:
On 2012-07-26, Karanbir Singh mail-lists@karan.org wrote:
On 07/26/2012 06:59 PM, Keith Keller wrote:
Who was the genius that decided that system-config-network-tui should NOT be part of the base CentOS 6.3 install ??
Not to mention it has insane deps like wifi firmware packages... not really if all you want to do is configure eth0 from the command line...
Wouldn't both of these decisions have been made upstream?
yes and no. We have some liberty to change / adapt the install class's based on what comes down stream ( remember, we normalise the distro core to remove variant specific / pricing specific options from upstream ).
The install classes and groups are things that we build, locally, in CentOS - in an attempt to match what is pushed downstream. If there are issues, its certainly worth testing to see if its a centos induced issue or not.
That sounds reasonable enough (and I wondered about that for the first question).
What about the second issue? Would CentOS change RPM dependencies from upstream (if it were possible)? That seems a lot less likely to me.
We would not change the dependencies of an RPM, we might change the install groups in the comps file.
The reason it is not included in CentOS now is because it is not included upstream.
For us to change it, there would need to be a compelling reason.
On 07/27/2012 02:41 AM, Keith Keller wrote:
The install classes and groups are things that we build, locally, in CentOS - in an attempt to match what is pushed downstream. If there are issues, its certainly worth testing to see if its a centos induced issue or not.
...
What about the second issue? Would CentOS change RPM dependencies from upstream (if it were possible)? That seems a lot less likely to me.
I did'nt mean to imply rpm level changes - as Johnny already clarified, we dont do that. Every package is built and delivered with the intent of looking as close to upstream as possible.
So to clarify what I did mean : upstream has different variants, and we need to normalise those. Sometimes its tricky. Eg: a 'minimal' install option for their RHEL-6-Server looks a bit different from RHEL-6-Workstation or RHEL-6-ComputeNode. When we deliver a CentOS-6, we also have a minimal install option that tries to get the best match for the user. If there was something totally whacked out, we might then need to rename and add another group. eg. assume that RHEL-6-Workstation has a LibreOffice component included, which might be considered reasonable on a workstation, we would not want that to cascade into the CentOS-6 minimal install. A potential compromise there would be a regular 'minimal install' option for CentOS-6, as well as a 'Mimimal-Workstation install' option.
Hope that clears it up.
Regards,