Faster system-start/shutdown! Service need to start on demand rather then during the boot up process or at least if anaconda/kudzu don't detect it don't enable it ( bluetooth, printer service sis etc. ) It's better to have the user to go through setup/installation/initializations process ( they are used to it ) and have faster startup than enable lots of unwanted/unneeded service during startup "for everything works solution"!
Application need to be able to adjust firewall to allow access for them selves. We don't like it but they noob user will and if your arguments are, the application will mess up my highly complicated netfilter/iptables firewall, routing rules than your smart enough to be able to *hash* an check box who would disable this feature in system-config-security, or at least offer a wider selection of services to open in s-c-s especially those who need more than just an port opening ( protocol 47 48 50 51 etc.. ). The noob user is not able to create there own *Custom* firewall rules.
Service should be bound to certain interface ( lo eth* ) instead being configured default to listen to *.
Let the majority fedora user community decide what should be the default application to use in gnome/kde to open/play/view etc files and which application will come with default installation ( in gnome/kde ), do research in what people are adding/changing/replacing to get better hint of what should be used as default app behavior or better yet let fedora user vote what should be used in new release in fedora ( browser pluggin maybe that would ask user to vote on what ( apps/fetures ) they want to see in next release of fedora vote counted and implemented after dev freeze? ).
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 ). There must be a (legal)way to enable 3 party repos during the installation process and set these things up for the noob user. ( moving the legal liability from fedora to the user, disclaimer or something he has to read, approve and press ok for ). If not move the Fedora HQ to Europe and create a legal and handicapped Fedora spin to be released in the states since everybody is so keen on suing everybody in the states. ( we still have some sanity and dignity left here in Europe, I said some :-) For their defence the states are young as a nation maybe this will grow of them. )
Offer encryption on user sensitive data during install or even by default on hardrive. ( browser cache, email cache etc or maybe offer the user to have his /home on encrypted partion ). What we do ( Surf the web,what we spend our money on etc ) is being monitor/catalog/profiled enough as is. Atleas if somebody gets his hands on your box/drive/laptop lets give him hard time to actually get your data.
Lets try to start do see things from noob user perspective and not advanced/dev user perspective. We advanced/developers can handle our selfs the noob cant!
Best regards Johann B.
Ps. Why was minimal install ( no gui ) removed from anaconda?
/Fedora by the user for the user.../
On Mon, 03 Sep 2007 12:25:52 +0000 ""Jóhann B. Guðmundsson"" johannbg@hi.is wrote:
Why was minimal install ( no gui ) removed from anaconda?
Because "minimal" meant way too many different things to different people. Instead we just give you control over the package set and let you even de-select the Base group (no yum for you!). Now everybody can define/select their own meaning of Minimal.
(and remember, many non-english languages need X to display the fonts correctly. Not very friendly if we dismiss them as users.)
On Mon, 2007-09-03 at 14:25 +0200, "Jóhann B. Guðmundsson" wrote:
Faster system-start/shutdown! Service need to start on demand rather then during the boot up process or at least if anaconda/kudzu don't detect it don't enable it ( bluetooth, printer service sis etc. ) It's better to have the user to go through setup/installation/initializations process ( they are used to it ) and have faster startup than enable lots of unwanted/unneeded service during startup "for everything works solution"!
+1 for this from here, BUT. Most of the nowadays notebooks has bluetooth in them, but it's turned off by default. You turn it on usually hitting or switching some button. As it is usually connected via USB internaly, it will not get detected by Anaconda or Kudzu, unless turned on. The bluetooth service, when running, however detects that bluetooth was plugged/turned on and appear in systray (unless set otherwise). While this is true for bluetooth, it might be similar for other services.
I think we should rather take a loooong thought and add to FirstBoot one screen for selecting services, which would be easy and simple to use. You would have there a combo with Desktop/Notebook/Server choices, and some checkboxes for optional services (but with sane names). I can imagine that as nobody needs bluetooth on server, on Desktop nearly nobody needs running power manager, etc. We should take a thought and decide what services should be enabled by default and what services should be easily available for user enabling during first boot (most likely the cups one, but MUST be called something like Printer Support).
Application need to be able to adjust firewall to allow access for them selves. We don't like it but they noob user will and if your arguments are, the application will mess up my highly complicated netfilter/iptables firewall, routing rules than your smart enough to be able to *hash* an check box who would disable this feature in system-config-security, or at least offer a wider selection of services to open in s-c-s especially those who need more than just an port opening ( protocol 47 48 50 51 etc.. ). The noob user is not able to create there own *Custom* firewall rules.
I hope I am no so geeky user, but to this I'd tell NO, NO, NO. If opening ports, than not automatically, but via system-config-firewall. If it is designed nice enough I think everyone can handle it. SELinux is another topic though... But I don't use it, so here I cannot make any suggestions.
Service should be bound to certain interface ( lo eth* ) instead being configured default to listen to *.
It cannot be? (I really don't know)
Let the majority fedora user community decide what should be the default application to use in gnome/kde to open/play/view etc files and which application will come with default installation ( in gnome/kde ), do research in what people are adding/changing/replacing to get better hint of what should be used as default app behavior or better yet let fedora user vote what should be used in new release in fedora ( browser pluggin maybe that would ask user to vote on what ( apps/fetures ) they want to see in next release of fedora vote counted and implemented after dev freeze? ).
+1 for this. The default applications need rethink, as well as default starters (the apps icons on panel). I think we need not to do a survey, mugshot serves good for that purpose [1].
Application user interface should be kept simple and simple to use with advanced menu feature for the advanced user.
Simple? Go for Gnome. Advanced? Go for KDE. I know, it's a lot of simplification, but generally people who want to set up everything use KDE and people who want things just work use GNOME. But being advanced user does not necessarily mean that you go with KDE... I don't think we need improvements in this case (maybe the pirut/pup and system-config-*, but that is being worked on continually).
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 ). There must be a (legal)way to enable 3 party repos during the installation process and set these things up for the noob user. ( moving the legal liability from fedora to the user, disclaimer or something he has to read, approve and press ok for ). If not move the Fedora HQ to Europe and create a legal and handicapped Fedora spin to be released in the states since everybody is so keen on suing everybody in the states. ( we still have some sanity and dignity left here in Europe, I said some :-) For their defence the states are young as a nation maybe this will grow of them. )
+1, but with this you should rather go ask on fedora/redhat legal. I don't think we could move Fedora HQ to Europe, but maybe there could be a legal way, how to help user with enabling third party repos (most likely livna or fresh, but not both) during the installation process.
Offer encryption on user sensitive data during install or even by default on hardrive. ( browser cache, email cache etc or maybe offer the user to have his /home on encrypted partion ). What we do ( Surf the web,what we spend our money on etc ) is being monitor/catalog/profiled enough as is. Atleas if somebody gets his hands on your box/drive/laptop lets give him hard time to actually get your data.
AFAIK this is being worked on.
Martin
References: [1] http://mugshot.org/applications
Lets try to start do see things from noob user perspective and not advanced/dev user perspective. We advanced/developers can handle our selfs the noob cant!
Best regards Johann B.
Ps. Why was minimal install ( no gui ) removed from anaconda?
/Fedora by the user for the user.../
-- Johann B. Gudmundsson. RHCE,CCSA Unix System Engineer. IT Management. Reiknistofnun University of Iceland. Taeknigardi, Dunhaga 5. Email: johannbg@hi.is IS-107 Reykjavik. Phone: +354-525-4267 Iceland. Fax: +354-552-8801
On Mon, 03 Sep 2007 14:58:33 +0200 Martin Sourada martin.sourada@seznam.cz wrote:
I think we should rather take a loooong thought and add to FirstBoot one screen for selecting services, which would be easy and simple to use. You would have there a combo with Desktop/Notebook/Server choices, and some checkboxes for optional services (but with sane names). I can imagine that as nobody needs bluetooth on server, on Desktop nearly nobody needs running power manager, etc. We should take a thought and decide what services should be enabled by default and what services should be easily available for user enabling during first boot (most likely the cups one, but MUST be called something like Printer Support).
Actually my feeling is that we should get rid of as many firstboot screens as possible and just pick reasonable defaults. The tools are there if a curious user needs to adjust something. So much of what we ask is just silly.
On Mon, 2007-09-03 at 15:00 +0200, Jesse Keating wrote:
On Mon, 03 Sep 2007 14:58:33 +0200 Martin Sourada martin.sourada@seznam.cz wrote:
I think we should rather take a loooong thought and add to FirstBoot one screen for selecting services, which would be easy and simple to use. You would have there a combo with Desktop/Notebook/Server choices, and some checkboxes for optional services (but with sane names). I can imagine that as nobody needs bluetooth on server, on Desktop nearly nobody needs running power manager, etc. We should take a thought and decide what services should be enabled by default and what services should be easily available for user enabling during first boot (most likely the cups one, but MUST be called something like Printer Support).
Actually my feeling is that we should get rid of as many firstboot screens as possible and just pick reasonable defaults. The tools are there if a curious user needs to adjust something. So much of what we ask is just silly.
Yes, most ARE, but the one with services could be useful. There is a batch of services that are useful on most of notebooks, but are unneeded on most of Desktops/Servers and vice versa. And we'd like to get rid of as much unneeded services as possible, so if we target the default ones with a thought of the target platform, it would be IMHO more effective. Maybe it could go to anaconda, but personally I think that first boot is better place for that.
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Martin Sourada wrote:
Yes, most ARE, but the one with services could be useful. There is a batch of services that are useful on most of notebooks, but are unneeded on most of Desktops/Servers and vice versa. And we'd like to get rid of as much unneeded services as possible, so if we target the default ones with a thought of the target platform, it would be IMHO more effective. Maybe it could go to anaconda, but personally I think that first boot is better place for that.
Asking the user in this case is the wrong answer. Don't expect the user to cherry pick services to enable/disable during installation. If users want to do that they can do it post installation or use kickstart.
Rahul
On Mon, 2007-09-03 at 16:17 +0200, Rahul Sundaram wrote:
Martin Sourada wrote:
Yes, most ARE, but the one with services could be useful. There is a batch of services that are useful on most of notebooks, but are unneeded on most of Desktops/Servers and vice versa. And we'd like to get rid of as much unneeded services as possible, so if we target the default ones with a thought of the target platform, it would be IMHO more effective. Maybe it could go to anaconda, but personally I think that first boot is better place for that.
Asking the user in this case is the wrong answer. Don't expect the user to cherry pick services to enable/disable during installation. If users want to do that they can do it post installation or use kickstart.
Rahul
If we ask him do-you-want-to-turn-cups-hal-hcid-services-on kind of question then yes. If we ask him do you have notebook, desktop or server, than it is right to ask him. And having these three different platforms means different needed services. Which precisely are these need not to be known by the person who is questioned. But there are also services we cannot know if user will need it or not, but still has such names, that user cannot guess for what they are. Cups is one example. Many users do not want this by default (they don't have a printer connected to their PC), but others do, even if they are just ordinary users, knowing nothing about services. If we ask them, do you want to turn printer support on, he will know the answer. That is my point, I hope it is clear enough.
Martin Sourada wrote:
If we ask him do-you-want-to-turn-cups-hal-hcid-services-on kind of question then yes. If we ask him do you have notebook, desktop or server, than it is right to ask him.
Whether a system is a laptop or not can be detected by the installer. Desktop/Server usages can be quite fuzzy and you can't really determine which services to run based on such simplistic questions.
And having these three different
platforms means different needed services. Which precisely are these need not to be known by the person who is questioned. But there are also services we cannot know if user will need it or not, but still has such names, that user cannot guess for what they are. Cups is one example. Many users do not want this by default (they don't have a printer connected to their PC), but others do, even if they are just ordinary users, knowing nothing about services. If we ask them, do you want to turn printer support on, he will know the answer. That is my point, I hope it is clear enough.
Cups and many other services can just be started on demand. Look up Dbus system activation.
Rahul
On Mon, 2007-09-03 at 16:55 +0200, Rahul Sundaram wrote:
Martin Sourada wrote:
If we ask him do-you-want-to-turn-cups-hal-hcid-services-on kind of question then yes. If we ask him do you have notebook, desktop or server, than it is right to ask him.
Whether a system is a laptop or not can be detected by the installer. Desktop/Server usages can be quite fuzzy and you can't really determine which services to run based on such simplistic questions.
Well, on desktop you usually don't need any server services (http server, ftp server, ssh server,...) on server you usually don't need any desktop services (bluetooth, ConsoleKit, to name some) and some of the notebook services. Also there are cases where you combine e.g. laptop with server (like in my case, having mostly laptop services, but vsftpd and postfix in addition), but these users know, how to enable services by themselves.
And having these three different
platforms means different needed services. Which precisely are these need not to be known by the person who is questioned. But there are also services we cannot know if user will need it or not, but still has such names, that user cannot guess for what they are. Cups is one example. Many users do not want this by default (they don't have a printer connected to their PC), but others do, even if they are just ordinary users, knowing nothing about services. If we ask them, do you want to turn printer support on, he will know the answer. That is my point, I hope it is clear enough.
Cups and many other services can just be started on demand. Look up Dbus system activation.
Then it is sufficient to enable cups automatically, when user adds first printer. But still the defaults remain and I have many running services in default install, I'll clearly have no use for. If the difference between notebook/desktop/server is one or two service, than it is not much, if the difference is bigger you will have significantly longer boot time, only because having services you clearly don't need.
Martin
Rahul
Martin Sourada wrote:
Well, on desktop you usually don't need any server services (http server, ftp server, ssh server,...)
Like I said it's fuzzy. GNOME file sharing program called gnome-user-share depends on httpd for example.
Then it is sufficient to enable cups automatically, when user adds first printer. But still the defaults remain and I have many running services in default install, I'll clearly have no use for
Those are bugs that need to be fixed. Asking the user here is just a workaround to paper over this problem.
Rahul
Yes, most ARE, but the one with services could be useful. There is a batch of services that are useful on most of notebooks, but are unneeded on most of Desktops/Servers and vice versa. And we'd like to get rid of as much unneeded services as possible, so if we target the default ones with a thought of the target platform, it would be IMHO more effective. Maybe it could go to anaconda, but personally I think that first boot is better place for that.
+1 - A simple list with a service's name and a short description would be very useful, and not to mention cut boot time. IMHO there are many services they Fedora has enabled by default which are relatively useless for most users. The whole rpc/nfs gang of services, sendmail - Why? I may be wrong, but I doubt that most of our users want to be running NFS and mail servers on a default install. Besides that, running Bluetooth on a machine without Bluetooth-capable hardware is a complete waste of resources.
A simple example: [X] Laptop services [ ] Bluetooth - Bluetooth connectivity services [X] NetworkManager - Easy management of network connections [ ] Avahi - Zeroconf network discovery [ ] NFS - File sharing [ ] sendmail - Mail server [ ] SMB - Samba (Windows) file and printer sharing [ ] SSH - Remote shell
Laptop Services would enable cpuspeed and apmd, as desktop machines don't really *need* those services. The rest can be enabled as the user sees fit.
Stewart
Stewart Adam wrote:
Yes, most ARE, but the one with services could be useful. There is a batch of services that are useful on most of notebooks, but are unneeded on most of Desktops/Servers and vice versa. And we'd like to get rid of as much unneeded services as possible, so if we target the default ones with a thought of the target platform, it would be IMHO more effective. Maybe it could go to anaconda, but personally I think that first boot is better place for that.
+1 - A simple list with a service's name and a short description would be very useful, and not to mention cut boot time. IMHO there are many services they Fedora has enabled by default which are relatively useless for most users. The whole rpc/nfs gang of services, sendmail - Why? I may be wrong, but I doubt that most of our users want to be running NFS and mail servers on a default install. Besides that, running Bluetooth on a machine without Bluetooth-capable hardware is a complete waste of resources.
A simple example: [X] Laptop services [ ] Bluetooth - Bluetooth connectivity services [X] NetworkManager - Easy management of network connections [ ] Avahi - Zeroconf network discovery [ ] NFS - File sharing [ ] sendmail - Mail server [ ] SMB - Samba (Windows) file and printer sharing [ ] SSH - Remote shell
Laptop Services would enable cpuspeed and apmd, as desktop machines don't really *need* those services. The rest can be enabled as the user sees fit.
Yes I don't need cpuspeed, as I *really* like listening to the sound of my CPU fan at full speed for no good reason, I also like my powerbil being as high as possible.
I can see merits on the general idea here, but the concept of desktops not needing powermanagement is from the previous century.
Regards,
Hans
On Mon, 2007-09-03 at 19:38 +0200, Hans de Goede wrote:
Yes I don't need cpuspeed, as I *really* like listening to the sound of my CPU fan at full speed for no good reason, I also like my powerbil being as high as possible.
I can see merits on the general idea here, but the concept of desktops not needing powermanagement is from the previous century.
Regards,
Hans
That's what I'm saying - Letting the user select is nice. Some machine's fans will blare, others not. Some Desktop CPU have throttle states, others none or not enough to make a big change.
Stewart
Stewart Adam wrote:
On Mon, 2007-09-03 at 19:38 +0200, Hans de Goede wrote:
Yes I don't need cpuspeed, as I *really* like listening to the sound of my CPU fan at full speed for no good reason, I also like my powerbil being as high as possible.
I can see merits on the general idea here, but the concept of desktops not needing powermanagement is from the previous century.
Regards,
Hans
That's what I'm saying - Letting the user select is nice. Some machine's fans will blare, others not. Some Desktop CPU have throttle states, others none or not enough to make a big change.
The user will always have the choice. The question is only whether a list of all possible services make sense to ask in the installer. IMO, this is the distribution's responsibility. For cpuspeed, enable it by default if the hardware is capable. If the hardware is not capable, cpuspeed disables itself on start.
Rahul
On Mon, 2007-09-03 at 21:00 +0200, Rahul Sundaram wrote:
The user will always have the choice. The question is only whether a list of all possible services make sense to ask in the installer. IMO, this is the distribution's responsibility. For cpuspeed, enable it by default if the hardware is capable. If the hardware is not capable, cpuspeed disables itself on start.
Rahul
Yes, it is distribution's responsibility, but the goal here is to make the boot process more effective. That means point out services we don't need and remove them from default configuration. If we can do this process fully automatic and dependant on hardware, than I am all for it not being in anaconda or first boot. If not, give user basic, easy choice of default configuration, either of which will NOT break a system, the set of enabled/disabled services would be chosen by distribution.
Another thing is system-config-services. Do we want users to use it? If yes then we need to make it as much as possible fool-proof. That basically means that we should give sane names there and not just name of the services - everyone knows what bluetooth means, not anyone knows what cups is. Sometimes description is enough, sometimes the description is misleading, hard to understand.
Martin
Martin Sourada wrote:
Yes, it is distribution's responsibility, but the goal here is to make the boot process more effective. That means point out services we don't need and remove them from default configuration. If we can do this process fully automatic and dependant on hardware, than I am all for it not being in anaconda or first boot.
That is what is being worked upon atleast incrementally.
Another thing is system-config-services. Do we want users to use it? If yes then we need to make it as much as possible fool-proof. That basically means that we should give sane names there and not just name of the services - everyone knows what bluetooth means, not anyone knows what cups is. Sometimes description is enough, sometimes the description is misleading, hard to understand.
File a bug report with suggestions for better short descriptive messages.
Rahul
On 9/3/07, Martin Sourada martin.sourada@seznam.cz wrote:
Another thing is system-config-services. Do we want users to use it? If yes then we need to make it as much as possible fool-proof. That basically means that we should give sane names there and not just name of the services - everyone knows what bluetooth means, not anyone knows what cups is. Sometimes description is enough, sometimes the description is misleading, hard to understand.
Last time I used it, most of the services came with descriptions.
On 9/3/07, Stewart Adam s.adam@diffingo.com wrote:
That's what I'm saying - Letting the user select is nice. Some machine's fans will blare, others not. Some Desktop CPU have throttle states, others none or not enough to make a big change.
we have a way to select services... its called system-config-services and its in the System->Administration menu. There's absolutely no compelling reason to move the selection dialog for services into the install process.
-jef
On Mon, 2007-09-03 at 11:03 -0800, Jeff Spaleta wrote:
On 9/3/07, Stewart Adam s.adam@diffingo.com wrote:
That's what I'm saying - Letting the user select is nice. Some machine's fans will blare, others not. Some Desktop CPU have throttle states, others none or not enough to make a big change.
we have a way to select services... its called system-config-services and its in the System->Administration menu. There's absolutely no compelling reason to move the selection dialog for services into the install process.
-jef
I in no way want to offend the coders system-config-services as it's a great tool but honestly when I took my first look at it I wasn't so sure what it all meant and I doubt new users will either. Besides being confused about all the runlevels and things each initscript has it's own status message and the descriptions of the services aren't always so clear.
Duplicating s-c-s into firstboot would be pointless; I think what Martin was trying to say was that a the services we enable now as a "just incase" like apmd, cpuspeed, the rpc batch could go into a "Do you actually need these?" list. A simple checkmark with clear, one-lined descriptions.
Stewart
Stewart Adam wrote:
I in no way want to offend the coders system-config-services as it's a great tool but honestly when I took my first look at it I wasn't so sure what it all meant and I doubt new users will either. Besides being confused about all the runlevels and things each initscript has it's own status message and the descriptions of the services aren't always so clear.
Duplicating s-c-s into firstboot would be pointless; I think what Martin was trying to say was that a the services we enable now as a "just incase" like apmd, cpuspeed, the rpc batch could go into a "Do you actually need these?" list. A simple checkmark with clear, one-lined descriptions.
Anaconda/Firstboot usually works by integrating system-config-* instead of reinventing the wheel with a different configuration tool inside the installer.
If system-config-services needs improvement, that needs to be fixed regardless of whether it is going to be in firstboot or not.
Rahul
On 9/3/07, Stewart Adam s.adam@diffingo.com wrote:
Duplicating s-c-s into firstboot would be pointless; I think what Martin was trying to say was that a the services we enable now as a "just incase" like apmd, cpuspeed, the rpc batch could go into a "Do you actually need these?" list. A simple checkmark with clear, one-lined descriptions.
If you are able to simplify it... then simplify it post-install by improving s-c-services. There is no compelling reason to let users disable default services as part of the install process.
Let's say my wife installs fedora on her desktop and she doesn't want bluetooth. Using an install time process...like you want..she'd turn it off at install time right? Now lets say she gets a spiffy bluetooth appliance and an usb to bluetooth adaptor for her desktop so she can talk to that bluetooth appliance. Where does she go to re-enable bluetooth on the desktop? She has to go to s-c-services!!!!!!!
The ultimate win here is to fix the primary user interface users need to use to turn off and turn on services they feel they need or don't need. The other ultimate win is to more towards on-demand servicing as much as possible to reduce the need for any service control. There is no compelling reason to drive this into the install process.. it only complicates usability because the user will have to interact with a different interface to turn services back on post-install.
-jef
On Mon, 03 Sep 2007 14:55:19 -0400 Stewart Adam s.adam@diffingo.com wrote:
That's what I'm saying - Letting the user select is nice. Some machine's fans will blare, others not. Some Desktop CPU have throttle states, others none or not enough to make a big change.
Letting the user choose is fine. Asking every single user the question is not fine. I'm all for customization and choice, I just think we toss enough technobabble at people and get in their way enough before we let them use the system. Keep in mind that Live images don't really go through this and there haven't been many(any?) complaints in that area despite the rather large uptake on usage. I think that model somewhat proves that we don't have to bombard our users with a ton of questions and instead pick reasonable defaults and provide tools to adjust after the fact.
On 9/4/07, Jesse Keating jkeating@redhat.com wrote:
On Mon, 03 Sep 2007 14:55:19 -0400 Stewart Adam s.adam@diffingo.com wrote:
That's what I'm saying - Letting the user select is nice. Some machine's fans will blare, others not. Some Desktop CPU have throttle states, others none or not enough to make a big change.
Letting the user choose is fine. Asking every single user the question is not fine. I'm all for customization and choice, I just think we toss enough technobabble at people and get in their way enough before we let them use the system. Keep in mind that Live images don't really go through this and there haven't been many(any?) complaints in that area despite the rather large uptake on usage. I think that model somewhat proves that we don't have to bombard our users with a ton of questions and instead pick reasonable defaults and provide tools to adjust after the fact.
*shakes pom-poms*
On 9/4/07, Colin Walters walters@redhat.com wrote:
*shakes pom-poms*
I would have thought that this was about boot times that you'd be shak'n your... boot-y.
-jef"what does it say about me when the part of the 3 day weekend that I liked most was getting a solid block of time in on my in-house python data viewer."spaleta
On 9/3/07, Martin Sourada martin.sourada@seznam.cz wrote:
Yes, most ARE, but the one with services could be useful. There is a batch of services that are useful on most of notebooks, but are unneeded on most of Desktops/Servers and vice versa.
This does not have to be in firstboot.. this can be post-firstboot. I personally do not want to be stuck in the installer or firstboot any longer than I absolutely must. Turning services off and other customization tasks I can do after I am in the running system...in parallel with other more important activities like installing updates or reading penny-arcade.
Adding a services dialog in firstboot or anaconda has the additional complication that users who are confused by it, have no mechanism to talk to other users while sitting in the installer interface or firstboot. You are giving unsuspecting users the option to turn services off before experiencing what the default system configuration. If they decide to turn things off, things they actually really need but don't understand the system well enough to know it, then you have given them the option to cripple the system before they even see what a working system is suppose to be. And you've done it in a way that makes it more difficult to get help repairing.
If you want, add a well worded blurb about the existence of the services configuration tool in a firstboot page or something..but don't expose services in the installer process. Let users work with the default services, and then customize.
-jef
On Mon, 2007-09-03 at 15:18 +0200, Martin Sourada wrote:
Yes, most ARE, but the one with services could be useful. There is a batch of services that are useful on most of notebooks, but are unneeded on most of Desktops/Servers and vice versa. And we'd like to get rid of as much unneeded services as possible, so if we target the default ones with a thought of the target platform, it would be IMHO more effective. Maybe it could go to anaconda, but personally I think that first boot is better place for that.
Actually, the bigger problem is the concept that everything has to be a "system service run from an initscript". To pick a specific case -- the fact that bluetooth daemons get started by an initscript as a service is really not what you want at this point. You instead want them being started based on the existence of the hardware probably as a hal callout[1].
The same can really be said for most of the things which start by default currently which are maybe not needed in some cases.
Services are for _servers_. And having to enable them (via system-config-services or chkconfig or ...) to use them makes sense because that's hardly going to be the only configuration you need to do for them.
Jeremy
[1] Bluetooth specifically is tracked with https://bugzilla.redhat.com/show_bug.cgi?id=222315 and the more general tracker bug is https://bugzilla.redhat.com/show_bug.cgi?id=222312
On Tue, 2007-09-04 at 10:45 -0400, Jeremy Katz wrote:
Actually, the bigger problem is the concept that everything has to be a "system service run from an initscript". To pick a specific case -- the fact that bluetooth daemons get started by an initscript as a service is really not what you want at this point. You instead want them being started based on the existence of the hardware probably as a hal callout[1].
+1
The ideal solution would be to run bluetooth only when bluetooth hardware is present, the same when applicable to all other services.
About the defaults - If/When should we reselect what will be the defaults? I forget which release it was planned for, but I do remember seeing a page on the Wiki at one point about disabling sendmail and the rpc* services, but it never seemed to have happened. I think it would be a good change to make for F8. A small one, but a change nonetheless.
Stewart
On Tue, 2007-09-04 at 23:05 +0200, Stewart Adam wrote:
On Tue, 2007-09-04 at 10:45 -0400, Jeremy Katz wrote:
Actually, the bigger problem is the concept that everything has to be a "system service run from an initscript". To pick a specific case -- the fact that bluetooth daemons get started by an initscript as a service is really not what you want at this point. You instead want them being started based on the existence of the hardware probably as a hal callout[1].
+1
The ideal solution would be to run bluetooth only when bluetooth hardware is present, the same when applicable to all other services.
About the defaults - If/When should we reselect what will be the defaults? I forget which release it was planned for, but I do remember seeing a page on the Wiki at one point about disabling sendmail and the rpc* services, but it never seemed to have happened. I think it would be a good change to make for F8. A small one, but a change nonetheless.
Stewart
We are past the feature freeze, I don't think this is possible... BUT. This thread is finally getting some shape as well as my ideas on this issue. The firstboot services screen was bad idea and I take it back, we should focus our efforts better. That means, as you and some others also suggested:
1. redefine the default set of services. Should be runlevel dependent and it should include only the services that are crucial to non-problematic run on every machine and that provide good user experience as well (like automounting CD's)
2. add support for automatically turning on services dependant on hardware. If you plug in bluetooth, HAL detects it and turn on the bluetooth services. Should be however handled in a way where user can have control over the service if (s)he want. That would mean that we would need three states for such a service: turned off by default, turned on by default, automatic.
3. Improve the system-config-services. Its great tool and has great potential but its confusing at first look. We need to provide to each service such a description *AND* name that everyone (well, I exaggerate here a little...) will understand it.
4. Some services that require a change of firewall rules to run correctly should offer such a change (but not do the change automatically, sometimes you want to have specific rules for the firewall, like opening ports only to specific IPs). These are mostly server services like sendmail, postfix, vsftpd, ...
5. Would be good if we provide gui utilities for easy (and only basic) configuration of services that has configuration capabilities. Should be accessible from system-config-services.
I hope this list makes sense, I think I learned a lot in this particular thread... We could maybe, if the changes are desirable and sane, add this on the F9 feature list.
Thanks, Martin
Martin Sourada wrote:
On Tue, 2007-09-04 at 23:05 +0200, Stewart Adam wrote:
On Tue, 2007-09-04 at 10:45 -0400, Jeremy Katz wrote:
Actually, the bigger problem is the concept that everything has to be a "system service run from an initscript". To pick a specific case -- the fact that bluetooth daemons get started by an initscript as a service is really not what you want at this point. You instead want them being started based on the existence of the hardware probably as a hal callout[1].
+1
The ideal solution would be to run bluetooth only when bluetooth hardware is present, the same when applicable to all other services.
About the defaults - If/When should we reselect what will be the defaults? I forget which release it was planned for, but I do remember seeing a page on the Wiki at one point about disabling sendmail and the rpc* services, but it never seemed to have happened. I think it would be a good change to make for F8. A small one, but a change nonetheless.
Stewart
We are past the feature freeze, I don't think this is possible... BUT.
As someone who was recently educated about this - remember, the feature freeze has nothing to do with keeping features out of F8 past the feature freeze deadline. It *only* has to do with what features are going to be heavily marketed.
I was confused as well, thinking that the motivation for feature freeze had something to do with preventing de-stabalizing things from being added past the freeze. That is what feature freeze means in many organizations. Not so in fedora. In fedora, de-stabalizing things cannot be added after devel-freeze.
-dmc
On Tue, 04 Sep 2007 17:33:09 -0500 Douglas McClendon dmc.fedora@filteredperception.org wrote:
I was confused as well, thinking that the motivation for feature freeze had something to do with preventing de-stabalizing things from being added past the freeze. That is what feature freeze means in many organizations. Not so in fedora. In fedora, de-stabalizing things cannot be added after devel-freeze.
I guess we're not all messaging the same thing. We'd rather far reaching de-stabalizing feature type stuff doesn't happen after the feature freeze as well. Sometimes it's just hard to tell somebody "No, wait 'till next release."
On Tue, 2007-09-04 at 23:53 +0200, Martin Sourada wrote:
- Improve the system-config-services. Its great tool and has great
potential but its confusing at first look. We need to provide to each service such a description *AND* name that everyone (well, I exaggerate here a little...) will understand it.
See my posting "plans for system-config-services, was: early-gdm redux" on fedora-desktop-list. Basically: yes, s-c-services is confusing to users right now, one thing to make it easier is remove the visual distinction between SysVinit and xinetd based services by way of tabs. I don't think anybody wants to tell s-c-services which type of service shall be configured ;-). That's one thing I want to change for Fedora 9, I've planned more and will hopefully get around to it all.
Nils
Jóhann B. Guðmundsson wrote:
Faster system-start/shutdown! Service need to start on demand rather then during the boot up process or at least if anaconda/kudzu don't detect it don't enable it ( bluetooth, printer service sis etc. ) It's better to have the user to go through setup/installation/initializations process ( they are used to it ) and have faster startup than enable lots of unwanted/unneeded service during startup "for everything works solution"!
I guess the next generation of init-scripts is going to figure out what the user wants. You have a point on the bluetooth/printer item, but the "unwanted" services is just silly.
Application need to be able to adjust firewall to allow access for them selves. We don't like it but they noob user will and if your arguments are, the application will mess up my highly complicated netfilter/iptables firewall, routing rules than your smart enough to be able to *hash* an check box who would disable this feature in system-config-security, or at least offer a wider selection of services to open in s-c-s especially those who need more than just an port opening ( protocol 47 48 50 51 etc.. ). The noob user is not able to create there own *Custom* firewall rules.
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?
I'm almost certain it should have said that if someone enables the webserver service (regardless of what actual software is providing the service), he should be asked whether he wants to open up his firewall for this/these new socket(s).
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?
Let the majority fedora user community decide what should be the default application to use in gnome/kde to open/play/view etc files and which application will come with default installation ( in gnome/kde ), do research in what people are adding/changing/replacing to get better hint of what should be used as default app behavior or better yet let fedora user vote what should be used in new release in fedora ( browser pluggin maybe that would ask user to vote on what ( apps/fetures ) they want to see in next release of fedora vote counted and implemented after dev freeze? ).
I believe we have that already.
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.
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.
( moving the legal liability from fedora to the user, disclaimer or something he has to read, approve and press ok for ). If not move the Fedora HQ to Europe and create a legal and handicapped Fedora spin to be released in the states since everybody is so keen on suing everybody in the states. ( we still have some sanity and dignity left here in Europe, I said some :-) For their defence the states are young as a nation maybe this will grow of them. )
Right. Europe has sanity and dignity but the US don't. Right.
*sigh*
Offer encryption on user sensitive data during install or even by default on hardrive. ( browser cache, email cache etc or maybe offer the user to have his /home on encrypted partion ). What we do ( Surf the web,what we spend our money on etc ) is being monitor/catalog/profiled enough as is. Atleas if somebody gets his hands on your box/drive/laptop lets give him hard time to actually get your data.
May I ask how you imagine the user recovers his data if he looses his private key or passphrase?
Lets try to start do see things from noob user perspective and not advanced/dev user perspective. We advanced/developers can handle our selfs the noob cant!
Best regards Johann B.
Ps. Why was minimal install ( no gui ) removed from anaconda?
It wasn't.
/Fedora by the user for the user.../
*Users*, plural. Thank you.
On Mon, 2007-09-03 at 15:21 +0200, Jeroen van Meeuwen wrote:
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.
I guess he meant rather GPL software that cannot be shipped in U.S. due to patent issues, as most of the software provided by the most widely used third party repos (livna and fresh) is GPL. There are many examples suggesting why this should be as easy as possible - ability to play legally bought DVDs, ability to play mp3, DivX, H.264, ... audio/video. Ability to install mplayer during installation, ability to install gstreamer-plugins-{ugly,bad}...
If we do not support this we loose. And remember, all the things I am talking about are licenced under licences that are acceptable into Fedora, only the damn U.S. wrongly implemented patents for software (where they actually rather hinder progress than encourage it) prohibits us from shipping them with Fedora. Proprietary drivers are there as well, but that's not why we should make these repos easy accessible.
We should encourage usage of FOSS software, but how can we do that when we are prohibited by U.S. laws to ship FOSS software that implements patented things? And no, I cannot play DVDs using vanilla Fedora and no, theora isn't better than H.264 (implemented in FOSS x264 codec) and yes, I can use ogg vorbis instead of mp3, but then my HW player will not play them.
Right. Europe has sanity and dignity but the US don't. Right.
There's a point in it, but nevertheless it's not true. US do sometimes suck, but in other things the EU does as well.
Martin
Martin Sourada wrote:
On Mon, 2007-09-03 at 15:21 +0200, Jeroen van Meeuwen wrote:
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.
I guess he meant rather GPL software that cannot be shipped in U.S. due to patent issues, as most of the software provided by the most widely used third party repos (livna and fresh) is GPL. There are many examples suggesting why this should be as easy as possible - ability to play legally bought DVDs, ability to play mp3, DivX, H.264, ... audio/video. Ability to install mplayer during installation, ability to install gstreamer-plugins-{ugly,bad}...
If a legally bought DVD doesn't play on Fedora, that doesn't mean the real problem lies within Fedora. If you disagree; how does that make it a Fedora problem exactly?
If we do not support this we loose.
We are strong fighters in the army of the Free (as in Freedom, not Gratis). We lose some, but we win an awful lot.
And remember, all the things I am
talking about are licenced under licences that are acceptable into Fedora, only the damn U.S. wrongly implemented patents for software (where they actually rather hinder progress than encourage it) prohibits us from shipping them with Fedora. Proprietary drivers are there as well, but that's not why we should make these repos easy accessible.
We should encourage usage of FOSS software, but how can we do that when we are prohibited by U.S. laws to ship FOSS software that implements patented things? And no, I cannot play DVDs using vanilla Fedora and no, theora isn't better than H.264 (implemented in FOSS x264 codec) and yes, I can use ogg vorbis instead of mp3, but then my HW player will not play them.
Restrictively patented software may, in your and many others' opinion, still be Free; I my opinion, it's not. It may be FOSS, but it isn't Free in the most pure sense of the word; If I can't share what I use, freely, with someone else just because there so happens to be an ocean in between and my buddy is living in the states; that to me isn't free.
No matter how we may differ in opinion though, freedom is essential; I think we all agree on that. Fedora however seems to consider freedom to be /freedom for everyone/, so independent from where you live or what the local law says you can or cannot do. That is what I encourage.
On Mon, 2007-09-03 at 16:31 +0200, Jeroen van Meeuwen wrote:
If a legally bought DVD doesn't play on Fedora, that doesn't mean the real problem lies within Fedora. If you disagree; how does that make it a Fedora problem exactly?
No, but the crowd of people he is talking about will think it is a Fedora problem. In this case it's problem of libdvdcss legality. Yes it is open source software, freely redistributable, but its usage is questionable. As far as I understand wiki page about this [1], it is legal to use it, even in the U.S.
If we do not support this we loose.
We are strong fighters in the army of the Free (as in Freedom, not Gratis). We lose some, but we win an awful lot.
Yes, and software patents, as they are, are hindering our efforts. We cannot ship mp3 support. And why? Free (as in freedom) software for playing and encoding it is available. But software patents take the choice away from us.
And remember, all the things I am
talking about are licenced under licences that are acceptable into Fedora, only the damn U.S. wrongly implemented patents for software (where they actually rather hinder progress than encourage it) prohibits us from shipping them with Fedora. Proprietary drivers are there as well, but that's not why we should make these repos easy accessible.
We should encourage usage of FOSS software, but how can we do that when we are prohibited by U.S. laws to ship FOSS software that implements patented things? And no, I cannot play DVDs using vanilla Fedora and no, theora isn't better than H.264 (implemented in FOSS x264 codec) and yes, I can use ogg vorbis instead of mp3, but then my HW player will not play them.
Restrictively patented software may, in your and many others' opinion, still be Free; I my opinion, it's not. It may be FOSS, but it isn't Free in the most pure sense of the word; If I can't share what I use, freely, with someone else just because there so happens to be an ocean in between and my buddy is living in the states; that to me isn't free.
The mp3 software (for example) itself isn't patented, but as far as I understand the patent thing, it violates the patents. Software patents are just defective by design, but it is not a problem of the idea, it's a problem of the implementation, IMHO.
No matter how we may differ in opinion though, freedom is essential; I think we all agree on that. Fedora however seems to consider freedom to be /freedom for everyone/, so independent from where you live or what the local law says you can or cannot do. That is what I encourage.
Agreed, but it's not our fault, that in some countries people have less freedom from the start (i.e. are not able to use free, as in freedom, software because of some, not very sane, banns). I think we should promote freedom not only by supplying only applications guaranteeing such freedom, but also help to fight for their rights to those, who have them lessened (e.g. in the case of software patents).
Martin
References: [1] http://en.wikipedia.org/wiki/Libdvdcss
PS: the software patents could be a good thing, but if they could apply only to harder things to think out and only to the person who come with the idea. Also patent fees should be paid only in cases where the one who uses the patented thing gain money from it, which FOSS software certainly don't. The current state of things is similar like if you were forced to pay patent fees to wheel-patent-holder (which could be some really big company) if you make your own wheel and give it to your kid for playing.
-- Kind regards,
Jeroen van Meeuwen -kanarip
-- http://www.kanarip.com/ RHCE, LPIC-2, MCP, CCNA C6B0 7FB4 43E6 CDDA D258 F70B 28DE 9FDA 9342 BF08
Jeroen van Meeuwen wrote:
Restrictively patented software may, in your and many others' opinion, still be Free; I my opinion, it's not. It may be FOSS, but it isn't Free in the most pure sense of the word; If I can't share what I use, freely, with someone else just because there so happens to be an ocean in between and my buddy is living in the states; that to me isn't free.
But surprisingly, nobody makes any effort to share the burden of system administration, which is why so few people use unix-like systems and why there are endless discussions like this of what packages should and shouldn't be installed or bundled in some small set of configuration choices that aren't going to fit everyone or be exactly right for any purpose.
What we really need is a push-button way for anyone who thinks they have built a system that is well configured for some particular use to publish his installed package list - and perhaps add a repository in the odd case that he needed something not in the usual repositories. Then anyone else should be able to read through the descriptions of the purposes for these configurations and why the admin that created them believes his setup is the best, pick one, and automatically get the same set of packages installed on his own computer - and periodically repeat to track the updates. This would eliminate about 90% of the reasons for having multiple distributions with confusing differences and give the effect of having an expert system administrator tuning each installation for its intended use.
If free software distribution was really about sharing instead of providing a complex base to sell support and services, I think something like this would have been done long ago.
Les Mikesell wrote:
Jeroen van Meeuwen wrote:
Restrictively patented software may, in your and many others' opinion, still be Free; I my opinion, it's not. It may be FOSS, but it isn't Free in the most pure sense of the word; If I can't share what I use, freely, with someone else just because there so happens to be an ocean in between and my buddy is living in the states; that to me isn't free.
But surprisingly, nobody makes any effort to share the burden of system administration, which is why so few people use unix-like systems and why there are endless discussions like this of what packages should and shouldn't be installed or bundled in some small set of configuration choices that aren't going to fit everyone or be exactly right for any purpose.
I'm sorry, you should not have read "If I can't share what I use" as:
"If I cannot publish a list of my installed software and their settings"
rather then
"I'm using something that is free here, but once I start using it elsewhere it may be illegal or I might get sued."
What we really need is a push-button way for anyone who thinks they have built a system that is well configured for some particular use to publish his installed package list - and perhaps add a repository in the odd case that he needed something not in the usual repositories. Then anyone else should be able to read through the descriptions of the purposes for these configurations and why the admin that created them believes his setup is the best, pick one, and automatically get the same set of packages installed on his own computer - and periodically repeat to track the updates. This would eliminate about 90% of the reasons for having multiple distributions with confusing differences and give the effect of having an expert system administrator tuning each installation for its intended use.
If you're gonna build profiles of what software is suited for what purpose, along with the ideal settings, I'm curious what a user would think of a 3-million-profiles-website he can choose the most fit profile from.
Jeroen van Meeuwen wrote:
Restrictively patented software may, in your and many others' opinion, still be Free; I my opinion, it's not. It may be FOSS, but it isn't Free in the most pure sense of the word; If I can't share what I use, freely, with someone else just because there so happens to be an ocean in between and my buddy is living in the states; that to me isn't free.
But surprisingly, nobody makes any effort to share the burden of system administration, which is why so few people use unix-like systems and why there are endless discussions like this of what packages should and shouldn't be installed or bundled in some small set of configuration choices that aren't going to fit everyone or be exactly right for any purpose.
I'm sorry, you should not have read "If I can't share what I use" as:
"If I cannot publish a list of my installed software and their settings"
rather then
"I'm using something that is free here, but once I start using it elsewhere it may be illegal or I might get sued."
My take on it is that there is a lot of work that can be shared with no legal interference and no one bothers to do it. Why not solve the problem that can be solved easily first?
What we really need is a push-button way for anyone who thinks they have built a system that is well configured for some particular use to publish his installed package list - and perhaps add a repository in the odd case that he needed something not in the usual repositories. Then anyone else should be able to read through the descriptions of the purposes for these configurations and why the admin that created them believes his setup is the best, pick one, and automatically get the same set of packages installed on his own computer - and periodically repeat to track the updates. This would eliminate about 90% of the reasons for having multiple distributions with confusing differences and give the effect of having an expert system administrator tuning each installation for its intended use.
If you're gonna build profiles of what software is suited for what purpose, along with the ideal settings, I'm curious what a user would think of a 3-million-profiles-website he can choose the most fit profile from.
It's approximately the same problem as deciding what song to listen to, or what news story to read next, something people do all the time, and more useful than wading through the gazillion different distributions on distrowatch, each trying to be a general purpose solution not really matched to any specific use. I doubt if there are 3 million people arrogant enough to call themselves experts, though. There are probably a few hundred configurations that an expert sysadmin would build for 99% of uses and the good ones would sort themselves out by reputation and be improved by user feedback. The base distribution could then just concentrate on getting all the programs into a repository and keeping their interfaces compatible so you didn't have to throw everything out to update.
On Mon, 2007-09-03 at 12:02 -0500, Les Mikesell wrote:
I doubt if there are 3 million people arrogant enough to call themselves experts, though. There are probably a few hundred configurations that an expert sysadmin would build for 99% of uses and the good ones would sort themselves out by reputation and be improved by user feedback. The base distribution could then just concentrate on getting all the programs into a repository and keeping their interfaces compatible so you didn't have to throw everything out to update.
You have heard about how Fedora has built an infrastructure to allow very easily to create "spins", what do you think that has been built for ?
From another email: If free software distribution was really about sharing instead of providing a complex base to sell support and services, I think something like this would have been done long ago."
Can you spare us this ridiculous rhetoric ?
Fedora is now built to make it easy to build spins. Just publishing a list of packages and let it die in oblivion is not going to help anybody. An expert willing to help others can instead build a spin and really benefit other people, by providing them with a targeted distribution without caring about packaging, but just about how to select and put together packages and making sure you can build an installable system, which is what your are asking for.
Simo.
Simo Sorce wrote:
On Mon, 2007-09-03 at 12:02 -0500, Les Mikesell wrote:
I doubt if there are 3 million people arrogant enough to call themselves experts, though. There are probably a few hundred configurations that an expert sysadmin would build for 99% of uses and the good ones would sort themselves out by reputation and be improved by user feedback. The base distribution could then just concentrate on getting all the programs into a repository and keeping their interfaces compatible so you didn't have to throw everything out to update.
You have heard about how Fedora has built an infrastructure to allow very easily to create "spins", what do you think that has been built for ?
You don't get it - I'm not interested in yet another limited set of choices on a custom CD that is already outdated by the time you download it. I'd like to see a framework to track an expertly-maintained system with little extra effort for the person doing the maintenance and none on the ones following it. If the admin adds or updates packages, the next update of the tracking machines should do the same.
From another email: If free software distribution was really about sharing instead of providing a complex base to sell support and services, I think something like this would have been done long ago."
Can you spare us this ridiculous rhetoric ?
It is an overgeneralization, but not ridiculous. You can choose between distributions funded by support/service subscriptions or ones that don't care much about the user experience and just warehouse the code. I think we'd be better off with a way to share the support/service work and make user experiences reproducible in any quantity.
Fedora is now built to make it easy to build spins. Just publishing a list of packages and let it die in oblivion is not going to help anybody.
Yes, that's exactly my point - the mechanism must permit tracking the continuous changes and updates made by the expert.
An expert willing to help others can instead build a spin and really benefit other people, by providing them with a targeted distribution without caring about packaging, but just about how to select and put together packages and making sure you can build an installable system, which is what your are asking for.
No, that will be wrong by the time it reaches a user's hands. The mechanism I want is a minimal install that gets yum or an equivalent on the internet. From there you pick an expert and a purpose for your machine and automatically get the set of packages installed in a tested, known-to-work, configuration just like an enterprise IT department might build for their desktops. Don't like it? Just pick a different one and the package manager would adjust the installed packages to match. Even if you have to try several know-working setups to get something you like it will be vastly easier than individually testing thousands of programs in all possible combinations yourself, and once you find a working master system you could always have an equally nicely working copy of it.
Jeroen van Meeuwen wrote:
Jóhann B. Guðmundsson wrote:
Faster system-start/shutdown! Service need to start on demand rather then during the boot up process or at least if anaconda/kudzu don't detect it don't enable it ( bluetooth, printer service sis etc. ) It's better to have the user to go through setup/installation/initializations process ( they are used to it ) and have faster startup than enable lots of unwanted/unneeded service during startup "for everything works solution"!
I guess the next generation of init-scripts is going to figure out what the user wants. You have a point on the bluetooth/printer item, but the "unwanted" services is just silly.
Application need to be able to adjust firewall to allow access for them selves. We don't like it but they noob user will and if your arguments are, the application will mess up my highly complicated netfilter/iptables firewall, routing rules than your smart enough to be able to *hash* an check box who would disable this feature in system-config-security, or at least offer a wider selection of services to open in s-c-s especially those who need more than just an port opening ( protocol 47 48 50 51 etc.. ). The noob user is not able to create there own *Custom* firewall rules.
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
I'm almost certain it should have said that if someone enables the webserver service (regardless of what actual software is providing the service), he should be asked whether he wants to open up his firewall for this/these new socket(s).
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
Let the majority fedora user community decide what should be the default application to use in gnome/kde to open/play/view etc files and which application will come with default installation ( in gnome/kde ), do research in what people are adding/changing/replacing to get better hint of what should be used as default app behavior or better yet let fedora user vote what should be used in new release in fedora ( browser pluggin maybe that would ask user to vote on what ( apps/fetures ) they want to see in next release of fedora vote counted and implemented after dev freeze? ).
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...
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 )
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...
( moving the legal liability from fedora to the user, disclaimer or something he has to read, approve and press ok for ). If not move the Fedora HQ to Europe and create a legal and handicapped Fedora spin to be released in the states since everybody is so keen on suing everybody in the states. ( we still have some sanity and dignity left here in Europe, I said some :-) For their defence the states are young as a nation maybe this will grow of them. )
Right. Europe has sanity and dignity but the US don't. Right.
*sigh*
Offer encryption on user sensitive data during install or even by default on hardrive. ( browser cache, email cache etc or maybe offer the user to have his /home on encrypted partion ). What we do ( Surf the web,what we spend our money on etc ) is being monitor/catalog/profiled enough as is. Atleas if somebody gets his hands on your box/drive/laptop lets give him hard time to actually get your data.
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..
Lets try to start do see things from noob user perspective and not advanced/dev user perspective. We advanced/developers can handle our selfs the noob cant!
Best regards Johann B.
Ps. Why was minimal install ( no gui ) removed from anaconda?
It wasn't.
/Fedora by the user for the user.../
*Users*, plural. Thank you.
Best regards Johann B.
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.
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.
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.
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 wrote:
Let's not forget to take the noob user perspective on things regarding my thread..
Somehow I think we do have users in mind somewhere, when trying to develop, build and release this distribution, along with it's new software we create and all new techniques we adopt, but somehow every once in a while someone seems to forget that this "noob user perspective" is not what the key audience of Fedora has.
I have my own strong feelings on a lot of the issues you mentioned. And I would like for there to be discussion on them, but a few things need to be considered.
These threads are hardly ever constructive.
Could we first have a discussion on some ground rules, etc to make these kind of discussions fruitful?
Could people suspend emotionally driven responses and keep things as technical as possible?
I'd rather we spend a month figuring out _how_ to have these discussions in a constructive manner, than have several of these threads.
Am Montag, den 03.09.2007, 14:15 -0500 schrieb Arthur Pemberton:
I have my own strong feelings on a lot of the issues you mentioned. And I would like for there to be discussion on them, but a few things need to be considered.
These threads are hardly ever constructive.
Could we first have a discussion on some ground rules, etc to make these kind of discussions fruitful?
Could people suspend emotionally driven responses and keep things as technical as possible?
I'd rather we spend a month figuring out _how_ to have these discussions in a constructive manner, than have several of these threads.
Well a wiki-based discussion was once suggested as a possible method, but the reason why the discussion fails is because there are too many points to address.
On 9/3/07, nodata lsof@nodata.co.uk wrote:
Am Montag, den 03.09.2007, 14:15 -0500 schrieb Arthur Pemberton:
I have my own strong feelings on a lot of the issues you mentioned. And I would like for there to be discussion on them, but a few things need to be considered.
These threads are hardly ever constructive.
Could we first have a discussion on some ground rules, etc to make these kind of discussions fruitful?
Could people suspend emotionally driven responses and keep things as technical as possible?
I'd rather we spend a month figuring out _how_ to have these discussions in a constructive manner, than have several of these threads.
Well a wiki-based discussion was once suggested as a possible method, but the reason why the discussion fails is because there are too many points to address.
Well could some respected individual divide and conqueror these discussions? I think we can and will benefit.
-
"Jóhann B. Guðmundsson" -
Arthur Pemberton -
Colin Walters -
Douglas McClendon -
Hans de Goede -
Jef Spaleta -
Jeremy Katz -
Jeroen van Meeuwen -
Jesse Keating -
Les Mikesell -
Martin Sourada -
Nils Philippsen -
nodata -
Rahul Sundaram -
Simo Sorce -
Stewart Adam