System Config Tools Cleanup Project - tools to eliminate/replace

[Jaroslav Reznik]

Hi all (interested in system config tools;-).
We are working on System Configurations Tools Cleanup Project we need Fedora
community opinion on this subject.

Some s-c-* tools are now very outdated, some are replaced with better 
solution, some are only used in Anaconda etc. 

This is a short list of application that could be eliminated/replaced/enhanced 
in short/long term from Fedora.
 
I've prepared it simple and clean to support further discussion, maybe some 
other tool is missing... 

* system-config-netboot
  - very outdated
  - replacements k12linux, cobbler

* system-config-boot
  - at least it needs facelift and it's not very usable at all

* system-config-display
  - xrandr should be used for resolution/dualhead configuration, Gnome & KDE 
have 
    own xrandr based display configuration tool
  - generates xorg.conf - it's not needed anymore (only if someone needs 
    more expert configuration)  

* system-config-network
  - replacement NetworkManager
  - missing IPv6? routing?

* system-config-date
  - Gnome/KDE/XFCE have own datetime configuration tool/module, it's confusing 
than
    which one users should use
  - used in firstboot or anaconda???

* system-config-keyboard
  - used only in Anaconda, let it be standalone?
  - very simple tool, Gnome/KDE have better one

* system-config-httpd
  - old GTK 1 application, should be ported to GTK 2 & PolicyKit

* switchdesk and system-switch-tools?
  - it's possible to switch desktop in GDM/KDM
  - one tool for switching all alternatives?

---

Expect more spam from us regarding cleanup project - we already have s-c-* 
tools reviews, so we will fill bugs soon (with some guidelines on list), 
nearly all s-c-* tools need to be ported to PolicyKit and so on ;-)

Happy system config tools hacking
System Config Cleanup Team

-- 
Jaroslav Řezník <jreznik(a)redhat.com&gt;
Associate Software Engineer - Base Operating Systems Brno

Office: [phone]
Mobile: [phone]
Red Hat, Inc.                               http://cz.redhat.com/

[Arthur Pemberton]

On Tue, Mar 24, 2009 at 11:10 AM, Jaroslav Reznik <jreznik(a)redhat.com&gt; wrote:
>  Hi all (interested in system config tools;-).
>  We are working on System Configurations Tools Cleanup Project we need Fedora
>  community opinion on this subject.
>
>  Some s-c-* tools are now very outdated, some are replaced with better
>  solution, some are only used in Anaconda etc.
>
>  This is a short list of application that could be eliminated/replaced/enhanced
>  in short/long term from Fedora.
>
>  I've prepared it simple and clean to support further discussion, maybe some
>  other tool is missing... 
I'm going to assume you want all discussion in this thread.

>  * system-config-netboot
>   - very outdated
>   - replacements k12linux, cobbler 
Kill it

>  * system-config-boot
>   - at least it needs facelift and it's not very usable at all 
Think there needs to be some discussion on a UI first and then out it
out there as a task that someone could pickup.

>  * system-config-display
>   - xrandr should be used for resolution/dualhead configuration, Gnome & KDE
>  have
>     own xrandr based display configuration tool
>   - generates xorg.conf - it's not needed anymore (only if someone needs
>     more expert configuration) 
system-config-display hasn't been use other than as an xorg generator
for me for quite a few releases now. And even haven't an xorg.conf no
longer solves my problems. So might as well kill it.


>  * system-config-network
>   - replacement NetworkManager
>   - missing IPv6? routing? 
I don't think NetworkManager is ready yet, at least not ready to
repalce system-config-network. Just setting up LTSP, i needed
system-config-network quite a bit.

>  * system-config-date
>   - Gnome/KDE/XFCE have own datetime configuration tool/module, it's confusing
>  than
>     which one users should use
>   - used in firstboot or anaconda??? 
Assuming it is killed, what happens to firsrtboot?

>  * system-config-keyboard
>   - used only in Anaconda, let it be standalone?
>   - very simple tool, Gnome/KDE have better one 
No opinion.

>  * system-config-httpd
>   - old GTK 1 application, should be ported to GTK 2 & PolicyKit 
Think there needs to be some discussion on a UI first and then out it
out there as a task that someone could pickup.

>  * switchdesk and system-switch-tools?
>   - it's possible to switch desktop in GDM/KDM
>   - one tool for switching all alternatives? 
Can anyone confirm that this still actually works? I seem to remember
it not really working last time I tried it, but I am not sure.

-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )

[Jochen Schmitt]

Jaroslav Reznik schrieb:
>  * switchdesk and system-switch-tools?
>    - it's possible to switch desktop in GDM/KDM
>    - one tool for switching all alternatives?
>     
This tool should be more extensible to allow the usage of other desktop 
environments.
On BZ #488602 I have made an suggestion which allows you to specified 
DESKTOP=LXDE
on /etc/sysconfig/desktop to start LXDE as a desktop environment.

BEst Regards:

Jochen Schmitt

[Muayyad AlSadi]

>  And even haven't an xorg.conf no
>  longer solves my problems. So might as well kill it. 
I needed system-config-display because
  * called by /etc/init.d/livesys-late to provide my livecd with a
xdriver= boot option
  * recover bad hand written xorg.conf
  * recover bad xorg.conf files generated by older versions of
proprietary nvidia drivers

> > * system-config-network
> >  - replacement NetworkManager
> >  - missing IPv6? routing?
>  I don't think NetworkManager is ready yet, at least not ready to
>  repalce system-config-network. Just setting up LTSP, i needed
>  system-config-network quite a bit. 
+1
NM is not ready yet,
for example I could not use it to dial xDSL and pass it my password
..etc. [in F9]

>  * system-config-keyboard
>   - used only in Anaconda, let it be standalone?
>   - very simple tool, Gnome/KDE have better one 
hmmm,
we need a system-wide default
and of course we need to allow users to override

talking about my self, I only rely on system-config-keyboard
because I have several problems with other tools
here is a screenshot

http://up2.m5zn.com/photo/2009/3/20/03/1ytw0m0w5.png/png

[Bill Nottingham]

Muayyad AlSadi (alsadi(a)gmail.com) said: 
>  > And even haven't an xorg.conf no
>  > longer solves my problems. So might as well kill it.
>  
>  I needed system-config-display because
>    * called by /etc/init.d/livesys-late to provide my livecd with a
>  xdriver= boot option 
Should be fixed - file a bug.

>    * recover bad hand written xorg.conf
>    * recover bad xorg.conf files generated by older versions of
>  proprietary nvidia drivers 
Having a separate tool not called anywhere else to solve PEBKAC
sounds wrong.

Bill

[Matthew Woehlke]

Bill Nottingham wrote:
>  Muayyad AlSadi (alsadi(a)gmail.com) said: 
> >   * recover bad hand written xorg.conf
> >   * recover bad xorg.conf files generated by older versions of
> > proprietary nvidia drivers
>  
>  Having a separate tool not called anywhere else to solve PEBKAC
>  sounds wrong. 
How is having a tool to generate sane xorg.conf's "wrong"? If it can 
sanitize and correct bad hand-written configs, even better. (We have 
tools that only do half of that, i.e. only point out the errors... their 
names tend to end in "lint".)

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
  ,= ,-_-. =.    Freedom to Use
((_/)o o(\_))  Freedom to Examine
  `-'(. .)`-'  Freedom to Share
      \_/     Freedom to Improve

[Bill Nottingham]

Matthew Woehlke (mw_triad(a)users.sourceforge.net) said: 
>  How is having a tool to generate sane xorg.conf's
> "wrong"? 
Xorg -configure

Bill

[Matthew Woehlke]

Bill Nottingham wrote:
>  Matthew Woehlke (mw_triad(a)users.sourceforge.net) said: 
> > How is having a tool to generate sane xorg.conf's "wrong"?
>  
>  Xorg -configure 
...which doesn't clean up existing xorg.conf and doesn't have the 
helpful 'you need to be root' dialog (and doesn't let you make even 
basic changes in a GUI)? How is that better?

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
  ,= ,-_-. =.    Freedom to Use
((_/)o o(\_))  Freedom to Examine
  `-'(. .)`-'  Freedom to Share
      \_/     Freedom to Improve

[Bill Nottingham]

Matthew Woehlke (mw_triad(a)users.sourceforge.net) said: 
>  Bill Nottingham wrote:
> > Matthew Woehlke (mw_triad(a)users.sourceforge.net) said: 
> >> How is having a tool to generate sane xorg.conf's "wrong"?
> >
> > Xorg -configure
>
>  ...which doesn't clean up existing xorg.conf and doesn't have the  
>  helpful 'you need to be root' dialog (and doesn't let you make even  
>  basic changes in a GUI)? How is that better? 
It's a tool that generates a sane xorg.conf. If that is the goal,
I think it's a better place to start than with a large barely-maintained
graphical framework.

Bill

[Jaroslav Reznik]

----- "Bill Nottingham" <notting(a)redhat.com&gt; wrote:

>  Matthew Woehlke (mw_triad(a)users.sourceforge.net) said: 
>  > Bill Nottingham wrote:
>  >> Matthew Woehlke (mw_triad(a)users.sourceforge.net) said: 
>  >>> How is having a tool to generate sane xorg.conf's "wrong"?
>  >>
>  >> Xorg -configure
>  >
>  > ...which doesn't clean up existing xorg.conf and doesn't have the  
>  > helpful 'you need to be root' dialog (and doesn't let you make even 
>  
>  > basic changes in a GUI)? How is that better?
>  
>  It's a tool that generates a sane xorg.conf. If that is the goal,
>  I think it's a better place to start than with a large
>  barely-maintained
>  graphical framework. 
Exactly what I think about it. Better to start from clean ground.
When someone needs custom xorg.conf, he must know what he's doing
so tool that does nothing (only generating template) is useless.

Jaroslav

>  Bill
>  
>  -- 
>  fedora-devel-list mailing list
>  fedora-devel-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Michael Cronenworth]

-------- Original Message --------
Subject: Re: System Config Tools Cleanup Project - tools to 
eliminate/replace
From: Bill Nottingham <notting(a)redhat.com&gt;
To: Development discussions related to Fedora <fedora-devel-list(a)redhat.com&gt;
Date: 03/24/2009 03:06 PM

>  
>  It's a tool that generates a sane xorg.conf. If that is the goal,
>  I think it's a better place to start than with a large barely-maintained
>  graphical framework.
>   
Unfortunately it's not a 100% guarantee to get a "sane" xorg.conf. The 
default for resolutions in X have been to try the maximum possible by 
the monitor, but this may not work well with the selected video card 
driver. Example: mga driver with a G450 and any size LCD monitor will 
not work above 800x600. I had to switch to the "vesa" driver to get a 
working X.

There needs to be better configuration keeping. X should first see if 
there is an xorg.conf. If there is one, it should see if the driver 
matches the currently installed card. If it does, it tries to start X. 
If the card and driver do not match, X should ignore the xorg.conf by 
default with the possiblity of a "Force" option. As for resolutions, 
without an xorg.conf, X should try the highest available, but fallback 
to a lower resolution if a user hasn't clicked on an "OK" button, etc. 
after a set amount of time.

All of this should be exposed to user-space so that X does not have to 
be run as root and the xorg.conf could be configured by GDM (KDM, etc) 
and/or the user via PolicyKit. This should also allow for use of GTK+ or 
QT for configuration widgets. The last thing a new user should see is a 
raw Xt window.

The "rm -f xorg.conf" policy is a good one in nature, but there will 
always be a need for static configuration. It seems the same dynamic 
configuration policy was on the minds of NetworkManager developers at 
the start, which has caused more trouble than good. Ajax should still 
continue work on making X hot-pluggable, hot-switchable, and more 
dynamic, but a static configuration policy should not be forgotten.

