-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/02/2014 09:58 PM, Máirín Duffy wrote:
Hi,
On 02/28/2014 01:55 PM, Stephen Gallagher wrote:
If you have serious concerns, please raise them immediately.
I'll +1 but my concerns are as follows:
- The Accessibility section makes no statements about Cockpit's
a11y or required state of a11y; is the web ui designed in such a way to be usable by those using screen readers? I've not used it but with the general popularity if JS frameworks that aren't necessarily screen-reader friendly it is a concern.
This is a really good question, actually. I'm CCing the Cockpit development list to get a response from them.
That being said, I think our accessibility efforts in the first release need to be "best reasonable effort". We want to support them, but we need to figure out where our limited resources are best spent in the short term. In the medium to long term, this becomes vastly more important.
- Encryption - I think this was raised elsewhere in the thread but
we should probably have a section to talk about encryption support (altho we missed this in PRD :-/) This would affect the filesystem and install defaults specifications.
I'd actually be slightly in favor of leaving encryption support to the custom path, for several reasons:
1) Encrypting a filesystem means that startup/reboot cannot be handled unattended. Someone will need to provide a password (or insert security device, etc.)
2) Servers in the "pets" category tend to remain running all the time. Encryption is only useful when the drive has been removed from the machine.
2b) Even if the drive is encrypted only for theft protection, in order to accomplish unattended install, the admin will have to customize the mechanism they use to provide the decryption key, in which case they're likely doing a custom install of the filesystem anyway.
3) While much less so than it once was, encryption requires CPU time to be used on I/O, which is often wasteful in a server environment.
So I'd suggest that Fedora Server recommends the use of LUKS for disk encryption and makes it available in the custom configuration path only.
Thoughts?
- Appearance - ok maybe this is stupid but it would be nice to
have installed and configured by default a nice console font like inconsolata or something like that with reasonable fallbacks for i18n.
Perfectly reasonable. Mind if I phrase it as:
"The Fedora Server team will consult with the Fedora Design Team to select a suitable console font."
- Backup - we talk about roles req lists of things to back up - do
we have a blessed backup system(s) we support tying into?
No, we've discussed that in the past. We don't currently want to try to dictate that (though in the future we may provide a Role for such a solution). At present, what we want to do is provide a programmatic interface for a backup solution to learn dynamically what we want it to back up (rather than requiring admins to maintain a whitelist themselves).
On 03/03/2014 02:00 PM, Stephen Gallagher wrote:
On 03/02/2014 09:58 PM, Máirín Duffy wrote:
I'll +1 but my concerns are as follows:
- The Accessibility section makes no statements about Cockpit's
a11y or required state of a11y; is the web ui designed in such a way to be usable by those using screen readers? I've not used it but with the general popularity if JS frameworks that aren't necessarily screen-reader friendly it is a concern.
This is a really good question, actually. I'm CCing the Cockpit development list to get a response from them.
Hi, good question! We in the Cockpit team haven't really talked about before. Thanks for bringing it up! The framework we're using in Cockpit is Patternfly [1] that buils on top of Bootstrap [2], and it seems there is a plugin available that makes things vastly better for screen readers. https://www.paypal-engineering.com/2014/01/28/bootstrap-accessibility-plugin...
1. https://www.patternfly.org/ 2. http://getbootstrap.com/
- Andreas
cockpit-devel@lists.fedorahosted.org
-
Andreas Nilsson -
Stephen Gallagher