Research Impact Conference; July 2016, Manchester
Research Impact Conference: Delivering Excellence 5th July 2016, Manchester Conference Centre, Manchester Research Impact: Delivering Excellence will explore REF case studies and testimonials to help researchers effectively measure and evidence impact, offering practical guidance on delivering high quality submissions across research projects. As announced in the current Spending Review, the UK government is taking forward a review of the Research Excellence Framework (REF) that is being led by Lord Stern. The review will draw on evaluation from the previous REF exercise to ensure future research funding is allocated more efficiently, offers greater rewards for excellence and reduces the administrative burden. By better examining research aims and keeping up to date with new digital technologies it could be possible for research groups based within the NHS to collate with academic successes. With new sources of funding for the NHS recently launching, such as Innovate UKs Digital Innovation in the Sharing Economy, it is time that the NHS reward excellence and enhance research evaluation models in order to support the development of future, lifesaving, technical advancements. View the overview at: http://www.ofenews.co.uk/link.php?M=5595793&N=2830&L=418&F=T] Speakers Include: Dr Simon Kerridge, Chair, Association of Research Managers and Administrators; Director of Research Services, University of Kent (confirmed) Aaron Porter, Director of External Affairs, National Centre for Universities & Business (NCUB) (confirmed) Dr Vicky Jones, REF Deputy Manager at HEFCE (confirmed) Sarah Parks, Analyst, RAND Europe (confirmed) Professor Roger Falconer, School of Engineering, Cardiff University; Member Panel B (confirmed) Dr Catriona Manville, Senior Adviser, RAND Europe (confirmed) View the programme at: http://www.ofenews.co.uk/link.php?M=5595793&N=2830&L=419&F=T Topics of discussion on the day Welcome and introduction The changing landscape for research funding The Metric Tide Writing REF bids and submissions: Improving quality and diversity Research Excellence: What makes a submission stand out? High Performing Research Units Benefits of attending: Learn about the future direction for research funding and assessment as the government reviews of governance, structure and evaluation develop. Practical advice and solutions to assist universities in improving the quality of REF submissions and interdisciplinary research. Explore new models and future iterations of research performance and evaluation. The impact of the Research Excellence Framework and how the assessment process will inform future submissions and assessment. Learn how to best evidence impact, excellence and diversity across a variety of disciplines and research projects. Insight into the intended and unintended consequences of the REF exercise. Assistance in developing the quality of research outputs and demonstrating originality, significance and rigour in applications. Practical ways of developing research strategies, support for staff and students, and delivering research infrastructures and collaborations. How to benchmark outcomes from Research Excellence Framework assessments. Discover how new models of research, funding and collaboration can support excellence. To register please go to: http://www.ofenews.co.uk/link.php?M=5595793&N=2830&L=420&F=T Regards, Jonathan Smith jonat...@ofenews.co.uk Senior Marketing Executive Open Forum Events 0161 376 9007 This email has been sent to "debian-devel@lists.debian.org" by Open Forum Events. If you're interested in receiving updates about future events from Open Forum Events please click here [http://www.ofenews.co.uk/link.php?M=5595793&N=2830&L=5&F=T]. To unsubscribe from receiving further emails from Open Forum Events please click Unsubscribe [http://www.ofenews.co.uk/link.php?M=5595793&N=2830&L=6&F=T]
tzdate 2016d update (released 2016-04-17) for future time stamps
Hi! A new version of tzdata is available, tzdata2016d (released 2016-04-17). The latest version affecting future time stamps: America/Caracas Asia/Magadan Asia/Tomsk In Venezuela we are very interested in the update of this package on Debian 7 and 8 will be soon, because we have many machines installed with this operating system and its derivatives. We thank the team of Debian developers for all the support they can offer. Regards, -- German Cardozo Chirinos ~ memento mori ~ :wq!
Re: tzdate 2016d update (released 2016-04-17) for future time stamps
On Tue, 2016-04-19 08:08:22 -0430, German Cardozo wrote: > Hi! > > A new version of tzdata is available, tzdata2016d (released > 2016-04-17). > > The latest version affecting future time stamps: > America/Caracas > Asia/Magadan > Asia/Tomsk > > In Venezuela we are very interested in the update of this package > on Debian 7 and 8 will be soon, because we have many machines > installed with this operating system and its derivatives. > > We thank the team of Debian developers for all the support they > can offer. > > Regards, > > -- > German Cardozo Chirinos > ~ memento mori ~ https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=821147 signature.asc Description: Digital signature
Re: tzdate 2016d update (released 2016-04-17) for future time stamps
Aníbal Monsalve Salazar escribió: On Tue, 2016-04-19 08:08:22 -0430, German Cardozo wrote: Hi! A new version of tzdata is available, tzdata2016d (released 2016-04-17). The latest version affecting future time stamps: America/Caracas Asia/Magadan Asia/Tomsk In Venezuela we are very interested in the update of this package on Debian 7 and 8 will be soon, because we have many machines installed with this operating system and its derivatives. We thank the team of Debian developers for all the support they can offer. Regards, -- German Cardozo Chirinos ~ memento mori ~ https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=821147 In case you do not get the update on time (e.g. if your machine follows some strict update policy) you can switch from Caracas to La Paz: "Indicó Arreaza que, en aparatos electrónicos y computadoras, usted puede poner la zona horaria de La Paz, Bolivia, que es -4 UTC." Regards Noel Torres er Envite binLkzqPJqdvi.bin Description: Clave PGP pública
Re: Packaging of static libraries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Apr 14, 2016 at 02:57:00PM +0200, Vincent Danjean wrote: > > If users have such specialized needs, I think it is not only reasonable that > > they build their own versions of their libraries; I expect them to prefer > > that. > > So we should make that as easy as possible. I can imagine that Gentoo also > > seems attractive to them, and it may be a good (or even better) solution. > > But > > as Debian, I think the best we can do to help them is to make it easy to > > build > > our packages from source with custom build flags. I'm guessing that we're > > probably talking less than 100 people in the world, maybe less than 10, that > > need this. It makes no sense to put a package in the archive just for them. > > I do not understand where your numbers come from. I understood that this was a very specialized thing that some people in research institutions would want. So I guessed a few people at Cern, for example. There aren't that many projects that are running for months. But it's still a wild guess, and I'm happy to believe you when you have better numbers. How many people do you expect need this? > I also know lots of HPC clusters installed with Debian. If Debian > choose to favor safety wrt to performance (instead of trying to find > a good compromise as currently), it will probably loose some users. It's always a compromise, and you were talking about people who don't want that. Those people will need to build their own libraries. > And no, admins (and most users) do not prefer to recompile software > instead of using the installed one (some users do not have enough > computer science skills to do it and some admins are already > overloaded and will not want to manage a derivative distribution) It's all about priorities. If having optimized libraries is very important, they will train someone to do that. If it is not worth the training, then that's fine, but then it obviously isn't so important. > > And changing the default compiler settings to fit their needs makes even > > less > > sense. > > However, it already occurred : we compile by default with -O2, not > with the compiler default (no -O options). Until now, the Debian > project seems to agree that this is a good tradeoff between > optimization and "code correction". That's not what I meant. You seem to suggest that we should compile for maximum performance, at the cost of security, because some people want that. Or maybe that we offer both options, I'm not sure what you propose. My point is that we should not do that; we decide on the compromise, and if it's too much towards security and away from performance for some people, they need to get a different distribution or compile things themselves. I think we should make it easy for them to do that. But I understand that you think the prospect of a small group of people leaving us over this is unacceptable, and we should try to avoid it even at high cost. I disagree. It's nicer if they want to keep using Debian, and as the universal OS we obviously hope that our system works for everyone. But it's not the end of the world if a small group of users doesn't think so. To clarify that: being the universal OS means to me that we have a good way to use Debian for every situation. It doesn't mean that every user thinks Debian is the best solution for them. Thanks, Bas -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJXFnGKAAoJEJzRfVgHwHE6DKQP/22wUdhkis8hV53571xuGtTn WDpYSKvwK98aodJDUzb70f4ZAncwLSiEdugOq+zmDdNY/ZkT/36qfWxFCakPpa8r N1dxLI7x7kq0K5fdnYj+lLUgLJI97NiwdJPWVun7NE45fDS9zY/9a4XZ8VDTzoZw WdIBaEZgfa2liDn4HCjDPI/j9Nll7h/IAeHFx+l0uB49wS0ydmUxTnYde22oOjXN hQoMBJBENXulCa073XBDJ67O8v7iGFXwR09ZcFixq2lcfvoLzgmAMnuuxhnWL/EQ I4e8ywXog0Mc9vvzCQ0tAPlUhkuzocpLvBArYVMwiFNXVMzmShNH2bh8iaxruG5P 4NUTKI1d/lK2lNt43n1HDBBwULPpPend51+ywbH/FTOtZKyHz88Y4+nuJPogXr0c Ejn+k1/SJ/tLHVCUy1TBQ4W25ns24WIwMBAsOog7McgnS02skG9QCAEmPj+I0KJp BuWsUO806PaU3LmX93l7wgxVOwtNf4JrJsuOB5o3wvhD3asnVeHiiwIaFxGvK3zW eBMl0Gsrbz+dtRKD8Ni3uVtPztxlAZVNgotA3mXWD+00wFu+TrrO74N0IXXLxXRf 7VnmpuYo4ICNmkLdgPFwE/pdzdAxw3xWGH2YLSogwPZoI6uuOa2UmbnEnyLNy/Dy 0mmHlB5r4qxc3zuwzKub =TxnM -END PGP SIGNATURE-
Re: Packaging of static libraries
Le 19/04/2016 19:57, Bas Wijnen a écrit : > You seem to suggest that we should compile for > maximum performance, at the cost of security, because some people want that. No. Reread what I wrote. I think security is important but this is only one thing between many. I'm convinced that we could do a way more secure system by enabling selinux in enforce mode, by running most of service in chroot, virtual machines, containers, by recompile them with tools that check all memory accesses, ... But I'm also sure that all of this is not done (for now, by default in Debian) because other 'things' would suffer too much (performances, usability, ...) whereas this is technically possible. So, any new 'security feature' should be evaluated (as always until now) with respect to the other aspects. The initial argument was: > We in Debian are in a good position to defend our users from the > fallout from this problem. We could change our default compiler > options to favour safety, and provide more traditional semantics. The safety argument was presented as one that dominate all the others. I do *not* deny that the safety is a very strong argument. I just say that other aspects must *also* be evaluated and balanced. And an small increase in safety is not always the best thing for the Debian project if it leads to severe performance/usability/... issues. Regards, Vincent -- Vincent Danjean GPG key ID 0xD17897FA vdanj...@debian.org GPG key fingerprint: 621E 3509 654D D77C 43F5 CA4A F6AE F2AF D178 97FA Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http://people.debian.org/~vdanjean/debian unstable main
Re: Packaging of static libraries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Apr 19, 2016 at 10:13:28PM +0200, Vincent Danjean wrote: > The initial argument was: > > We in Debian are in a good position to defend our users from the > > fallout from this problem. We could change our default compiler > > options to favour safety, and provide more traditional semantics. > > The safety argument was presented as one that dominate all the > others. I disagree. It just says that there is a safety issue and we could improve that situation. This is a public discussion, of course counterarguments about other things, such as performance and usability, are allowed. > I just say that other aspects must *also* be evaluated and balanced. > And an small increase in safety is not always the best thing for the > Debian project if it leads to severe performance/usability/... issues. I agree, and I think everyone does. But at the same time, where we want that balance to be may change with time. The quote above suggests that we may want to shift towards more security. But nowhere does it imply or suggest that there is no balance. Thanks, Bas -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJXFpfsAAoJEJzRfVgHwHE6NeAP/jm7Z8Mrxkvo2UipoCKShQNe 3ig1WMVcnWV/KIlxmMNdYR4Ey10bcBizqKw+htJ/D2gxSqaQChXrLHmZwqaCEpV5 7XMMLJ8oOwLevZSR18UR7L45ncCXrlzqCUaX72LFa9tHDVNc+V1cTT0WwiMCVGT3 gPbsluUGOsbXRHhdj4+C7CnstCItnVKrp0ogXOyDR2S4QFy7vBPEOf+VnD1asOxO Y85FBWyA1RMDdOrhKZJneOrUahICBmTnyzdH/vEwB0EOBwweZgQymZecy85PUIFk za5G2dnQa50DhKua7zH8zSHjfkn6iB4AlO9T8igoXs1ZQuMrfXFto7F+N80TItPW wZKD8jvkrNs5UnkG6WCrn7aXUYsho3DwHvTFtRu6U4S/Q/63WuIWST3JUp8KJNyr uzz0FpnsfgXA8dVfGkrj0rl4igC9xUf1K3suHNxARK0k/oag6TO8bOJ8efcgGLUq kK7Sq+daWpYDMiD/cYjr5dFvC0hQY+AKRPMunhi7pVAoy+ORnCp0jotwCFBa4sWQ 0BdttvTLGDYizwUUW7m97zgdKWNxShMxFjSsGIMkIx7ozq9q3+lsUG/eZODOy/uh 9TOkJiWHAIfHSdg6VtMGZRw1MGe9JtyT5KyCc3j08I56yoSVnv3yYdspe1v9ZnBi iWvO5HSNETQfgFf9SlnI =eyKN -END PGP SIGNATURE-
Re: Packaging of static libraries
On Apr 19 2016, Bas Wijnen wrote: > On Thu, Apr 14, 2016 at 02:57:00PM +0200, Vincent Danjean wrote: >> > If users have such specialized needs, I think it is not only reasonable >> > that >> > they build their own versions of their libraries; I expect them to prefer >> > that. >> > So we should make that as easy as possible. I can imagine that Gentoo also >> > seems attractive to them, and it may be a good (or even better) solution. >> > But >> > as Debian, I think the best we can do to help them is to make it easy to >> > build >> > our packages from source with custom build flags. I'm guessing that we're >> > probably talking less than 100 people in the world, maybe less than 10, >> > that >> > need this. It makes no sense to put a package in the archive just for >> > them. >> >> I do not understand where your numbers come from. > > I understood that this was a very specialized thing that some people in > research institutions would want. So I guessed a few people at Cern, for > example. There aren't that many projects that are running for months. But > it's still a wild guess, and I'm happy to believe you when you have better > numbers. How many people do you expect need this? Random datapoint: there are more than 400 usernames starting with "n" on NERSC, and my UID is above 70k. No matter how interpret this is, it's pretty much guaranteed that the number of people doing HPC is *way* above 100. On the other hand, NERSC also recommends recompiling any application with their compiler. So I'm not taking any position here :-). Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«
New virtual package ‘adventure’
Howdy all, The classic game “Adventure” has an existing implementation in Debian, and I am packaging another implementation (‘python-adventure’) which hews closer to the original PDP-10 implementation's behaviour. I have worked with the maintainer of the existing Debian package ‘bsdgames’, to make the name ‘/usr/games/adventure’ available via the Debian alternatives system. There are many existing implementations of Adventure, with different choices made in details of implementation. I will be providing a second implementation (in ‘colossal-cave-adventure’). We intend to use the ‘adventure’ virtual package name, to declare providing an implementation of the classic game Adventure. -- \“If you can't hear me sometimes, it's because I'm in | `\ parentheses.” —Steven Wright | _o__) | Ben Finney