tldr;

[Jeremy Katz]

On Tuesday, March 24 2009, Bill Nottingham said:
>  Muayyad AlSadi (alsadi(a)gmail.com) said: 
>  > > And even haven't an xorg.conf no
>  > > longer solves my problems. So might as well kill it.
>  > 
>  > I needed system-config-display because
>  >   * called by /etc/init.d/livesys-late to provide my livecd with a
>  > xdriver= boot option
>  
>  Should be fixed - file a bug. 
ajax was talking about having the xserver do this automatically... not
sure if he got around to it or not

Jeremy

[Matej Cepl]

On 2009-03-24, 17:15 GMT, Muayyad AlSadi wrote:
>    * recover bad hand written xorg.conf
>    * recover bad xorg.conf files generated by older versions of
>  proprietary nvidia drivers 
rm -fv /etc/X11/xorg.conf 

is pretty good one for both of these (hint: it SHOULD work 
without any xorg.conf, if not file a bug).

Matěj

[Bill Nottingham]

Jaroslav Reznik (jreznik(a)redhat.com) said: 
>  * system-config-netboot
>    - very outdated
>    - replacements k12linux, cobbler 
Yes, this needs to die.

>  * system-config-display
>    - xrandr should be used for resolution/dualhead configuration, Gnome & KDE 
>  have 
>      own xrandr based display configuration tool
>    - generates xorg.conf - it's not needed anymore (only if someone needs 
>      more expert configuration)   
This is already not in the default install.

>  * system-config-network
>    - replacement NetworkManager
>    - missing IPv6? routing? 
Which are you referring to 'missing' features in this case?

>  * switchdesk and system-switch-tools?
>    - it's possible to switch desktop in GDM/KDM
>    - one tool for switching all alternatives? 
Yes, I'm not sure why this still is around.

Bill

[Adam Jackson]

On Tue, 2009-03-24 at 13:04 -0400, Bill Nottingham wrote:
>  Jaroslav Reznik (jreznik(a)redhat.com) said: 
>  > * system-config-netboot
>  >   - very outdated
>  >   - replacements k12linux, cobbler
>  
>  Yes, this needs to die.
>  
>  > * system-config-display
>  >   - xrandr should be used for resolution/dualhead configuration, Gnome & KDE 
>  > have 
>  >     own xrandr based display configuration tool
>  >   - generates xorg.conf - it's not needed anymore (only if someone needs 
>  >     more expert configuration)  
>  
>  This is already not in the default install. 
s-c-d is really only useful for multihead across multiple GPUs.  If that
_worked_ in X at the moment.

xorg.conf is still useful (and recommended) for configuring the initial
login screen.

- ajax

[Matthew Woehlke]

Adam Jackson wrote:
>  s-c-d is really only useful for multihead across multiple GPUs.  If
> that
>  _worked_ in X at the moment. 
It works for me, if by "works" you mean "GLX crashes if it's
loaded" 
;-). (But I have three monitors on two cards; one PCIe, and one good-old 
PCI. GL is thoroughly broken, but it's working otherwise.)

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
  ,= ,-_-. =.    Freedom to Use
((_/)o o(\_))  Freedom to Examine
  `-'(. .)`-'  Freedom to Share
      \_/     Freedom to Improve

[Adam Williamson]

On Tue, 2009-03-24 at 13:10 -0500, Matthew Woehlke wrote:
>  Adam Jackson wrote:
>  > s-c-d is really only useful for multihead across multiple GPUs.  If that
>  > _worked_ in X at the moment.
>  
>  It works for me, if by "works" you mean "GLX crashes if it's
> loaded" 
>  ;-). (But I have three monitors on two cards; one PCIe, and one good-old 
>  PCI. GL is thoroughly broken, but it's working otherwise.) 
You're not using an RandR 1.2 driver, are you?

In my experience, multi-card multi-head just ain't working at all with
RandR 1.2 / 1.3. It's not yet capable of handling it. I think that's
what ajax was talking about.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

[Scott Tsai]

Some suggestions:

1. Keep this wiki page up-to-date:
http://fedoraproject.org/wiki/SystemConfig/Tools
It still mentions "pirut" for example.
Add a link to the upstream repositories on fedorahosted.org

2. Consider removing these after loud announcements:
system-config-netboot
system-config-display

3. Only remove system-config-network when Fedora no longer ships the old 
network configuration scripts like /etc/sysconfig/network-scripts/ifup 
and have NetworkManager totally take over.
Even then you might want to keep a "System->Administration->Network" menu

entry but have it start the NetworkManager connection editor.

[Jaroslav Reznik]

On Tuesday 24 March 2009 18:04:52 Scott Tsai wrote:
>  Some suggestions:
>
>  1. Keep this wiki page up-to-date:
>  http://fedoraproject.org/wiki/SystemConfig/Tools
>  It still mentions "pirut" for example.
>  Add a link to the upstream repositories on fedorahosted.org 
I'd like to update it according this "questionaire". And yes, all system 
configs should be hosted on fedorahosted.org.

>  2. Consider removing these after loud announcements:
>  system-config-netboot
>  system-config-display
>
>  3. Only remove system-config-network when Fedora no longer ships the old
>  network configuration scripts like /etc/sysconfig/network-scripts/ifup
>  and have NetworkManager totally take over.
>  Even then you might want to keep a "System->Administration->Network"
> menu
>  entry but have it start the NetworkManager connection editor. 
Seems reasonable to me.

Thanks!

Jaroslav

[Fabian Deutsch]

Am Dienstag, den 24.03.2009, 17:04 +0000 schrieb Scott Tsai:
>  Some suggestions:
>  
>  1. Keep this wiki page up-to-date:
>  http://fedoraproject.org/wiki/SystemConfig/Tools
>  It still mentions "pirut" for example.
>  Add a link to the upstream repositories on fedorahosted.org
>  
>  2. Consider removing these after loud announcements:
>  system-config-netboot
>  system-config-display
>  
>  3. Only remove system-config-network when Fedora no longer ships the old 
>  network configuration scripts like /etc/sysconfig/network-scripts/ifup 
>  and have NetworkManager totally take over.
>  Even then you might want to keep a "System->Administration->Network" menu
>
>  entry but have it start the NetworkManager connection editor. 
What is the long term solution for configuring network settings on
server systems not using NM?

- fabian

[Kevin Kofler]

Fabian Deutsch wrote:
>  What is the long term solution for configuring network settings on
>  server systems not using NM? 
The idea is that "server systems not using NM" will not exist in the "long
term". Instead, they'll use NM with systemwide configuration. NM actually
supports systemwide settings these days, and with those settings it can
connect to the network without requiring a user login.

        Kevin Kofler

[Bill Nottingham]

Scott Tsai (scottt.tw(a)gmail.com) said: 
>  3. Only remove system-config-network when Fedora no longer ships the
> old 
>  network configuration scripts like /etc/sysconfig/network-scripts/ifup 
>  and have NetworkManager totally take over. 
NetworkManager's connection editor will (soon) be able to
write to those files. Even if NM isn't in use, if it's
writing the same data, to the same files, while being
actually maintained more... I don't see why s-c-network
would stay around.

Bill

[Ralf Corsepius]

Bill Nottingham wrote:
>  Scott Tsai (scottt.tw(a)gmail.com) said: 
> > 3. Only remove system-config-network when Fedora no longer ships the old 
> > network configuration scripts like /etc/sysconfig/network-scripts/ifup 
> > and have NetworkManager totally take over.
>  
>  NetworkManager's connection editor will (soon) be able to
>  write to those files. Even if NM isn't in use, if it's
>  writing the same data, to the same files, while being
>  actually maintained more... I don't see why s-c-network
>  would stay around. 
Well, I regret having to say so, but unless NetworkManager has seen 
_very_ substantial improvements since FC10, I feel your rationale is 
wishful thinking.

Actually, I feel s-c-network should be revived and NetworkManager be 
made strictly optional.

[Matthew Woehlke]

Ralf Corsepius wrote:
>  Actually, I feel s-c-network should be revived and NetworkManager be
>
>  made strictly optional. 
I'd actually have to disagree. I *love* NM on my Asus (netbook). It's 
great for laptops (or other computers that tend to move around and need 
to deal with "foreign" networks, especially wireless networks), and it's 
"okay" for desktops. (For one, it handles Verizon CDMA modems out of the 
box, much better even that on Windoze, which is why I'd much rather use 
NM when dealing with one of those.) However, it's not yet up-to-snuff 
(and possibly inferior) for servers or other "complicated" network 
setups, and it's maybe at "break even" for static setups.

I think we /should/ be pushing NM for "normal" use so it gets exposure 
and improves, but I agree that s-c-n and the if-scripts toolchains need 
to be maintained (at least for now) as they are still superior for some 
situations.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
  ,= ,-_-. =.    Freedom to Use
((_/)o o(\_))  Freedom to Examine
  `-'(. .)`-'  Freedom to Share
      \_/     Freedom to Improve

[Ralf Corsepius]

Matthew Woehlke wrote:
>  Ralf Corsepius wrote:
> > Actually, I feel s-c-network should be revived and NetworkManager be 
> > made strictly optional.
>  
>  I'd actually have to disagree. I *love* NM on my Asus (netbook).
Congratulations.

For me,
- NM doesn't work on any machine w/ WLAN
- NM is just bloated ballast on machines w/o WLAN


>   It's
>  great for laptops (or other computers that tend to move around and need 
>  to deal with "foreign" networks, 
Seemingly it's sufficiently
functional for some people in such 
situation. I don't have such demands.

>  especially wireless networks), and it's 
>  "okay" for desktops.  
Yes, it works "sufficiently" on my
desktops, but ... at which price?
... Instability caused by silly "dark magic",
... no cli
... no network profiles
... bloat



(For one, it handles Verizon CDMA modems out of the
>  box, much better even that on Windoze, which is why I'd much
> rather use 
>  NM when dealing with one of those.) However, it's not yet up-to-snuff 
>  (and possibly inferior) for servers or other "complicated" network 
>  setups, and it's maybe at "break even" for static setups. 
My network
isn't compliated (static IPs, static topologic, yp based 
autofs, DHCP).

It's just that NM can't handle it properly.


Ralf

[Arthur Pemberton]

On Tue, Mar 24, 2009 at 10:00 PM, Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  Matthew Woehlke wrote:
> >
> > Ralf Corsepius wrote:
> >>
> >> Actually, I feel s-c-network should be revived and NetworkManager be made
> >> strictly optional.
> >
> > I'd actually have to disagree. I *love* NM on my Asus (netbook).
>
>  Congratulations.
>
>  For me,
>  - NM doesn't work on any machine w/ WLAN
>  - NM is just bloated ballast on machines w/o WLAN 
I believe you are in a very small minority with that view.

> >  It's
> >
> > great for laptops (or other computers that tend to move around and need to
> > deal with "foreign" networks,
>
>  Seemingly it's sufficiently functional for some people in such situation. I
>  don't have such demands. 
It's more than functional for most people in most situations.

> > especially wireless networks), and it's "okay" for
> desktops.
>
>  Yes, it works "sufficiently" on my desktops, but ... at which price?
>  ... Instability caused by silly "dark magic", 
Oh please.

>  ... no cli
>  ... no network profiles 
Both valid concerns.

>  ... bloat 
Made up over used word thrown around as as a subject non specific
critic of any software someone doesn't like

>  My network isn't compliated (static IPs, static topologic, yp
> based autofs,
>  DHCP).
>  It's just that NM can't handle it properly. 
Since I've been told that NM can handle static IPs now, i don't see
why any of the above would be a problem.

-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )

[Ralf Corsepius]

