Let's not forget to take the noob user perspective on things regarding
my thread..
Jeroen van Meeuwen wrote:
Jóhann B. Guðmundsson wrote:
Jeroen van Meeuwen wrote:
If an application is allowed to change the firewall configuration
why do we even include the firewall at all? What's next,
applications that can modify the SELinux policies to allow
themselves to run?
You still need to be root to enable these (chkconfig ) services so
why not let it open access for it self while you enable the service.
If you have custom firewall rules check the hash box to disable this
so doesn't mess up firewall rules. Regarding the SElinux I cannot
predict the future
tho I would mind having that ability
You do not necessarily have to be root but gain root privileges. In
addition, some applications like HAL daemon can enable (for example)
CUPS (ergo without the user being root or gaining any privileges);
would you want to let that automatically open up your firewall?
SELinux in this case does get a little help. If you run authconfig to
configure NIS and choose to update the configuration files (--update),
it enables the ypbind as well as the allow_ypbind SELinux boolean.
"service httpd start" however should not, under any circumstance,
enable any of the SELinux booleans involved with where httpd may look
for files.
Finding the golden way between service firewall and SElinux on what
should/could be open automatically takes time
and discussion. Rome wasn't build in one day, but the fewer steps needed
to get things working for the noob user the better.
At least more checkbox for more service should be added to s-c-s
specially the vpn/protocols related one...
Service should be bound to certain interface ( lo eth* ) instead
being configured default to listen to *.
Right, because on one side you want to make things easier, but the
bind address is /so easy/ to configure from any GUI administration
tool, that you want to limit the bind to a certain interface only?
What happens if there's no eth0? What happens if you have eth0,
wlan0 and ppp0 and change between those interfaces because you are a
roaming user?
It should not still be set to listen to all interfaces
Good argument, I guess we really need to reconsider.
Let the majority fedora user community decide what should be the
default application to use in gnome/kde to open/play/view etc files
[...]
I believe we have that already.
Ok where I wanna vote against use of Totem and Evolution
System-config-network as default and vote for VLC and Thunderbird and
NetworkManager instead...
Try the wiki Feature pages. These threads will most definitely not get
the feature you want. VLC btw is out-of-the-question.
The Fedora users should vote what is and what is out in default install,
so up with poll my vote will be one of thousand, hundred of thousand and
even millions.
Application user interface should be kept simple and simple to use
with advanced menu feature for the advanced user. Things should
work as much as possible out of the box .
99% what normal user is doing ( surfing the web, reading his email,
writing his paper etc should work out of the box ).
I guess your wish got heard retroactively and implemented some years
ago.
We are behind in supporting media in browser ( java mplayer plugin etc )
Do you think there might be a reason why these are not in Fedora?
There must be a (legal)way to enable 3 party repos during the
installation process and set these things up for the noob user.
God no! If we do that, we lose. On a personal note; I'd rather make
it as hard as possible to ever use anything I can't read any source
code of, or that isn't licensed to permit me to do whatever I want
to do with it.
Hum wonder if noobs like reading source don't think so...
Consider what a noob does on any other Operating System Of
(No-)Choice. It isn't much easier.
May I ask how you imagine the user recovers his data if he looses
his private key or passphrase?
I don't you just get screwed..
Nice, that'll bring us good user experience.
--
Jóhann B. Guðmundsson. RHCE,CCSA
Unix Kerfistjóri.
Kerfistjórn.
Reiknistofnun Háskóla Íslands.
Tæknigarði, Dunhaga 5. Rafpóstur: johannbg@xxxxx
107 Reykjavík. Sími: 525-4267
Ísland. Bréfasími: 552-8801
Johann B. Gudmundsson. RHCE,CCSA
Unix System Engineer.
IT Management.
Reiknistofnun University of Iceland.
Taeknigardi, Dunhaga 5. Email: johannbg@xxxxx
IS-107 Reykjavik. Phone: +354-525-4267
Iceland. Fax: +354-552-8801
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
