Re: Windows 10 S
On 5/11/2017 11:01 AM, Rory O'Farrell wrote: > I cam across this thread on an Ubuntu forum > https://ubuntuforums.org/showthread.php?t=2360989 > > The gist of it is that Win 10 S (out of the box) will not run 32 bit > applications. > > I have not delved into the depths of Windows 10 and Microsoft policy, being a > contented linux user, but if the reports in that thread are true ought we not > seriously consider a 64 bit OpenOffice? (trying a second time, as I don't think my first attempt made it to the list) I don't think that it's about 32-bit vs 64-bit, it's about not running native old-style win32 apps, and only allowing new UWP apps. The apps can still be 32 or 64 bits, but must be UWP and live in the Windows Store - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Windows 10 S
On 5/11/2017 11:01 AM, Rory O'Farrell wrote: > I cam across this thread on an Ubuntu forum > https://ubuntuforums.org/showthread.php?t=2360989 > > The gist of it is that Win 10 S (out of the box) will not run 32 bit > applications. > > I have not delved into the depths of Windows 10 and Microsoft policy, being a > contented linux user, but if the reports in that thread are true ought we not > seriously consider a 64 bit OpenOffice? > I don't think that it's about 32-bit vs 64-bit, it's about not running native old-style win32 apps, and only allowing new UWP apps. The apps can still be 32 or 64 bits, but must be UWP and live in the Windows Store - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [www] [SUGGEST] Change Native Language to Dropdown/select box
On 13/05/2014 12:44, Tal Daniel wrote: I'd like to suggest to replace the Native Language link, on www.openoffice.org menu to a more visible dropbox. E.g. Product | Download | ... | Lanauge: [English ] I believe users are more accustomed to select their language from a select box, rather than clicking native language (I remember I had a hard time, as a beginner OpenOffice site visitor to understand what does this link mean). This would also allow faster move to a translated version of the site, for people who prefer to read it in their language. + Another suggestion is to move the suggested dropdown box above the menu bar, somewhere near the search box. Tal +1 for both ideas - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: please I would like to contact a real person for Open Office Writer project
Forwarded from the community list... On 27/01/2014 00:26, Arnaldo Carbone arnycarb...@gmail.com wrote: Hi there; it is so difficult to contact you! everytime I tryed to do it, I had an automatic failure message back! please contact me! Arnaldo - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Precompiled headers
On 21/01/2014 10:09, Andre Fischer wrote: On 21.01.2014 08:57, Andre Fischer wrote: Yesterday I was asked whether the use of precompiled headers had any benefit on the compilation speed. I thought the answer would be yes but I was not sure. So I did some tests. And the difference is huge. I compiled sw/ with make -sr -j8 on a i7 s2720 (2.2GHz), 8GB Ram laptop. One important addition: precompiled headers are only supported on Windows (my experiment took place on Windows7). I guess the other systems are fast enough without precompiled headers. Also, I'm not an expert, but I think that there's a difference for release artifacts whether or not you compile with PCH. I know that the chromium project, for example, recommends PCH for debug builds, but for final releases, removing PCH is a big part of the optimizations... Issac - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Precompiled headers
On 21/01/2014 13:56, Andre Fischer wrote: On 21.01.2014 09:25, Issac Goldstand wrote: On 21/01/2014 10:09, Andre Fischer wrote: On 21.01.2014 08:57, Andre Fischer wrote: Yesterday I was asked whether the use of precompiled headers had any benefit on the compilation speed. I thought the answer would be yes but I was not sure. So I did some tests. And the difference is huge. I compiled sw/ with make -sr -j8 on a i7 s2720 (2.2GHz), 8GB Ram laptop. One important addition: precompiled headers are only supported on Windows (my experiment took place on Windows7). I guess the other systems are fast enough without precompiled headers. Also, I'm not an expert, but I think that there's a difference for release artifacts whether or not you compile with PCH. I know that the chromium project, for example, recommends PCH for debug builds, but for final releases, removing PCH is a big part of the optimizations... Good to know. Do you have any pointers? -Andre I don't :(. I only remember having heard about the performance hit once, but lack of Googled information on the subjects suggests that I may be wrong/outdated. About the chromium project, see this link https://code.google.com/p/chromium/wiki/WindowsPrecompiledHeaders which mentions the bit of gospel I mentioned above (by default for non-official builds) without really explaining why the release build doesn't use it by default. Sorry I can't be more helpful, Issac - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Fwd: Fwd: Re: Content Committee, ApacheCon 2014
On 17/12/2013 00:34, Andrea Pescetti wrote: jan i wrote: Being in europe, I dont have the option to participate, but I like the challenge of filling a whole day with AOO, mixing developer and end user themes. Don't let being in Europe hold you back... If it's just ticket prices, that's why the ASF has the TAC http://www.apache.org/travel/ If you feel you can help the community by being there, then TAC will help you be there! There's already a blurb on the TAC page about ACNA 2014, although the summary is that it's not quite time to apply yet. Issac - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [RELEASE]: availability of uploads and synchronize SF mirrors
I can confirm that I see it there On Jul 21, 2013 1:30 PM, Juergen Schmidt jogischm...@gmail.com wrote: Am Sonntag, 21. Juli 2013 um 03:40 schrieb Dave Fisher: On Jul 20, 2013, at 5:10 PM, Marcus (OOo) wrote: Am 07/20/2013 12:45 PM, schrieb Marcus (OOo): Here a little update what I can see: 1. https://sourceforge.net/projects/openofficeorg.mirror/files/4.0.0/binaries/ The builds seem to be completely received on SourceForge. So, for me it's done. 2. http://www.apache.org/dist/ No openoffice directory and therefore no binary and source builds. Maybe Juergen and Infra are still working on this. I'll look again today evening/tomorrow morning (European timezone). This is unchanged. There is a thread on the infrastructure ML that includes Juergen about this. Apparently it is there, but not there. This may have something to do with apache mirroring between US and Europe. I would suggest that you go on IRC #asfinfra and ask about this situation and not assume one way or another. INFRA-6568 is closed now, it should be there now. Please check ... Sorry I don't have more time Juergen Thanks, Dave At the end it seems that we won't have source files available when we annouce the release. Is this any kind of stopper? The source is available as usual via SVN access. So, I don't know. If not then I would unstage the dirs/files on SourceForge and therefore make the AOO 4.0 release visible for the world. And update the download webpages. As the announcement is planned for Monday I will do this on Sunday evening (European time). Any objections? Marcus Am 07/19/2013 05:16 PM, schrieb Jürgen Schmidt: The vote closed successful and I have once again uploaded the files in the dist are on the people server. /www/www.apache.org/dist/openoffice/4.0.0 The relevant files for SF are under /www/www.apache.org/dist/extgernaldist/openoffice/4.0.0 I hope the rsync url works now, if not please contact the infra people directly. rsync Url: rsync.apache.org::apache-dist-external A complete file list can you find here http://people.apache.org/~jsc/aoo4.0_files_dist-openoffice-4.0.0.txt http://people.apache.org/~jsc/aoo4.0_files_dist-externaldist-openoffice-4.0.0.txt As I mentioned earlier I will be not available until next week Thursday. But I hope I can follow the release a little bit to have some fun with you all together ;-) Juergen - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Proposal: Improve security by limiting committer access in SVN
On 03/04/2013 16:13, Rob Weir wrote: On Wed, Apr 3, 2013 at 9:06 AM, janI j...@apache.org wrote: On 3 April 2013 14:39, Rob Weir robw...@apache.org wrote: We're starting to take a deeper look at what is required to integrate code signing into the OpenOffice build and release process. As you probably know operating systems, especially Windows and MacOS, are now checking for digital signatures and by default prevent users from installing programs that are not signed. We see similar checks being integrated into anti-virus scanners and even web browsers now. One of the things that has come out in discussions is how large a target OpenOffice is, to hackers. We're on track to have 50 million downloads in our first year. If someone is able to get a virus or a trojan into our code, they have the ability to cause a huge amount of damage. And if we are also signing our code, then this damage can propagate even faster, since the OS's let down their guard somewhat when dealing with signed code. (Signed code == trust). Of course, none of this has ever happened with OpenOffice, but with the stature and reach we have, it is reasonable to believe that we could be a target of opportunity for someone wishing to cause trouble. We should always keep this in mind and make sure that we are taking reasonable precautions to prevent this from happening. One vulnerability, in theory, is that we have over 100 committers (123 to be exact) who have permission to modify the source code in Subversion. Each account is protected by a self-selected passcode. It is not clear to me that we even have requirements on password complexity or expiration policies. In any case, the weakness of this approach is not necessarily what you might think -- brute force attack on the password. If someone wants to initiate a spear phishing attack against a committer, it would be something like: 1) Standard phishing: a spoofed note from Apache Infra, with some invented story that asks you to change your password but first enter your old one for confirmation. It leads you to a fake, non-Apache website. 2) If you use the same passcode on multiple web services and one of them is compromised, say by retrieving the passcode hashes, then it is easy to do offline dictionary attacks (rainbow tables, etc.) and figure out your Apache password. 3) If you lose control of your laptop, at a conference, bar, hotel, whatever, even temporarily, someone can gain access to your Subversion account, via applications that cache credentials, like TortoiseSVN. 4) Similar to #3, but by taking control of your laptop via remote means, i.e., via a virus loaded on to your machine via another vulnerability. None of these things have happened to us yet, but all of these things are possible. So how do we reduce this risk? There are a few things we do or should be doing already. 1) Be careful on the machines that you use Subversion from. Treat it like a machine where you access your bank account from. If you are visiting risky sites or downloading and installing software from dubious places, then you are putting your Apache account at risk. 2) Use a high-complexity Apache passcode, one not used by you on any other service. 3) Change your passcode periodically, say every 90 days. 4) On laptops be sure to set a strong login password, but also where available also a separate harddrive password. These should also be strong passwords, not reused, and should be periodically changed. For those who are building binaries for distribution, the above guidance is even more critical. Of course, we also protect the code through our CTR process. All active coders should be subscribed to the commits list and should be reviewing the changes that are made there. Trust the code, not the person. Remember, if we ever are attacked then it will be through someone's compromised account. So if you see an odd check-in, say, from Juergen, don't just accept it saying Juergen knows what he is doing. If it is odd, then it should be challenged. All of the above should already be going on today. But I'd like to propose one change to our current process that will, I think, greatly increase security. This would be to restrict SVN authorization for the code to only the subset of committers who are actively coding. We should give this authorization freely to committers who request it. But today we have 123 committers, some of whom have never used Subversion, and some (like me) who edit /site and /ooo-site but never touch the code. So we probably have 90 or more accounts that don't need access to the source code tree. Since such used accounts are unlikely to be following the best practices outlined above (changing passwords periodically, etc.) then they are even more risky. We lose nothing by removing authorization for those users, in order to reduce the risk profile. Of course, on request
Re: Which version of MSVC Express?
On 21/01/2013 01:32, Ariel Constenla-Haile wrote: as stated in the building guide, the Visual Studio 2008. Apache Committers had a MSD subscription that, AFAIK - I don't have the subscription -, gives you access to the Pro Edition and other stuff (I'm not sure if it is valid for this year, the announce was made at the beginning of 2012). Regards It's probably still in effect, and our MS liaison will likely announce the renewal for 2013 in the next 6-8 weeks, given it being close to a year since the 2012 ones went out. Any committer can apply for it AFAIK, though there are a limited number of licenses. Issac