Arthur Pemberton wrote:
>  On Tue, Mar 24, 2009 at 10:00 PM, Ralf Corsepius
> <rc040203(a)freenet.de&gt; wrote:
> > Matthew Woehlke wrote:
> >> Ralf Corsepius wrote:
> >>> Actually, I feel s-c-network should be revived and NetworkManager be made
> >>> strictly optional.
> >> I'd actually have to disagree. I *love* NM on my Asus (netbook).
> > Congratulations.
> >
> > For me,
> > - NM doesn't work on any machine w/ WLAN
> > - NM is just bloated ballast on machines w/o WLAN
>  
>  I believe you are in a very small minority with that view. 
Please stop using this
ole bolshevist argument. Just because you don't 
see a problem doesn't mean there isn't a problem.

> >>  It's
> >>
> >> great for laptops (or other computers that tend to move around and need to
> >> deal with "foreign" networks,
> > Seemingly it's sufficiently functional for some people in such situation. I
> > don't have such demands.
>  
>  It's more than functional for most people in most situations.
>  
> >> especially wireless networks), and it's "okay" for desktops.
> > Yes, it works "sufficiently" on my desktops, but ... at which price?
> > ... Instability caused by silly "dark magic",
>  
>  Oh please. 
... Yes, NM is responsible for pulling in dozens of unnecessary 
daemons/services.

> > ... no cli
> > ... no network profiles
>  
>  Both valid concerns. 
IMO, both hard show stoppers, disqualifying NM from being branded a 
replacement for s-c-networking.

> > ... bloat
>  
>  Made up over used word thrown around as as a subject non specific
>  critic of any software someone doesn't like 
Do yourself a favor and check how
much bloat (and potential sources 
errors and vulnerabilities) NM pulls in.

In case you haven't noticed yet: In comparison to s-c-networking, this 
list is very long.

> > My network isn't compliated (static IPs, static topologic, yp
> based autofs,
> > DHCP).
> > It's just that NM can't handle it properly.
>  
>  Since I've been told that NM can handle static IPs now, i don't see
>  why any of the above would be a problem. 
"told" is the key word ...
reality speaks a different language.

The problem with it: Due to NM's black magic and the huge set of 
services it is trying to interact with, it's very difficult to identify 
the origin of problems.

One prominent and well-known case many people have complained about:
NM's way of dns handling.

Ralf

[Suren Karapetyan]

Arthur Pemberton wrote:
>  On Tue, Mar 24, 2009 at 10:00 PM, Ralf Corsepius
> <rc040203(a)freenet.de&gt; wrote:
>    
> > Matthew Woehlke wrote:
> >     
> >> Ralf Corsepius wrote:
> >>       
> >>> Actually, I feel s-c-network should be revived and NetworkManager be made
> >>> strictly optional.
> >>>         
> >> I'd actually have to disagree. I *love* NM on my Asus (netbook).
> >>       
> > Congratulations.
> >
> > For me,
> > - NM doesn't work on any machine w/ WLAN
> > - NM is just bloated ballast on machines w/o WLAN
> >     
>
>  I believe you are in a very small minority with that view.
>
>    
> >>  It's
> >>
> >> great for laptops (or other computers that tend to move around and need to
> >> deal with "foreign" networks,
> >>       
> > Seemingly it's sufficiently functional for some people in such situation. I
> > don't have such demands.
> >     
>
>  It's more than functional for most people in most situations.
>
>    
> >> especially wireless networks), and it's "okay" for desktops.
> >>       
> > Yes, it works "sufficiently" on my desktops, but ... at which price?
> > ... Instability caused by silly "dark magic",
> >     
>
>  Oh please.
>
>    
> > ... no cli
> > ... no network profiles
> >     
>
>  Both valid concerns.
>
>    
> > ... bloat
> >     
>
>  Made up over used word thrown around as as a subject non specific
>  critic of any software someone doesn't like
>     
Come on... :)
A full-fledged daemon running all the time sitting on the system bus
waking up every few seconds (to eat CPU) which is going to do

ifconfig eth0 111.111.111.111/24 up
ip route add default via 111.111.111.222
echo "nameserver 111.111.111.123" > /etc/resolv.conf

And do it only *once* every reboot (which can easily be 30+ days).

This makes sense neither for servers nor for desktops.
It's useful for laptops which travel a lot (not even all laptops, cause 
many of them are used as desktop-replacements).

What I'm asking for is to allow free choice, cause , you know, there is 
no such thing as "one true way",
i.e. what is the only way in one situation may be completely useless and 
even stupid in another.
>    
> > My network isn't compliated (static IPs, static topologic, yp based autofs,
> > DHCP).
> > It's just that NM can't handle it properly.
> >     
>
>  Since I've been told that NM can handle static IPs now, i don't see
>  why any of the above would be a problem.
>
>

[Arthur Pemberton]

On Wed, Mar 25, 2009 at 1:37 AM, Suren Karapetyan
<surenkarapetyan(a)gmail.com&gt; wrote:
>  Arthur Pemberton wrote:
>  Come on... :)
>  A full-fledged daemon running all the time sitting on the system bus
>  waking up every few seconds (to eat CPU) which is going to do 
What exactly is a full-fledged daemon tha makes it bad things for
servers or desktops? What amount of your CPU is it using that it is
such a bad thing.

>  ifconfig eth0 111.111.111.111/24 up
>  ip route add default via 111.111.111.222
>  echo "nameserver 111.111.111.123" > /etc/resolv.conf
>
>  And do it only *once* every reboot (which can easily be 30+ days).
>
>  This makes sense neither for servers nor for desktops. 
Look, if you have a simple setup fine. I am all for everyone having
their choice. But taking the tone that it is some bad thing or a waste
of time is ridiculous. It makes sense on desktops unless they have a
connection that cannot ever be severed, and do not use VPNs.

>  It's useful for laptops which travel a lot (not even all laptops,
> cause many
>  of them are used as desktop-replacements). 
It's useful for desktops as well.

>  What I'm asking for is to allow free choice, cause , you know,
> there is no
>  such thing as "one true way",
>  i.e. what is the only way in one situation may be completely useless and
>  even stupid in another. 
What's the point of asking for that when you can already turn
NetworkManager off. If NetworkManager fills all the role provided by
s-c-network, there's no point in having two ways to do the same thing.
I started off by saying that there are several things that
NetworkManager doesn't do yet so s-c-network shouldn't be removed yet.

Some of these things bring change and seem to make some people overly
nervous, as long you can do things the old way, try not to block
change that is useful to everyone else.  It's just like PulseAudio, it
helps a lot of people, but it works terribly for me, so I just removed
it. No need to go complaining about its existence.

-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )

[Bill Crawford]

On Wednesday 25 March 2009 06:56:08 Arthur Pemberton wrote:

>  What's the point of asking for that when you can already turn
>  NetworkManager off. If NetworkManager fills all the role provided by
>  s-c-network, there's no point in having two ways to do the same thing.
>  I started off by saying that there are several things that
>  NetworkManager doesn't do yet so s-c-network shouldn't be removed yet. 
The worry is that the "NM can replace this" argument is heading towards removal

of the "old" way of doing things, and for a few people that's annoying. It
is 
not a true replacement; it does very different things.

>  Some of these things bring change and seem to make some people
> overly
>  nervous, as long you can do things the old way, try not to block
>  change that is useful to everyone else.  It's just like PulseAudio, it
>  helps a lot of people, but it works terribly for me, so I just removed
>  it. No need to go complaining about its existence. 
We're not "complaining about its existence" we are objecting to it being
forced 
as a "replacement" in all situations, even though it a) doesn't really
support 
all those situations, and b) is unnecessary in at least some of them.

No one is "blocking change that is useful to everyone else", some people object

to having this change forced on them ...

The "it still works" argument is disingenuous when the NM solution is being 
touted as a complete replacement for the "old" way, ... we're not stupid, we

know the plan is to remove the "old" way of doing things completely. Some of us

think this should be postponed until NM can *actually* be a replacement, and I 
for one would like it if NM would "get out of the way" ... I have a single 
wired ethernet connection on this machine, and no matter how much RAM I have, 
using some of it semi-permanently to support NM in the background is a waste.

Not saying you shouldn't have your NM, just want to be sure I won't be forced to 
use it :o)

[Adam Williamson]

On Wed, 2009-03-25 at 12:17 +0000, Bill Crawford wrote:
>  On Wednesday 25 March 2009 06:56:08 Arthur Pemberton wrote:
>  
>  > What's the point of asking for that when you can already turn
>  > NetworkManager off. If NetworkManager fills all the role provided by
>  > s-c-network, there's no point in having two ways to do the same thing.
>  > I started off by saying that there are several things that
>  > NetworkManager doesn't do yet so s-c-network shouldn't be removed yet.
>  
>  The worry is that the "NM can replace this" argument is heading towards removal
>
>  of the "old" way of doing things, and for a few people that's annoying. It
> is 
>  not a true replacement; it does very different things.
>  
>  > Some of these things bring change and seem to make some people overly
>  > nervous, as long you can do things the old way, try not to block
>  > change that is useful to everyone else.  It's just like PulseAudio, it
>  > helps a lot of people, but it works terribly for me, so I just removed
>  > it. No need to go complaining about its existence.
>  
>  We're not "complaining about its existence" we are objecting to it being
> forced 
>  as a "replacement" in all situations, even though it a) doesn't really
> support 
>  all those situations, and b) is unnecessary in at least some of them.
>  
>  No one is "blocking change that is useful to everyone else", some people object
>
>  to having this change forced on them ...
>  
>  The "it still works" argument is disingenuous when the NM solution is being 
>  touted as a complete replacement for the "old" way, ... we're not stupid,
> we 
>  know the plan is to remove the "old" way of doing things completely. Some of us
>
>  think this should be postponed until NM can *actually* be a replacement, and I 
>  for one would like it if NM would "get out of the way" ... I have a single 
>  wired ethernet connection on this machine, and no matter how much RAM I have, 
>  using some of it semi-permanently to support NM in the background is a waste.
>  
>  Not saying you shouldn't have your NM, just want to be sure I won't be forced to
>
>  use it :o) 
I think there's some heat being generated here due to the fact that
'NetworkManager' is not a suitably specific term :)

> From the discussion it appears that the 'Edit Connections'
> tool in 
NetworkManager (nm-connection-editor) can perform some configuration
tasks even if you are not actually using the NetworkManager daemon -
i.e. it can configure the 'old school' /etc/sysconfig files. This is the
sense in which NetworkManager can 'replace' s-c-n, I believe.

So what's really important is: what can s-c-n configure in
the /etc/sysconfig system than nm-connection-editor cannot? All the
(useful) functions in s-c-n have to be available in nm-connection-editor
before s-c-n can safely be dropped. That's the real issue, I think.

I don't think anyone is proposing dropping the support for the 'network'
service and /etc/sysconfig configuration files, so it's not really
useful to discuss whether that's a good idea or not, since it isn't
happening.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

[Suren Karapetyan]

On Wednesday 25 March 2009 10:56:08 Arthur Pemberton wrote:
>  On Wed, Mar 25, 2009 at 1:37 AM, Suren Karapetyan
>
>  <surenkarapetyan(a)gmail.com&gt; wrote:
>  > Arthur Pemberton wrote:
>  > Come on... :)
>  > A full-fledged daemon running all the time sitting on the system bus
>  > waking up every few seconds (to eat CPU) which is going to do
>
>  What exactly is a full-fledged daemon tha makes it bad things for
>  servers or desktops? What amount of your CPU is it using that it is
>  such a bad thing. 
 2045 root      20   0 69236 2456 1920 S  0.0  0.1   0:01.98 NetworkManager               
                                                                  
 2058 root      20   0 74152 3964 3336 S  0.0  0.1   0:00.06 nm-system-setti
NetworkManager wakes up every second and does a new poll syscall with 3 second 
timeout.
6MB of RAM, 15 open fds and 1/3 wakeup/s to do network management on a laptop 
which travels once it day is O.K.
6MB of RAM, 15 open fds  and 1/3 wakeup/s to do absolutely nothing (e.g. 
server :) ) is bad.
Of course it doesn't use much, and I'm sure it can be made to use even less.
But there is no point in using any CPU/RAM/HDD at all if it isn't going to do 
you any good.

>  > ifconfig eth0 111.111.111.111/24 up
>  > ip route add default via 111.111.111.222
>  > echo "nameserver 111.111.111.123" > /etc/resolv.conf
>  >
>  > And do it only *once* every reboot (which can easily be 30+ days).
>  >
>  > This makes sense neither for servers nor for desktops.
>
>  Look, if you have a simple setup fine. I am all for everyone having
>  their choice. But taking the tone that it is some bad thing or a waste
>  of time is ridiculous. It makes sense on desktops unless they have a
>  connection that cannot ever be severed, and do not use VPNs. 
I'm also for everyone having their free choice and that's my main point.
And I'm not saying that it's useless, I'm saying that sometimes it useless.

>  > It's useful for laptops which travel a lot (not even all laptops, cause
>  > many of them are used as desktop-replacements).
>
>  It's useful for desktops as well. 
The main part of it which is useful (and is different from simple script which 
runs dhclient) for desktop (with single connection) IMO is detecting if there 
is internet connection.
Do I miss something big here.

>  > What I'm asking for is to allow free choice, cause , you know, there is
>  > no such thing as "one true way",
>  > i.e. what is the only way in one situation may be completely useless and
>  > even stupid in another.
>
>  What's the point of asking for that when you can already turn
>  NetworkManager off. If NetworkManager fills all the role provided by
>  s-c-network, there's no point in having two ways to do the same thing.
>  I started off by saying that there are several things that
>  NetworkManager doesn't do yet so s-c-network shouldn't be removed yet. 
What exactly are we talking about?
Is it just NetworkManager/s-c-network, or does /etc/init.d/network have 
something to do with this too?

I'm almost sure it's the latter.
If NM will be able to read /etc/sysconfig/network-scripts/ifcgf-*, do ifcfg/ip 
route stuff and quit I'll agree that it can replace s-c-network.
But I'm sure it won't, cause we already have a program/script which does 
that... and there is no need to create a new one for the same job.


>  Some of these things bring change and seem to make some people overly
>  nervous, as long you can do things the old way, try not to block
>  change that is useful to everyone else.  It's just like PulseAudio, it
>  helps a lot of people, but it works terribly for me, so I just removed
>  it. No need to go complaining about its existence. 
I'm not trying to block changes (and I'm sure I can't) but it looks like 
others are trying to block the "old way". I use NetworkManager myself on my 
laptop, but I don't use it on my desktop, cause
a) It *never* changes networks
b) It bridges eth and wlan together.

And about PulseAudio :)
I have the same problems with it as You do.
It creates a lot of sound skipping/stopping/hanging and games not playing 
problems for me. It doesn't work at all on my laptop, but with F10 (and 
updates :) ) it became bearable on my desktop. So I'm using it (at least 
trying to) there. But even if it starts to work ideally on every machine I 
use, I still want to be able to use bare ALSA when I want so.

>  --
>  Fedora 9 : sulphur is good for the skin
>  ( www.pembo13.com )

[Muayyad AlSadi]

> >   * recover bad hand written xorg.conf
> >   * recover bad xorg.conf files generated by older versions of
> > proprietary nvidia drivers 
>  rm -fv /etc/X11/xorg.conf 
I already did

https://bugzilla.redhat.com/show_bug.cgi?id=465634

another one was with a brother who needed to pass some option to make
cursors appear [it was an S3 Chrom VGA card] he needs xorg.conf file
to save add this option

another case when I don't like 190000x160000 default resolution
and I want a smooth entry from GDM, so I set both to the same resolution

[Christoph Wickert]

Am Mittwoch, den 25.03.2009, 01:56 -0500 schrieb Arthur Pemberton:

>  
>  > It's useful for laptops which travel a lot (not even all laptops, cause many
>  > of them are used as desktop-replacements).
>  
>  It's useful for desktops as well. 
If your desktop is connected to the internet via ethernet, what is the
use of NetworkManager? Or if the desktop is not connected to the
internet at all, what's it's use?

Regards,
Christoph

[Jesse Keating]

On Wed, 2009-03-25 at 18:09 +0100, Christoph Wickert wrote:
>  
>  If your desktop is connected to the internet via ethernet, what is the
>  use of NetworkManager? Or if the desktop is not connected to the
>  internet at all, what's it's use? 

Even when using Ethernet, I find it useful for initiating a VPN
connection when I need it, or re-initiating a connection when the vpn
drops for whatever reason.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

[Christoph Wickert]

Am Mittwoch, den 25.03.2009, 10:32 -0700 schrieb Jesse Keating:
>  On Wed, 2009-03-25 at 18:09 +0100, Christoph Wickert wrote:
>  > 
>  > If your desktop is connected to the internet via ethernet, what is the
>  > use of NetworkManager? Or if the desktop is not connected to the
>  > internet at all, what's it's use?
>  
>  
>  Even when using Ethernet, I find it useful for initiating a VPN
>  connection when I need it, or re-initiating a connection when the vpn
>  drops for whatever reason. 
Agreed, but how many of our users are using VPN? 2%? 5%?

Regards,
Christoph

[Arthur Pemberton]

On Wed, Mar 25, 2009 at 12:50 PM, Christoph Wickert
<christoph.wickert(a)googlemail.com&gt; wrote:
>  Am Mittwoch, den 25.03.2009, 10:32 -0700 schrieb Jesse Keating:
> > On Wed, 2009-03-25 at 18:09 +0100, Christoph Wickert wrote:
> > >
> > > If your desktop is connected to the internet via ethernet, what is the
> > > use of NetworkManager? Or if the desktop is not connected to the
> > > internet at all, what's it's use?
> >
> >
> > Even when using Ethernet, I find it useful for initiating a VPN
> > connection when I need it, or re-initiating a connection when the vpn
> > drops for whatever reason.
>
>  Agreed, but how many of our users are using VPN? 2%? 5%?
>
>  Regards,
>  Christoph 
Possibly, but why make it hard for those 2% plus those that
plug/unplug their desktop/routers., plus those with laptop, all
because some guys don't want NM tickling their kernels every minute?


-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )

[Bill Crawford]

On Wednesday 25 March 2009 20:07:45 Arthur Pemberton wrote:
>  On Wed, Mar 25, 2009 at 12:50 PM, Christoph Wickert
>
>  <christoph.wickert(a)googlemail.com&gt; wrote:
>  > Am Mittwoch, den 25.03.2009, 10:32 -0700 schrieb Jesse Keating:
>  >> On Wed, 2009-03-25 at 18:09 +0100, Christoph Wickert wrote:
>  >> > If your desktop is connected to the internet via ethernet, what is the
>  >> > use of NetworkManager? Or if the desktop is not connected to the
>  >> > internet at all, what's it's use?
>  >>
>  >> Even when using Ethernet, I find it useful for initiating a VPN
>  >> connection when I need it, or re-initiating a connection when the vpn
>  >> drops for whatever reason.
>  >
>  > Agreed, but how many of our users are using VPN? 2%? 5%?
>  >
>  > Regards,
>  > Christoph
>
>  Possibly, but why make it hard for those 2% plus those that
>  plug/unplug their desktop/routers., plus those with laptop, all
>  because some guys don't want NM tickling their kernels every minute? 
Noone is saying that.

I suspect some people might be thinking "why affect the 98% for the benefit of a 
handful of people who, if they are using a VPN, could probably manage to click 
on a button in an applet, or launch a command from a menu, or type something in 
order to bring up the VPN?" ...

I'd love to see an applet that let you go "hey, please start this
interface". 
Oh, wait, we used to have one ...

[Matthew Woehlke]

Arthur Pemberton wrote:
>  Possibly, but why make it hard for those 2% plus those that
>  plug/unplug their desktop/routers., plus those with laptop, all
>  because some guys don't want NM tickling their kernels every minute? 
Two words: battery life. (Or if you prefer, "power consumption". Useless 
process eating CPU are *bad*.)

Of course, the irony is that NM is most useful for the same systems 
where power consumption is of most concern :-).

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"Yoda of Borg am I. Futile is resistance. Assimilate you, I will."
   -- from http://en.wikipedia.org/wiki/Wikipedia:Yet_more_Best_of_BJAODN

[Matthew Garrett]

On Wed, Mar 25, 2009 at 03:28:16PM -0500, Matthew Woehlke wrote:

>  Of course, the irony is that NM is most useful for the same systems 
>  where power consumption is of most concern :-). 
Waking up once a minute has an insignificant impact on power 
consumption. Sure, it'd be nice if it could be avoided, but it's really 
not that important.

-- 
Matthew Garrett | mjg59(a)srcf.ucam.org

[Chris Adams]

Once upon a time, Matthew Garrett <mjg(a)redhat.com&gt; said:
>  Waking up once a minute has an insignificant impact on power 
>  consumption. Sure, it'd be nice if it could be avoided, but it's really 
>  not that important. 
If it were only once per minute, it wouldn't be so bad.  I see a lot
more than that (on F10; I keep crashing rawhide anaconda so I haven't
checked F11-to-be yet).
-- 
Chris Adams <cmadams(a)hiwaay.net&gt;
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

[Matthew Garrett]

On Wed, Mar 25, 2009 at 09:44:46PM -0500, Chris Adams wrote:
>  Once upon a time, Matthew Garrett <mjg(a)redhat.com&gt; said:
>  > Waking up once a minute has an insignificant impact on power 
>  > consumption. Sure, it'd be nice if it could be avoided, but it's really 
>  > not that important.
>  
>  If it were only once per minute, it wouldn't be so bad.  I see a lot
>  more than that (on F10; I keep crashing rawhide anaconda so I haven't
>  checked F11-to-be yet). 
Once you're down below once a second it's pretty much noise, assuming 
everything's using g_timeout_add_seconds.

-- 
Matthew Garrett | mjg59(a)srcf.ucam.org

[Arthur Pemberton]

On Wed, Mar 25, 2009 at 12:09 PM, Christoph Wickert
<christoph.wickert(a)googlemail.com&gt; wrote:
>  Am Mittwoch, den 25.03.2009, 01:56 -0500 schrieb Arthur Pemberton:
>
> >
> > > It's useful for laptops which travel a lot (not even all laptops, cause
> many
> > > of them are used as desktop-replacements).
> >
> > It's useful for desktops as well.
>
>  If your desktop is connected to the internet via ethernet, what is the
>  use of NetworkManager? Or if the desktop is not connected to the
>  internet at all, what's it's use? 

The same reason I first tried NetworkManager and got thoroughly
burned... the base network script don't handle losing and resuming
connections. Listen, I've been burned by NM in its early days, and I
recognize that it isn't ready yet. I just don't support those who say
that NM should be retired.


-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )

[Suren Karapetyan]

Arthur Pemberton wrote:
>  On Wed, Mar 25, 2009 at 12:09 PM, Christoph Wickert
>  <christoph.wickert(a)googlemail.com&gt; wrote:
>    
> > Am Mittwoch, den 25.03.2009, 01:56 -0500 schrieb Arthur Pemberton:
> >
> >     
> >>> It's useful for laptops which travel a lot (not even all laptops, cause
> many
> >>> of them are used as desktop-replacements).
> >>>         
> >> It's useful for desktops as well.
> >>       
> > If your desktop is connected to the internet via ethernet, what is the
> > use of NetworkManager? Or if the desktop is not connected to the
> > internet at all, what's it's use?
> >     
>
>
>  The same reason I first tried NetworkManager and got thoroughly
>  burned... the base network script don't handle losing and resuming
>  connections. Listen, I've been burned by NM in its early days, and I
>  recognize that it isn't ready yet. I just don't support those who say
>  that NM should be retired.
>
>
>     
Look, guys, there is a huge misunderstanding involved in every 
discussion about NM.
Those who "protect" NM try to protect it in every situation. They are 
sure everyone who
wants to use anything except NM want NM dead and buried face down.
 They always say that every
"normal" person's use cases are covered by NM, and if it isn't good for

you - you are stupid,
you're on your own and you should burn in hell, and also you try to 
block changes
which are good for everyone.

And those who "attack" NM (including me :) ) think (and I hope they are 
wrong) that
"the others" (yep.. the ones from ABC's series :) ) are going to force 
them use something,
which they don't want and it is going to cause them a lot of unbearable 
pain...

What I think everyone will agree with is that both NM and 
/etc/init.d/network have cons and pros
and that both have their users. It's also clear that NM's features 
aren't super-set of
"service network"'s and the opposite isn't true too.
I also think there will be no objections if I say:
One should always be able to setup everything he wants with 
ifconfig/iproute2
If You don't agree with it, think about a completely hosed system...
Then do "ldd `which ifconfig`" and "ldd `which NetworkManager`" and 
guess which one
has more chance to die because of a few bad blocks on the HDD.

If we put all this thoughts (which look like facts to me) together we 
get that it's possible
and makes sense to maintain "service network" next to NM *forever*.

I think if we all can agree on the last sentence it will make all the 
future discussions
much more constructive.

[Matej Cepl]

On 2009-03-25, 06:37 GMT, Suren Karapetyan wrote:
>  What I'm asking for is to allow free choice, cause , you know, 
>  there is no such thing as "one true way", 
service NetworkManager stop
chkconfig NetworkManager off
chkconfig network on
service network start

Matěj

[Bill Crawford]

On Wednesday 25 March 2009 09:13:56 Matej Cepl wrote:
>  On 2009-03-25, 06:37 GMT, Suren Karapetyan wrote:
>  > What I'm asking for is to allow free choice, cause , you know,
>  > there is no such thing as "one true way",
>
>  service NetworkManager stop
>  chkconfig NetworkManager off
>  chkconfig network on
>  service network start 
Yes, as long as that continues to be possible :o)

[ in other words, I have no problem with NM existing, although I think it's a 
big monster of complications that needn't be so ]

>  Matěj

[Kevin Fenzi]

On Tue, 24 Mar 2009 14:09:56 -0400
Bill Nottingham <notting(a)redhat.com&gt; wrote:

>  Scott Tsai (scottt.tw(a)gmail.com) said: 
>  > 3. Only remove system-config-network when Fedora no longer ships
>  > the old network configuration scripts
>  > like /etc/sysconfig/network-scripts/ifup and have NetworkManager
>  > totally take over.
>  
>  NetworkManager's connection editor will (soon) be able to
>  write to those files. Even if NM isn't in use, if it's
>  writing the same data, to the same files, while being
>  actually maintained more... I don't see why s-c-network
>  would stay around. 
Here's my short list of things I would like to see implemented before
s-c-network goes away: 

- bridging support in NM 
- command line configuration/management tool for nm
(I would think this could just be a management tool and have some
config file to change config, I don't care which). 

>  
>  Bill
>   
kevin

[Alex Lancaster]

> >>>> "KF" == Kevin Fenzi  writes: 
[...]

KF> Here's my short list of things I would like to see implemented before
KF> s-c-network goes away: 

KF> - command line configuration/management tool for nm
KF> (I would think this could just be a management tool and have some
KF> config file to change config, I don't care which). 

Yes, indeed, I agree this is must have before s-c-network goes away.
Also a way of specifying wireless connections from the command-line
and in text mode (e.g. a server with no GUI).  

A way to select from available wireless ones in some kind of
text-based modes is really needed, although this is currently not
provided by s-c-network.

Alex

[Orion Poplawski]

Alex Lancaster wrote:
> >>>>> "KF" == Kevin Fenzi  writes:
>  
>  [...]
>  
>  KF> Here's my short list of things I would like to see implemented before
>  KF> s-c-network goes away:  
And support for analog ppp dialup:

https://bugzilla.redhat.com/show_bug.cgi?id=486671


-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA/CoRA Division                    FAX: [phone]
3380 Mitchell Lane                  orion(a)cora.nwra.com
Boulder, CO 80301              http://www.cora.nwra.com

[David Lutterkort]

On Tue, 2009-03-24 at 17:04 +0000, Scott Tsai wrote:
>  3. Only remove system-config-network when Fedora no longer ships the
> old 
>  network configuration scripts like /etc/sysconfig/network-scripts/ifup 
>  and have NetworkManager totally take over. 
For system-wide configs, those scritps need to stick around; NM
integration of those will be addressed by using netcf, which
encapsulates all the headaches with what files to change to set up a
bond etc.

David

[Scott Tsai]

On Tue, 24 Mar 2009 18:53:39 +0000, David Lutterkort wrote:
>  For system-wide configs, those scritps need to stick around; NM
>  integration of those will be addressed by using netcf, which
>  encapsulates all the headaches with what files to change to set up a
>  bond etc. 
This implies that unless the traditional network configuration 
initscripts are taught to configure WPA and 3G modems those kind of 
connections could never be system-wide though?

I was hoping that sharing internet connection through a 3G modem "system-
wide" (i.e. from a box where I never login locally) would eventually be 
supported.

[Adam Williamson]

On Tue, 2009-03-24 at 17:10 +0100, Jaroslav Reznik wrote:

>  * system-config-display
>    - xrandr should be used for resolution/dualhead configuration, Gnome & KDE 
>  have 
>      own xrandr based display configuration tool 
Only for RandR 1.2-based drivers, note. Although as of F11 we should be
shipping RandR 1.2 drivers for the three major card types by default for
the first time (radeon, nouveau, intel).

>  * system-config-network
>    - replacement NetworkManager
>    - missing IPv6? routing? 
Quite a lot of people still don't want to use NetworkManager. It makes
little sense on a system which just sits there connected to a static IP
address 24/7.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

[Colin Walters]

On Tue, Mar 24, 2009 at 1:16 PM, Adam Williamson <awilliam(a)redhat.com&gt; wrote:

>  Quite a lot of people still don't want to use NetworkManager. It
> makes
>  little sense on a system which just sits there connected to a static IP
>  address 24/7. 
I think it does because it provides a useful networking API for other
applications to consume.  For example, answering the question "is
there an active network link" was effectively impossible for app
authors before.

Also, in my opinion on a well-managed network if you want a fixed IP
address, the right way to do it is MAC matching on the DHCP server,
not client configuration.  And NetworkManager works well in such a
setup.

[Arthur Pemberton]

On Tue, Mar 24, 2009 at 12:38 PM, Colin Walters <walters(a)verbum.org&gt; wrote:
>  On Tue, Mar 24, 2009 at 1:16 PM, Adam Williamson
> <awilliam(a)redhat.com&gt; wrote: 
[ snip ]
>  Also, in my opinion on a well-managed network if you want a fixed IP
>  address, the right way to do it is MAC matching on the DHCP server,
>  not client configuration.  And NetworkManager works well in such a
>  setup. 

Sometimes you just want to enter an IP address manually. This
shouldn't be considered some extra special case.


-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )

[Jaroslav Reznik]

On Tuesday 24 March 2009 18:43:55 Arthur Pemberton wrote:
>  On Tue, Mar 24, 2009 at 12:38 PM, Colin Walters
> <walters(a)verbum.org&gt; wrote:
>  > On Tue, Mar 24, 2009 at 1:16 PM, Adam Williamson <awilliam(a)redhat.com&gt;
>  > wrote:
>
>  [ snip ]
>
>  > Also, in my opinion on a well-managed network if you want a fixed IP
>  > address, the right way to do it is MAC matching on the DHCP server,
>  > not client configuration.  And NetworkManager works well in such a
>  > setup.
>
>  Sometimes you just want to enter an IP address manually. This
>  shouldn't be considered some extra special case. 
You can enter IP manually in nm-applet too, so it's same (sorry, I've never 
tried it but is seems to be there).

Jaroslav

>  --
>  Fedora 9 : sulphur is good for the skin
>  ( www.pembo13.com )

[Lyos Gemini Norezel]

Arthur Pemberton wrote:
>  On Tue, Mar 24, 2009 at 12:38 PM, Colin Walters
> <walters(a)verbum.org&gt; wrote:
>    
>  Sometimes you just want to enter an IP address manually. This
>  shouldn't be considered some extra special case.
>
>     
(In Gnome)
System -> Administration -> Network
Select network device -> Edit
'General' tab -> 'Statically Set IP Addresses:'

Worked flawlessly for me when I had to use my laptop as a tftp server to 
fix my broken openwrt router.

Lyos Gemini Norezel

[Harald Hoyer]

Lyos Gemini Norezel schrieb:
>  Arthur Pemberton wrote:
> > On Tue, Mar 24, 2009 at 12:38 PM, Colin Walters <walters(a)verbum.org&gt; 
> > wrote:
> >   Sometimes you just want to enter an IP address manually. This
> > shouldn't be considered some extra special case.
> >
> >   
>  (In Gnome)
>  System -> Administration -> Network
>  Select network device -> Edit
>  'General' tab -> 'Statically Set IP Addresses:'
>  
>  Worked flawlessly for me when I had to use my laptop as a tftp server to 
>  fix my broken openwrt router.
>  
>  Lyos Gemini Norezel
>   
this is in fact system-config-network :-)

[Jaroslav Reznik]

On Tuesday 24 March 2009 18:38:40 Colin Walters wrote:
>  On Tue, Mar 24, 2009 at 1:16 PM, Adam Williamson
> <awilliam(a)redhat.com&gt;  
wrote:
>  > Quite a lot of people still don't want to use
> NetworkManager. It makes
>  > little sense on a system which just sits there connected to a static IP
>  > address 24/7.
>
>  I think it does because it provides a useful networking API for other
>  applications to consume.  For example, answering the question "is
>  there an active network link" was effectively impossible for app
>  authors before. 
Yes, this make sense and it's really quite useful - applications know current 
network state. So now we should collect what is still missing in NM and what 
do we really need to have.

>  Also, in my opinion on a well-managed network if you want a fixed IP
>  address, the right way to do it is MAC matching on the DHCP server,
>  not client configuration.  And NetworkManager works well in such a
>  setup. 
+1, but there are still devices that don't allow this (as my ADSL router, I 
can only have random IP, no MAC binding available).

Jaroslav

[Suren Karapetyan]

Colin Walters wrote:
>  On Tue, Mar 24, 2009 at 1:16 PM, Adam Williamson
> <awilliam(a)redhat.com&gt; wrote:
>
>    
> > Quite a lot of people still don't want to use NetworkManager. It makes
> > little sense on a system which just sits there connected to a static IP
> > address 24/7.
> >     
>
>  I think it does because it provides a useful networking API for other
>  applications to consume.  For example, answering the question "is
>  there an active network link" was effectively impossible for app
>  authors before.
>     
I'm not quite sure squid/httpd/dhcpd/samba/... cares about network link.
The programs which check link availability are usually (always?) desktop 
programs.
>  Also, in my opinion on a well-managed network if you want a fixed IP
>  address, the right way to do it is MAC matching on the DHCP server,
>  not client configuration.  And NetworkManager works well in such a
>  setup.
>     
Yes that makes sense for any 10+ workstations network.
But it doesn't make sense for the 2-3 servers which serve that network, 
cause they usually *never* have their ips changed.

So again this makes sense only for desktops (and of course much more 
sense for laptops) but is mostly useless for servers.
And also /etc/init.d/network with dhclient also works quite well in this 
setup.

What I wanted to say is "Removing old ifcfg-style network configuration 
support is wrong".

[Dan Horák]

Colin Walters píše v Út 24. 03. 2009 v 13:38 -0400:
>  On Tue, Mar 24, 2009 at 1:16 PM, Adam Williamson
> <awilliam(a)redhat.com&gt; wrote:
>  
>  > Quite a lot of people still don't want to use NetworkManager. It makes
>  > little sense on a system which just sits there connected to a static IP
>  > address 24/7.
>  
>  I think it does because it provides a useful networking API for other
>  applications to consume.  For example, answering the question "is
>  there an active network link" was effectively impossible for app
>  authors before. 
There are situations when you don't want any reaction on link up/down
events.

>  Also, in my opinion on a well-managed network if you want a fixed IP
>  address, the right way to do it is MAC matching on the DHCP server,
>  not client configuration.  And NetworkManager works well in such a
>  setup. 
It really depends on situation, but staticly assigned IPs (without DHCP)
are usually prefered in server deployments.


		Dan

[Bill Crawford]

On Tuesday 24 March 2009 17:38:40 Colin Walters wrote:

>  Also, in my opinion on a well-managed network if you want a fixed IP
>  address, the right way to do it is MAC matching on the DHCP server,
>  not client configuration.  And NetworkManager works well in such a
>  setup. 
You're entitled to your opinion, but not everyone wants to have to set up DHCP, 
and not everyone wants to have to go their sysadmin and request configuration 
changes to the corporate DHCP server just to change some piece of configuration 
FOR THEIR LOCAL MACHINE with all the annoyance to the sysadmin, timewasting for 
me, and so on.

It used to be nice and simple; you put the DNS server(s) in /etc/resolv.conf or 
in /etc/sysconfig/network-scripts/eth0, you got a network connection when the 
system booted.

It's not always correct to remove the DNS settings from /etc/resolv.conf when 
you shut the machine down; I disabled NM on my rawhide test install because I 
could no longer chroot into it from my older system and run "yum" to update (or

a number of other things) due to "host not found" errors.

NetworkManager may "work" well in some setups; it's just annoying to see it

touted as a panacæa when it plainly isn't handling a lot of nice simple setups 
at all well.

[Bill Crawford]

On Tuesday 24 March 2009 17:38:40 Colin Walters wrote:

>  Also, in my opinion on a well-managed network if you want a fixed IP
>  address, the right way to do it is MAC matching on the DHCP server,
>  not client configuration.  And NetworkManager works well in such a
>  setup. 
What happens when you replace your network card, btw?

[Jonathan Dieter]

On Tue, 2009-03-24 at 18:04 +0000, Bill Crawford wrote:
>  On Tuesday 24 March 2009 17:38:40 Colin Walters wrote:
>  
>  > Also, in my opinion on a well-managed network if you want a fixed IP
>  > address, the right way to do it is MAC matching on the DHCP server,
>  > not client configuration.  And NetworkManager works well in such a
>  > setup.
>  
>  What happens when you replace your network card, btw?
>   
You reassign the IP address to the new MAC address.  I use a script that
allows me to set an IP address and hostname to a MAC address with a
single command (it updates both bind and dhcpd).

At the school I work at, we used to run our network with static (set on
the client side) IP addresses.  A couple of years ago, we made the
switch over to DHCP with the "static" IP address coming from the server,
and it's made life much easier.  We've found that we image/update the
computers far more than we ever change network cards.

Jonathan

[Matthew Woehlke]

Colin Walters wrote:
>  Also, in my opinion on a well-managed network if you want a fixed IP
>  address, the right way to do it is MAC matching on the DHCP server,
>  not client configuration. 
I disagree. I want to be able to configure boxes to match DNS entries 
without also having to fiddle with the DHCP configuration. (Besides, 
what if the NIC goes bad? It's easier to just swap it out and continue 
running the old config on the new hardware than to have to update DHCP.)

In the instance where the machine admins are also the network admins, I 
tend to agree (and in fairness that's how I run my home network), but 
when the machine admins are in a totally separate group (and, for that 
matter, thousands of miles geographically displaced as well) it doesn't 
work so well. (In such cases, it sometimes ends up you have to ask 
people to memorize IP addresses until IT gets around to fixing DNS, 
never mind trying to get them to manage static DHCP leases as well.)

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
  ,= ,-_-. =.    Freedom to Use
((_/)o o(\_))  Freedom to Examine
  `-'(. .)`-'  Freedom to Share
      \_/     Freedom to Improve

[Matthew Woehlke]

Colin Walters wrote:
>  Also, in my opinion on a well-managed network if you want a fixed IP
>  address, the right way to do it is MAC matching on the DHCP server,
>  not client configuration.  And NetworkManager works well in such a
>  setup. 
Aside from the other reasons I mentioned (which I notice Bill Crawford 
echoed), I'd point out that you still need to statically assign the IP 
/for the DHCP server/ ;-).

(Yes I know it was said elsewhere NM is supposed to handle static 
IP's... just pointing out why it *must* be able to do so if you expect 
to use it to replace the if* scripts.)

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
  ,= ,-_-. =.    Freedom to Use
((_/)o o(\_))  Freedom to Examine
  `-'(. .)`-'  Freedom to Share
      \_/     Freedom to Improve

[Tom Diehl]

On Tue, 24 Mar 2009, Colin Walters wrote:

>  On Tue, Mar 24, 2009 at 1:16 PM, Adam Williamson
> <awilliam(a)redhat.com&gt; wrote:
>
> > Quite a lot of people still don't want to use NetworkManager. It makes
> > little sense on a system which just sits there connected to a static IP
> > address 24/7.
>
>  I think it does because it provides a useful networking API for other
>  applications to consume.  For example, answering the question "is
>  there an active network link" was effectively impossible for app
>  authors before.
>
>  Also, in my opinion on a well-managed network if you want a fixed IP
>  address, the right way to do it is MAC matching on the DHCP server,
>  not client configuration.  And NetworkManager works well in such a
>  setup. 
Which I guess is OK if you are not setting up the system with the dhcp server
AND the box you are setting up has X installed. Does NM have a command line
interface? Not that I have seen but I could have missed it.

Regards,

-- 
Tom Diehl		tdiehl(a)rogueind.com		Spamtrap address mtd123(a)rogueind.com

[Chuck Anderson]

On Tue, Mar 24, 2009 at 03:31:09PM -0400, Tom Diehl wrote:
>  On Tue, 24 Mar 2009, Colin Walters wrote:
>
> > On Tue, Mar 24, 2009 at 1:16 PM, Adam Williamson <awilliam(a)redhat.com&gt; wrote:
> >
> >> Quite a lot of people still don't want to use NetworkManager. It makes
> >> little sense on a system which just sits there connected to a static IP
> >> address 24/7.
> >
> > I think it does because it provides a useful networking API for other
> > applications to consume.  For example, answering the question "is
> > there an active network link" was effectively impossible for app
> > authors before.
> >
> > Also, in my opinion on a well-managed network if you want a fixed IP
> > address, the right way to do it is MAC matching on the DHCP server,
> > not client configuration.  And NetworkManager works well in such a
> > setup.
>
>  Which I guess is OK if you are not setting up the system with the dhcp server
>  AND the box you are setting up has X installed. Does NM have a command line
>  interface? Not that I have seen but I could have missed it. 
NM supports static IP addresses configured in 
/etc/sysconfig/network-scripts/ifcfg-ethX, or you could enable the 
keyfile plugin to use INI-like files to specify network configuration.  
If you set ONBOOT=yes, you don't even need to interact with NM in any 
way--it should just work.  If you need to wait for the network before 
continuing the system boot up, set NETWORKWAIT=yes in 
/etc/sysconfig/network.

So basically, the no-X argument isn't convincing to me, because you 
can still do the basic stuff the old non-X way and it works.

However, there is an argument for not getting rid of the old network 
scripts.  The following are supported with network scripts but not NM 
yet:

1. IPv6
2. bridges
3. interface aliases

..and probably more.

[Tom Diehl]

On Tue, 24 Mar 2009, Chuck Anderson wrote:

>  On Tue, Mar 24, 2009 at 03:31:09PM -0400, Tom Diehl wrote:
> > On Tue, 24 Mar 2009, Colin Walters wrote:
> >
> >> On Tue, Mar 24, 2009 at 1:16 PM, Adam Williamson <awilliam(a)redhat.com&gt;
> wrote:
> >>
> >>> Quite a lot of people still don't want to use NetworkManager. It makes
> >>> little sense on a system which just sits there connected to a static IP
> >>> address 24/7.
> >>
> >> I think it does because it provides a useful networking API for other
> >> applications to consume.  For example, answering the question "is
> >> there an active network link" was effectively impossible for app
> >> authors before.
> >>
> >> Also, in my opinion on a well-managed network if you want a fixed IP
> >> address, the right way to do it is MAC matching on the DHCP server,
> >> not client configuration.  And NetworkManager works well in such a
> >> setup.
> >
> > Which I guess is OK if you are not setting up the system with the dhcp server
> > AND the box you are setting up has X installed. Does NM have a command line
> > interface? Not that I have seen but I could have missed it.
>
>  NM supports static IP addresses configured in
>  /etc/sysconfig/network-scripts/ifcfg-ethX, or you could enable the
>  keyfile plugin to use INI-like files to specify network configuration.
>  If you set ONBOOT=yes, you don't even need to interact with NM in any
>  way--it should just work.  If you need to wait for the network before
>  continuing the system boot up, set NETWORKWAIT=yes in
>  /etc/sysconfig/network. 
Well maybe I mis-understood then. I thought 
/etc/sysconfig/network-scripts/ifcfg-ethX was going away. If that is
incorrect then I do not understand what all of the complaining is
about.

>  So basically, the no-X argument isn't convincing to me, because you
>  can still do the basic stuff the old non-X way and it works.
>
>  However, there is an argument for not getting rid of the old network
>  scripts.  The following are supported with network scripts but not NM
>  yet:
>
>  1. IPv6
>  2. bridges
>  3. interface aliases 
But the current scripts in /etc/sysconfig/network-scripts/ do this now
If you say they are not going away then rpm -e NM* and you have what you have
today when you do not install X. Works for me for the last 15 years or so.
I will admit I do like nm on my laptop but NOT on my servers.

Seriously, what am I missing?

Regards,

-- 
Tom Diehl		tdiehl(a)rogueind.com		Spamtrap address mtd123(a)rogueind.com

[Jaroslav Reznik]

On Wednesday 25 March 2009 04:08:11 Tom Diehl wrote:
>  On Tue, 24 Mar 2009, Chuck Anderson wrote:
>  > On Tue, Mar 24, 2009 at 03:31:09PM -0400, Tom Diehl wrote:
>  >> On Tue, 24 Mar 2009, Colin Walters wrote:
>  >>> On Tue, Mar 24, 2009 at 1:16 PM, Adam Williamson <awilliam(a)redhat.com&gt;
>  
wrote:
>  >>>> Quite a lot of people still don't want to use
> NetworkManager. It makes
>  >>>> little sense on a system which just sits there connected to a static
>  >>>> IP address 24/7.
>  >>>
>  >>> I think it does because it provides a useful networking API for other
>  >>> applications to consume.  For example, answering the question "is
>  >>> there an active network link" was effectively impossible for app
>  >>> authors before.
>  >>>
>  >>> Also, in my opinion on a well-managed network if you want a fixed IP
>  >>> address, the right way to do it is MAC matching on the DHCP server,
>  >>> not client configuration.  And NetworkManager works well in such a
>  >>> setup.
>  >>
>  >> Which I guess is OK if you are not setting up the system with the dhcp
>  >> server AND the box you are setting up has X installed. Does NM have a
>  >> command line interface? Not that I have seen but I could have missed it.
>  >
>  > NM supports static IP addresses configured in
>  > /etc/sysconfig/network-scripts/ifcfg-ethX, or you could enable the
>  > keyfile plugin to use INI-like files to specify network configuration.
>  > If you set ONBOOT=yes, you don't even need to interact with NM in any
>  > way--it should just work.  If you need to wait for the network before
>  > continuing the system boot up, set NETWORKWAIT=yes in
>  > /etc/sysconfig/network.
>
>  Well maybe I mis-understood then. I thought
>  /etc/sysconfig/network-scripts/ifcfg-ethX was going away. If that is
>  incorrect then I do not understand what all of the complaining is
>  about. 
Network-scripts are part of initscripts, s-c-n is only TUI/GUI configuration 
tool. So these scripts stays until something better is designed (I'm not sure 
how netcf - mentioned in this thread - works).

If we have another tool that's able to edit configuration and use network-
scripts then it's nonsense to have both doing same. So now the question is 
what's missing in NM edit connections (not in standalone NM) and if it is 
worth to add it there or let it alone in s-c-n or only let possibility to do 
it manually (and for servers it's my preferred way to have control over 
configuration).

Jaroslav 

>  > So basically, the no-X argument isn't convincing to me,
> because you
>  > can still do the basic stuff the old non-X way and it works.
>  >
>  > However, there is an argument for not getting rid of the old network
>  > scripts.  The following are supported with network scripts but not NM
>  > yet:
>  >
>  > 1. IPv6
>  > 2. bridges
>  > 3. interface aliases
>
>  But the current scripts in /etc/sysconfig/network-scripts/ do this now
>  If you say they are not going away then rpm -e NM* and you have what you
>  have today when you do not install X. Works for me for the last 15 years or
>  so. I will admit I do like nm on my laptop but NOT on my servers.
>
>  Seriously, what am I missing?
>
>  Regards,
>
>  --
>  Tom Diehl		tdiehl(a)rogueind.com		Spamtrap address mtd123(a)rogueind.com 
-- 
Jaroslav Řezník <jreznik(a)redhat.com&gt;
Associate Software Engineer - Base Operating Systems Brno

Office: [phone]
Mobile: [phone]
Red Hat, Inc.                               http://cz.redhat.com/

[Dan Williams]

On Tue, 2009-03-24 at 10:16 -0700, Adam Williamson wrote:
>  On Tue, 2009-03-24 at 17:10 +0100, Jaroslav Reznik wrote:
>  
>  > * system-config-display
>  >   - xrandr should be used for resolution/dualhead configuration, Gnome & KDE 
>  > have 
>  >     own xrandr based display configuration tool
>  
>  Only for RandR 1.2-based drivers, note. Although as of F11 we should be
>  shipping RandR 1.2 drivers for the three major card types by default for
>  the first time (radeon, nouveau, intel).
>  
>  > * system-config-network
>  >   - replacement NetworkManager
>  >   - missing IPv6? routing?
>  
>  Quite a lot of people still don't want to use NetworkManager. It makes
>  little sense on a system which just sits there connected to a static IP
>  address 24/7. 
NM also doesn't write out ifcfg files, which s-c-n is still pretty good
at.  I hope to land that functionality for F11, but I think s-c-n still
has one release left in it, at least.  Doesn't hurt to keep both around,
as long as the cooperate with each other (something I'll be working on
too).  Maybe just don't install it by default when NM is installed by
default, but keep it available.

Dan

>  -- 
>  Adam Williamson
>  Fedora QA Community Monkey
>  IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
>  http://www.happyassassin.net
>

[Matthew Woehlke]

Jaroslav Reznik wrote:
>  * system-config-display
>    - xrandr should be used for resolution/dualhead configuration, Gnome & KDE 
>  have 
>      own xrandr based display configuration tool
>    - generates xorg.conf - it's not needed anymore (only if someone needs 
>      more expert configuration)   
At least this machine needs an xorg.conf, I think the one of my home 
machines does also.

I'd vote to keep this as a tool to generate a decent starting point for 
an xorg.conf that needs to be hand-edited, as opposed to having to write 
one from scratch (which, frankly, sucks, especially things like getting 
monitor refresh rates correct).

Bill pointed out that this is not installed by default, which is fine. 
I'd say we should keep it that way; available and working for those that 
need it, but not installed by default.

>  * system-config-network
>    - replacement NetworkManager
>    - missing IPv6? routing? 
What about machines not using NM? (Like, again, this one and one of my 
home machines...) As with s-c-display, it's useful for not having to 
hand-write configs (or at least to generate good starting points). It 
should probably not be installed when NM is being used, though, so 'not 
installed by default' except on non-NM-using spins (if there are any).

For this machine, I'm running custom ifup scripts in order to set up a 
TUN bridge, so "eth0" is just the hardware with no address and the local 
processes actually use br0. (tap0 is fed to qemu as a virtual hardware 
device, so the box has multiple IP's, one of which is "owned" by the 
VM.) Can NM handle that yet?

>  * system-config-date
>    - Gnome/KDE/XFCE have own datetime configuration tool/module, it's confusing 
>  than
>      which one users should use
>    - used in firstboot or anaconda??? 
...and s-c-date conflicts with these. What manages the ntp service? I 
don't think I've had any luck with the KDE date config working correctly 
at system level, which means if s-c-date went away I'd have to manage 
the date/time on my machine(s) at CLI level and by editing ntpd.conf by 
hand.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
  ,= ,-_-. =.    Freedom to Use
((_/)o o(\_))  Freedom to Examine
  `-'(. .)`-'  Freedom to Share
      \_/     Freedom to Improve

[David Lutterkort]

On Tue, 2009-03-24 at 13:21 -0500, Matthew Woehlke wrote:
>  For this machine, I'm running custom ifup scripts in order to set
> up a 
>  TUN bridge, so "eth0" is just the hardware with no address and the local 
>  processes actually use br0. (tap0 is fed to qemu as a virtual hardware 
>  device, so the box has multiple IP's, one of which is "owned" by the 
>  VM.) Can NM handle that yet? 
No, but that's such a common setup that both libvirt and NM will support
it in the near future (via netcf).

David

[Kevin Kofler]

Matthew Woehlke wrote:
>  ...and s-c-date conflicts with these. What manages the ntp service?
> I
>  don't think I've had any luck with the KDE date config working correctly
>  at system level, which means if s-c-date went away I'd have to manage
>  the date/time on my machine(s) at CLI level and by editing ntpd.conf by
>  hand. 
Uh, the KDE date configuration tool is intended to work at system level (and
at system level ONLY), it's one of the few System Settings modules
requiring root privileges for a reason.

        Kevin Kofler

[David Lutterkort]

On Tue, 2009-03-24 at 17:10 +0100, Jaroslav Reznik wrote:
>  * system-config-netboot
>    - very outdated
>    - replacements k12linux, cobbler 
Heh, yeah, the shortcomings of this were the inspiration for cobbler.

>  * system-config-boot
>    - at least it needs facelift and it's not very usable at all 
And should probably use Augeas in the backend.

>  * system-config-network
>    - replacement NetworkManager
>    - missing IPv6? routing? 
If a tool like this is needed at all (though NM should really just
absorb the functionality), the backend should be based on netcf[1]

David

[1] Currently at http://people.redhat.com/dlutter/netcf, but I'll
    move it to fedorahosted any day now, and actually make a release.
    The intent is to have netcf as a distro-agnostic backend for network
    configuration that can be used by at least libvirt and NM

[Rudolf Kastl]

2009/3/24 Jaroslav Reznik <jreznik(a)redhat.com&gt;:
>  Hi all (interested in system config tools;-).
>  We are working on System Configurations Tools Cleanup Project we need Fedora
>  community opinion on this subject.
>
>  Some s-c-* tools are now very outdated, some are replaced with better
>  solution, some are only used in Anaconda etc.
>
>  This is a short list of application that could be eliminated/replaced/enhanced
>  in short/long term from Fedora.
>
>  I've prepared it simple and clean to support further discussion, maybe some
>  other tool is missing...
>
>  * system-config-netboot
>   - very outdated
>   - replacements k12linux, cobbler 
could be removed.

>  * system-config-boot
>   - at least it needs facelift and it's not very usable at all
>
>  * system-config-display
>   - xrandr should be used for resolution/dualhead configuration, Gnome & KDE
>  have
>     own xrandr based display configuration tool
>   - generates xorg.conf - it's not needed anymore (only if someone needs
>     more expert configuration) 
or someone has issues with the automatic detection or wants to use
nvidia binary drivers (which have a file overlay). or needs to switch
driver to vesa if drivers are broken or or or or... i wouldnt call
that expert stuff. more things you still need to do in some cases.

>  * system-config-network
>   - replacement NetworkManager
>   - missing IPv6? routing? 
system-config-network has a text user interface. networkmanager is
still lacking a proper way to be configured or used from a terminal as
it is. still required e.g. for system troubleshooting and system
rescue ... e.g. if X doesent start you cant enable or manage your
interfaces properly. most endusers cant handle the textfiles and
therefore wouldnt even be able to configure an interface manually to
get the updates that makes things start again. (not like friends of
mine didnt have those issues before)

>  * system-config-date
>   - Gnome/KDE/XFCE have own datetime configuration tool/module, it's confusing
>  than
>     which one users should use
>   - used in firstboot or anaconda??? 
as long as those tool properly configure ntp... in the gnome date
applet i cant find any ntp options.

>  * system-config-keyboard
>   - used only in Anaconda, let it be standalone?
>   - very simple tool, Gnome/KDE have better one 
system wide config tool yet missing?

>  * system-config-httpd
>   - old GTK 1 application, should be ported to GTK 2 & PolicyKit 
+1

>  * switchdesk and system-switch-tools?
>   - it's possible to switch desktop in GDM/KDM
>   - one tool for switching all alternatives? 
atleast the nonui script can still be useful to some degree.



there is another one i have to add:

system-config-cluster:

doesent start since 2 years because of a pam error... maintainer
doesent respond to bugs at all... is pretty buggy.
but doesent have a replacement (ricci is in the true... but lucy still
cant go in because of the zope problem since years now)


>  ---
>
>  Expect more spam from us regarding cleanup project - we already have s-c-*
>  tools reviews, so we will fill bugs soon (with some guidelines on list),
>  nearly all s-c-* tools need to be ported to PolicyKit and so on ;-)
>
>  Happy system config tools hacking
>  System Config Cleanup Team
>
>  --
>  Jaroslav Řezník <jreznik(a)redhat.com&gt;
>  Associate Software Engineer - Base Operating Systems Brno
>
>  Office: [phone]
>  Mobile: [phone]
>  Red Hat, Inc.                               http://cz.redhat.com/
>
>  --
>  fedora-devel-list mailing list
>  fedora-devel-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

[Matthias Clasen]

On Tue, 2009-03-24 at 20:03 +0100, Rudolf Kastl wrote:
>  
>  as long as those tool properly configure ntp... in the gnome date
>  applet i cant find any ntp options. 
NTP doesn't need any configuration UI, it just needs to be on by
default.

[Ralf Corsepius]

Matthias Clasen wrote:
>  On Tue, 2009-03-24 at 20:03 +0100, Rudolf Kastl wrote:
> > as long as those tool properly configure ntp... in the gnome date
> > applet i cant find any ntp options.
>  
>  NTP doesn't need any configuration UI,  it just needs to be on by default.
Wrong.

Keywords: Firewall, dedicated local ntpd-servers.

Ralf

[Adam Jackson]

On Wed, 2009-03-25 at 18:49 +0100, Ralf Corsepius wrote:
>  Matthias Clasen wrote:
>  > On Tue, 2009-03-24 at 20:03 +0100, Rudolf Kastl wrote:
>  >> as long as those tool properly configure ntp... in the gnome date
>  >> applet i cant find any ntp options.
>  > 
>  > NTP doesn't need any configuration UI,  it just needs to be on by default.
>  Wrong.
>  
>  Keywords: Firewall, dedicated local ntpd-servers. 
Statistically speaking, 0% of the endpoints on the internet are ntpd
servers.

- ajax

[Chuck Anderson]

On Thu, Mar 26, 2009 at 10:12:21AM -0400, Adam Jackson wrote:
>  On Wed, 2009-03-25 at 18:49 +0100, Ralf Corsepius wrote:
>  > Matthias Clasen wrote:
>  > > On Tue, 2009-03-24 at 20:03 +0100, Rudolf Kastl wrote:
>  > >> as long as those tool properly configure ntp... in the gnome date
>  > >> applet i cant find any ntp options.
>  > > 
>  > > NTP doesn't need any configuration UI,  it just needs to be on by default.
>  > Wrong.
>  > 
>  > Keywords: Firewall, dedicated local ntpd-servers.
>  
>  Statistically speaking, 0% of the endpoints on the internet are ntpd
>  servers. 
We also need to fix ntpdate so that it waits for the network to be 
available before attempting to set the clock.  Using NetworkManager 
NETWORKWAIT=yes doesn't help here.

[Callum Lerwick]

On Wed, 2009-03-25 at 13:40 -0400, Matthias Clasen wrote:
>  On Tue, 2009-03-24 at 20:03 +0100, Rudolf Kastl wrote:
>  > 
>  > as long as those tool properly configure ntp... in the gnome date
>  > applet i cant find any ntp options.
>  
>  NTP doesn't need any configuration UI, it just needs to be on by
>  default.  
Because NTP servers just love it when you have ten machines updating
from one IP. Even Windows XP lets you easily enter in your own NTP
server.

... What I really want is an easy "Multicast client" checkbox. Right now
to configure multicast I seem to have to manually edit ntp.conf which
seems to get clobbered occasionally. I run a local NTP server off my
MythTV box, since it needs to have accurate time anyway.

[Nils Philippsen]

On Thu, 2009-03-26 at 00:51 -0500, Callum Lerwick wrote:

>  ... What I really want is an easy "Multicast client"
> checkbox. Right now
>  to configure multicast I seem to have to manually edit ntp.conf 
Would you please open a bug/RFE for that against s-c-date?

>  which
>  seems to get clobbered occasionally. 
What gets/how does it get clobbered?

>  I run a local NTP server off my
>  MythTV box, since it needs to have accurate time anyway. 
Thanks,
Nils
-- 
Nils Philippsen      "Those who would give up Essential Liberty to purchase 
Red Hat               a little Temporary Safety, deserve neither Liberty
nils(a)redhat.com       nor Safety."  --  Benjamin Franklin, 1759
PGP fingerprint:      C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011

[Kevin Kofler]

Rudolf Kastl wrote:

>  2009/3/24 Jaroslav Reznik <jreznik(a)redhat.com&gt;:
> > * system-config-date
> > - Gnome/KDE/XFCE have own datetime configuration tool/module, it's
> > confusing than
> > which one users should use
> > - used in firstboot or anaconda???
>  
>  as long as those tool properly configure ntp... in the gnome date
>  applet i cant find any ntp options. 
KDE's System Settings date/time module supports NTP.

        Kevin Kofler

[Nils Philippsen]

On Tue, 2009-03-24 at 17:10 +0100, Jaroslav Reznik wrote:

>  * system-config-date
>    - Gnome/KDE/XFCE have own datetime configuration tool/module, it's confusing 
>  than
>      which one users should use 
- as they (should) operate on the same low-level resources
(/bin/date, /sbin/hwclock, /etc/localtime) it shouldn't really matter
much which is used
- the DE specific things should be much more visible than s-c-date (i.e.
directly in the panel vs. some levels deep in the menu), I don't see
much source for confusion there
- AFAIK, none of the tools in the DEs deal with NTP right now (do they
at least honor it being used and then block setting the system clock?),
so I'm not inclined to drop it

>    - used in firstboot or anaconda??? 
yes

Nils
-- 
Nils Philippsen      "Those who would give up Essential Liberty to purchase 
Red Hat               a little Temporary Safety, deserve neither Liberty
nils(a)redhat.com       nor Safety."  --  Benjamin Franklin, 1759
PGP fingerprint:      C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011

[Kevin Kofler]

Nils Philippsen wrote:
>  - AFAIK, none of the tools in the DEs deal with NTP right now (do
> they
>  at least honor it being used and then block setting the system clock?),
>  so I'm not inclined to drop it 
KDE actually does.

That said, it doesn't detect an NTP setup configured with
system-config-date, it shows NTP as not in use. It also only supports
selecting a server from a list or entering a server into the combobox, no
multiple servers, no advanced options.

        Kevin Kofler

[Rudolf Kastl]

2009/3/27 Kevin Kofler <kevin.kofler(a)chello.at&gt;:
>  Nils Philippsen wrote:
> > - AFAIK, none of the tools in the DEs deal with NTP right now (do they
> > at least honor it being used and then block setting the system clock?),
> > so I'm not inclined to drop it
>
>  KDE actually does.
>
>  That said, it doesn't detect an NTP setup configured with
>  system-config-date, it shows NTP as not in use. It also only supports
>  selecting a server from a list or entering a server into the combobox, no
>  multiple servers, no advanced options. 
proper ntp setups require atleast 3 servers to be set. (proper tuning
various more things.)

regards,
Rudolf Kastl

>         Kevin Kofler
>
>  --
>  fedora-devel-list mailing list
>  fedora-devel-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

[Nils Philippsen]

On Fri, 2009-03-27 at 23:53 +0100, Kevin Kofler wrote:
>  Nils Philippsen wrote:
>  > - AFAIK, none of the tools in the DEs deal with NTP right now (do they
>  > at least honor it being used and then block setting the system clock?),
>  > so I'm not inclined to drop it
>  
>  KDE actually does.
>  
>  That said, it doesn't detect an NTP setup configured with
>  system-config-date, it shows NTP as not in use. 
I haven't looked at the tool/applet in question, but to me this seems
more problematic than not caring about NTP at all. I guess KDE stores
the setting whether NTP is used or not in some KDE configuration place?
It's probably a bit more work to operate with the actual OS setting
which might be implemented in very different ways on the various OSs
where KDE is deployed (Linux distros, other Unixes, ...), but if you
want I can try to help out with that so that it can be done properly on
the OSs where we know how to do it. I imagine it like this piece of
pseudo code:

if system is LSB compliant
        use LSB functions to check for status/start/stop NTP
        (/usr/lib/lsb/{install,remove}_initd, calling /etc/init.d
        scripts directly)
else if system has /sbin/chkconfig, /sbin/service
        use chkconfig, service to check for status/start/stop NTP
else if (yet another way to do it)
        (do it yet another way)
else if ...
        ...
else
        don't bother

Naturally, this would have to take the various names of NTP init scripts
into account (e.g. "ntp" vs. "ntpd"). It also shouldn't matter
much if
the above decisions are made during build- or runtime. The various OS
teams would then be responsible to keep their part of this up to date.

Nils
-- 
Nils Philippsen      "Those who would give up Essential Liberty to purchase 
Red Hat               a little Temporary Safety, deserve neither Liberty
nils(a)redhat.com       nor Safety."  --  Benjamin Franklin, 1759
PGP fingerprint:      C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011

[Nils Philippsen]

On Tue, 2009-03-24 at 17:10 +0100, Jaroslav Reznik wrote:
>  * system-config-network
>    - replacement NetworkManager
>    - missing IPv6? routing? 
Not my turf, but I'll comment anyway. IMO, some things need to happen
before NM could be used everywhere from a functionality POV (not
addressing bloat here ;-), here's what I think of right now:

- it needs to support an arbitrary number of interfaces up at the same
time (i.e. multiple LANs/WLANs/VPNs simultaneously)
- it needs to support arbitrarily complicated routing setups, if I'm
connected to two VPNs at the same time it better do that right
- It should (optionally) not immediately kill off interfaces with
dropped links
- DNS handling needs to be improved a great deal, e.g. use private DNS
server for home LAN, use VPN DNS server for their respective addresses
_only_ (e.g. for specific domains/IP ranges)

Nils
-- 
Nils Philippsen      "Those who would give up Essential Liberty to purchase 
Red Hat               a little Temporary Safety, deserve neither Liberty
nils(a)redhat.com       nor Safety."  --  Benjamin Franklin, 1759
PGP fingerprint:      C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011

[Christoph Wickert]

Am Dienstag, den 24.03.2009, 17:10 +0100 schrieb Jaroslav Reznik:

>  * system-config-date
>    - Gnome/KDE/XFCE have own datetime configuration tool/module, it's confusing 
>  than which one users should use 
Xfce does _not_ have a date time configuration tool.

>  * system-config-keyboard
>    - used only in Anaconda, let it be standalone?
>    - very simple tool, Gnome/KDE have better one 
So has Xfce, but LXDE and others haven't.

>  * switchdesk and system-switch-tools?
>    - it's possible to switch desktop in GDM/KDM
>    - one tool for switching all alternatives? 
Yes please, as not everybody wants to use GDM/KDM. The tool needs to be
extensible for new desktops, currently this is hardcoded.

Regards,
Christoph

[Orcan Ogetbil]

On Tue, Mar 24, 2009 at 12:10 PM, Jaroslav Reznik wrote:
>  * system-config-keyboard
>   - used only in Anaconda, let it be standalone?
>   - very simple tool, Gnome/KDE have better one
>  
I'm constantly using this. Something in Fedora changes my Fedora
layout to Arabic on each login, for some reason. I couldn't figure out
why this is happening but the only solution is to run
system-config-keyboard and pick US English for me. KDE's configuration
GUI does not help at all.

Orcan

[Björn Persson]

onsdagen den 25 mars 2009 skrev Orcan Ogetbil:
>  On Tue, Mar 24, 2009 at 12:10 PM, Jaroslav Reznik wrote:
>  > * system-config-keyboard
>  >  - used only in Anaconda, let it be standalone?
>  >  - very simple tool, Gnome/KDE have better one
>
>  I'm constantly using this. Something in Fedora changes my Fedora
>  layout to Arabic on each login, for some reason. I couldn't figure out
>  why this is happening but the only solution is to run
>  system-config-keyboard and pick US English for me. KDE's configuration
>  GUI does not help at all. 
I had that problem for several weeks, except that the system seemed to think I 
had a US keyboard and I had to set it to Swedish on each login. The first 
thing I did was to check if there was a system-config-keyboard. There was, 
and it did the job, so I never looked for a KDE tool. (It might have been a 
bit difficult if I hadn't known to press [+] to type "-".)

The problem seems to have gone away about a week ago.

Björn Persson

[Till Maas]

On Di März 24 2009, Jaroslav Reznik wrote:

>  * system-config-date
>    - Gnome/KDE/XFCE have own datetime configuration tool/module, it's
>  confusing than
>      which one users should use
>    - used in firstboot or anaconda???
>
>  * system-config-keyboard
>    - used only in Anaconda, let it be standalone?
>    - very simple tool, Gnome/KDE have better one 
Do the Gmone/KDE/Whatever tools really know / configure 
/etc/sysconfig/keyboard and /etc/sysconfig/clock?

I remember using system-config-keyboard a lot with live media btw.

Regards,
Till