Real Estate Industry Email List
Good Day, I found that your company is going to exhibit in tradeshow "HR Tech 2017". Would you be interested to sell your product and services as per your required location? If yes, please let me know your targets so that I can get you potential clients with their company name, email address, contact name, website and more information as per your requirement. Specialties: CEOs, CFOs, COOs Chief Talent Officers CIOs, CTOs Vice Presidents and Directors of: HR, HRMS, Talent Management, Recruitment, Compensation, Training & Learning, Employee Relations, Communications, Human Capital Management, IT & Technology, Development, Benefits, Payroll and many more across globe. Please let me know below format so that I can send you some free sample file for your review. Target Industry: _ (Any Industry) Target Geography: ___ (Any) Target Job Title: _ (Any) Waiting for your response. Thanks, Caitlin Brown SR. Marketing Manager --- This email has been checked for viruses by AVG. http://www.avg.com ___ freebsd-mono@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-mono To unsubscribe, send any mail to "freebsd-mono-unsubscr...@freebsd.org"
Re: Help Wanted - Work with MSFT and help finish the port of .NET Core to FreeBSD
On Monday, 4 September 2017 10:54:21 Geoffrey Huntley wrote: > See https://www.youtube.com/watch?v=NHllisWOCpU and > https://twitter.com/GeoffreyHuntley/status/904227946084294656 Hi Geoffrey It is great to hear there is more interest in finishing the port of .NET Core to FreeBSD (and, I hope, to have ports living in the Port's Collection). Would it be possible for you to put me (and the mono@ mailing list) in touch with Karel and Tomas - I'm not on Twitter. I'll reply to this email (dropping ports@ and advocacy@) with more technical details. Regards David signature.asc Description: This is a digitally signed message part.
Re: Help Wanted - Work with MSFT and help finish the port of .NET Core to FreeBSD
On Tuesday, 5 September 2017 20:52:10 David Naylor wrote: > On Monday, 4 September 2017 10:54:21 Geoffrey Huntley wrote: > > See https://www.youtube.com/watch?v=NHllisWOCpU and > > https://twitter.com/GeoffreyHuntley/status/904227946084294656 > > Hi Geoffrey > > It is great to hear there is more interest in finishing the port of .NET > Core to FreeBSD (and, I hope, to have ports living in the Port's > Collection). > > Would it be possible for you to put me (and the mono@ mailing list) in touch > with Karel and Tomas - I'm not on Twitter. > > I'll reply to this email (dropping ports@ and advocacy@) with more technical > details. There has been multiple attempts to finish the porting, my effort can be found here [1]. Alas, I haven't looked at it in a while so I'm not sure how things look on the .NET Core 2.0 front. As it stands I have: # git clone https://github.com/DragonSA/dotnet # make -C dotnet/dotnet-sdk install # gdb /usr/local/dotnet/bootstrap/dotnet (gdb) run --version (gdb) bt #0 0x00080299065b in pthread_mutex_destroy () from /lib/libthr.so.3 #1 0x00080298f919 in pthread_mutex_lock () from /lib/libthr.so.3 #2 0x00081d093c4d in GetCollatorFromSortHandle () from /usr/local/dotnet/bootstrap/shared/Microsoft.NETCore.App/1.0.3/System.Globalization.Native.so #3 0x00081d093dcf in GlobalizationNative_CompareString () from /usr/local/dotnet/bootstrap/shared/Microsoft.NETCore.App/1.0.3/System.Globalization.Native.so #8 0x00080291cae8 in vtable for InlinedCallFrame () from /usr/local/dotnet/bootstrap/shared/Microsoft.NETCore.App/1.0.3/libcoreclr.so The main challenges have been: 1) how to bootstrap the build: i) mscorlib.dll (and friends) need to be compiled on Windows ii) all other dlls also need to be compiled on Windows (without crossgen) 2) nuget downloads conflict with the approach required by the Ports Collection Some initial ideas I have to overcome the issues are: a) improve the Ports Collection to handle nuget packages (WIP) (2) b) have dotnet-sdk distributed without crossgen applied (1ii) c) adopt mono's approach of creating a single dll for all platforms (1i) d) allow bootstrapping of .NET Core with mono (1) e) fix the core dump mentioned above :-P f) abstract the bootstrapping process (i.e. init-tools.sh) [1] https://github.com/DragonSA/dotnet Regards David signature.asc Description: This is a digitally signed message part.
Re: Update on porting mono 5
On Saturday, 2 September 2017 11:03:59 Romain Tartière wrote: > On Fri, Aug 25, 2017 at 09:41:43PM +0200, David Naylor wrote: > > [2] A general discussion needs to be had around nuget packages. How do we > > consume them? > > > > i) as downloads with each port containing a copy > > > > ii) local ports with consistency across the Ports Collections > > > > iii) A mixture of the above (i.e. (ii) is there is a native component, > > otherwise (i)) > > I prefer (ii) as I think it gives the end user the best leverage to patch > > issues with nuget packages locally (and to get updates without waiting on > > a) upstream, and b) us/ports maintainer). However, at this point that > > option is at 0% progress. > > Yeah, it's a problem that is broader and broader… and for which I don't > think a universal solution works :-/ At a minimum, any nuget package that contains a native (i.e. compiled) portion needs to be a Port. > With local copies (i) you end-up with a lot of duplication (Go > applications are a good example of how this can become quite stupid, I > recently created a port for a go application, the source tarball > includes the source of all dependencies, and everything is bundled in a > 13MB executable (that only depends on libc.so and libthr.so). > > With a port per dependency (ii), you sooner or later have to handle > conflicts between dependencies (port A needs foo-1.0.0 but port B needs > foo-2.0.0) and it can get tricky. I think we can already handle that (see all the Qt ports). I'm not sure what currently happens when A depends on B and C but B and C depend on different versions of D. Does .NET just use the latest version of D? > I only have experience with programming with Ruby as a language that has > similar problem. I ended at only installing system tools using the > FreeBSD ports (e.g. puppet, vagrant, passenger), and for applications I > actually use, I just grab the source, and use bundler to gather all > dependencies as the user running the software, therefore I end up having > something similar to (i) without using the port system. > > My weak Windows development experience learned me to put all dll of an > application in the application directory. If it's still a good advice, > I guess that each application should have it's copy of all it's > dependencies, and therefore each port should install a bundle of all > what is required by it. In my ideal situation all dlls will be installed in the GAC (or just linked to where they are installed). If I read this [1] correctly, Debian advocates for all dlls to be registered in the GAC. > Another problem with nugets packages is that you only get binaries, > right? That means that is something goes really wrong, there is no way > to audit the source code of what led to disaster. The problem is > similar with the few Java projects I gave a look at. My feeling is that > this is even worst :-( Ruby being interpreted, there is no such > problems. > > I am not enough involved in Java nor .Net to think about mitigations of > this issue. This is my primary concern, how does one take control when each port manages its own private dependencies. [1] https://pkg-mono.alioth.debian.org/cli-policy/ signature.asc Description: This is a digitally signed message part.
Re: Update on porting mono 5
On Saturday, 2 September 2017 11:55:15 Robert Alegrid wrote: > I apologize in advance if I formatted this message incorrectly or addressed > it incorrectly. This is the first time I'm posting to a mailing list, so I > have no real idea how I should be doing it. Looks good to me :-), welcome to the list. > I also just program as a hobby (and mostly on Windows at that), so that > should be taken in consideration as well. > > On Saturday, 2 September 2017 7:03 PM, Romain Tartière wrote: > >On Fri, Aug 25, 2017 at 09:41:43PM +0200, David Naylor wrote: > >> [2] A general discussion needs to be had around nuget packages. How do > >> we > >> consume them? > >> > >> i) as downloads with each port containing a copy > >> ii) local ports with consistency across the Ports Collections > >> > >> iii) A mixture of the above (i.e. (ii) is there is a native component, > >> otherwise (i)) > >> I prefer (ii) as I think it gives the end user the best leverage to patch > >> issues with nuget packages locally (and to get updates without waiting on > >> a) upstream, and b) us/ports maintainer). However, at this point that > >> option is at 0% progress. > > It's possible for NuGet to use a local directory as a feed: > https://docs.microsoft.com/en-us/nuget/hosting-packages/local-feeds > If you add the local feed earlier in the list of sources, it should pick up > your locally built packages instead of fetching it from the internet. Good to know, but this will still require patching each port to use a local feed. > NuGet also maintains a cache of packages that it uses to restore from when > it doesn't have an internet connection to work with. I believe this location is $PACKAGES=$HOME/.nuget/packages and is the best approach to provide packages during build phase. Regards signature.asc Description: This is a digitally signed message part.
Fwd: Help Wanted - Work with MSFT and help finish the port of .NET Core to FreeBSD
Yuri, I apologize, I thought this went to everyone. I didn't mean to single you out. :) My comments below... Russ -- Forwarded message -- From: Russell Haley Date: Mon, Sep 4, 2017 at 9:29 PM Subject: Re: Help Wanted - Work with MSFT and help finish the port of .NET Core to FreeBSD To: Yuri On Sun, Sep 3, 2017 at 7:15 PM, Yuri wrote: > On 09/03/17 17:54, Geoffrey Huntley wrote: >> >> Seehttps://www.youtube.com/watch?v=NHllisWOCpU and >> https://twitter.com/GeoffreyHuntley/status/904227946084294656 > > > > Is there a body of software that requires .Net? I never came across anything > great that needed .Net to run. > > In other words, why is this needed and who is going to use it? There are literally millions of DotNet applications that are running in companies of varying sizes around the world that could be easily converted to run on FreeBSD without a user being any the wiser, especially Asp.net applications (a huge chunk of that). There are many companies looking to get DotNet applications off of expensive operating systems and onto cheap FOSS operating systems that require no licensing and very little upgrading. From my experience people looking to convert over from MS.Net to Mono have always had *some reason* to not make the switch (real or imagined). DotNet Core offers the first truly cross platform opportunity for most Microsoft shops. Further, FreeBSD offers a unique opportunity for companies to take application code and close it off as an appliance (virtual or physical) and protect intellectual property in a way that GPL licensed OSes can't. This can be easily seen in Sony Playstation 3 & 4 and the NetApp appliance as models for very profitable closed source applications of FreeBSD. I've very effectively run Samba4 on FreeBSD as a complete AD replacement in a small scale test. One could conceivably remove a lot of licensing for Servers and Client Access Licenses by moving over to a FreeBSD based system. As someone with experience in both large scale IT and embedded systems, the RAD application development that DotNet offers is fantastic. It's like building working space shuttles out of Lego. Microsoft lost badly in the OS wars on the phones and is loosing on the cheap tablets as well. The are not gaining much in Web Servers and starting to see losses in IT systems to Linux. The local school system where I am from has moved completely to Ubuntu (and it shows in the three week downtime in their email systems). The MS solution to GNU/Linux and all FOSS is to do what they do best: absorb the technology. They have created the Microsoft Subsystem For Linux, which allows them to natively run Linux system calls in the NT Kernel. They have moved their business model to the cloud and are looking to embrace FOSS just like Amazon and Google do. In order to keep their technologies relevant, they now need to allow DotNet to run on GNU/Linux and other FOSS systems. As someone that embraces all technology, I see this as an excellent thing. Russ ___ freebsd-mono@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-mono To unsubscribe, send any mail to "freebsd-mono-unsubscr...@freebsd.org"
Re: Help Wanted - Work with MSFT and help finish the port of .NET Core to FreeBSD
On Tue, Sep 5, 2017 at 11:52 AM, David Naylor wrote: > On Monday, 4 September 2017 10:54:21 Geoffrey Huntley wrote: >> See https://www.youtube.com/watch?v=NHllisWOCpU and >> https://twitter.com/GeoffreyHuntley/status/904227946084294656 > > Hi Geoffrey > > It is great to hear there is more interest in finishing the port of .NET Core > to FreeBSD (and, I hope, to have ports living in the Port's Collection). > > Would it be possible for you to put me (and the mono@ mailing list) in touch > with Karel and Tomas - I'm not on Twitter. > > I'll reply to this email (dropping ports@ and advocacy@) with more technical > details. > > Regards > > David Just an FYI: I found Karel's email address and dropped him a private message for more information (I also don't use twitter). I wanted to wait for permission before publishing any information on the mono mailing list (including his email address etc). I had the DotNet CORE and CLR running on FreeBSD using the instructions posted way back when. I also asked about more information a few months back on the DotNet forums but I can't find the message. The response was that "nothing was happening at the time". http://forums.dotnetfoundation.org/ Cheers, Russ ___ freebsd-mono@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-mono To unsubscribe, send any mail to "freebsd-mono-unsubscr...@freebsd.org"
Re: Update on porting mono 5
On Saturday, 2 September 2017 07:40:28 Russell Haley wrote: > On Sat, Sep 2, 2017 at 4:55 AM, Robert Alegrid wrote: > >>Another problem with nugets packages is that you only get binaries, > >>right? That means that is something goes really wrong, there is no way > >>to audit the source code of what led to disaster. The problem is > >>similar with the few Java projects I gave a look at. My feeling is that > >>this is even worst :-( Ruby being interpreted, there is no such > >>problems. > >> > > NuGet packages have in their manifest a field to specify where the source > > code lives. However, since it's optional and is just a URL to the > > repository, it probably doesn't help much for this use case. > > Is this coming up because of the use of Nuget during the build process > or is it because of general concern for the user? The first issue is a practical one: with ports now requiring tens of nuget packages (and lock files generated by nuget - so we cannot cheat) it is becoming an issue with porting. The second issue is more a philosophical one around concern for the user. The discussion below covers this concern and doesn't change the immediate plans for handling nuget packages (as bundled dependencies). > As a professional DotNet developer, I agree with Mr. Alegrid for the > most part. Nuget is designed as a binary tool because DotNet is a > binary based system. It comes from a user mindset, not an opensource > mindset. Because of that, I question why we are having this > discussion. Is it not the decision of the user/developer how they > would like to use their package manager? Also, it is their choice if > they prefer to use sources. I sometimes do both. Stable packages from > Nuget and others from source. The question here is how easy is it for the developer to change the binaries they consume? A good way to illustrate the problem is the Heart Bleed bug in OpenSSL. Currently on FreeBSD the libopenssl.so file is centrally accessible, so to fix the bug just requires fixing the centrally stored libopenssl.so file. However, if all programs that used libopenssl.so had their own local copy (say statically compiled, or otherwise) the fix would be a headache. In the land of Ports, we would need to patch (or wait for an update of) every single port that used OpenSSL. This is obviously a problematic situation to be in. Philosophically it is one of the differences between Windows (everyone bundles all their dependencies) and Unix [1] (all dependencies are centrally available). > Nuget is designed for local, per project resources. It is particularly > effective when developing across many developers as it will go and get > the packages for you automatically at build time (wicked cool feature, > which seamlessly mixes source with binary distribution). Items that > are supposed to live system wide are to be stored in the General > Assembly Cache (GAC) and should be designed to be put there. You can > get Nuget to drop things in the GAC but have not used this feature. > The GAC is designed around large scale software deployments which, > sadly, I don't think will ever apply to mono on FreeBSD. In a limited sense, nuget is redundant on FreeBSD thanks to the Ports Collection and pkg - but I do see the need on Windows and more generally in the .NET ecosystem. Do you perhaps have any links that detail how nuget can store dlls in the GAC? > Worrying about per-port repositories for Nuget is not a thing because > the manifest within DotNet applications decides what runtime version > of the assembly to use at build time so it is necessarily per-port. > Also, DotNet can have hard or soft links (I forget the terminology) to > required assemblies in the sense they can specify to use any version > or a specific version, and can specify if the assemblies require to be > signed (i.e. verified by the authors credentials against a trusted > list). The GAC handles versioning for system level assemblies and if > you overwrite a required version in your local repository it's a > development error that you need to sort yourself. Unfortunately, we do need to worry about per ports dependencies. In the practical case it is around the need to download the nuget packages within the Ports Collections framework (so we get security protection, etc), before the build phase. Ports are not allowed interest access during build. Regards [1] I know PC-BSD, for a while at least, also bundles all dependencies within a PBI? signature.asc Description: This is a digitally signed message part.
Re: Update on porting mono 5
* I apologize for being lazy and linking to stack exchange answers. In a perfect world I would go and look this stuff up in the Nuget documentation. It leaves open the possibility of miss-interpretation (by me) and possible wrong answers. On Tue, Sep 5, 2017 at 12:25 PM, David Naylor wrote: > On Saturday, 2 September 2017 07:40:28 Russell Haley wrote: >> On Sat, Sep 2, 2017 at 4:55 AM, Robert Alegrid > wrote: >> >>Another problem with nugets packages is that you only get binaries, >> >>right? That means that is something goes really wrong, there is no way >> >>to audit the source code of what led to disaster. The problem is >> >>similar with the few Java projects I gave a look at. My feeling is that >> >>this is even worst :-( Ruby being interpreted, there is no such >> >>problems. >> >> >> > NuGet packages have in their manifest a field to specify where the source >> > code lives. However, since it's optional and is just a URL to the >> > repository, it probably doesn't help much for this use case. >> >> Is this coming up because of the use of Nuget during the build process >> or is it because of general concern for the user? > > The first issue is a practical one: with ports now requiring tens of nuget > packages (and lock files generated by nuget - so we cannot cheat) it is > becoming an issue with porting. Agreed. A poor deployment strategy by the Mono team IMHO. > The second issue is more a philosophical one around concern for the user. The > discussion below covers this concern and doesn't change the immediate plans > for handling nuget packages (as bundled dependencies). > >> As a professional DotNet developer, I agree with Mr. Alegrid for the >> most part. Nuget is designed as a binary tool because DotNet is a >> binary based system. It comes from a user mindset, not an opensource >> mindset. Because of that, I question why we are having this >> discussion. Is it not the decision of the user/developer how they >> would like to use their package manager? Also, it is their choice if >> they prefer to use sources. I sometimes do both. Stable packages from >> Nuget and others from source. > > The question here is how easy is it for the developer to change the binaries > they consume? > > A good way to illustrate the problem is the Heart Bleed bug in OpenSSL. > Currently on FreeBSD the libopenssl.so file is centrally accessible, so to fix > the bug just requires fixing the centrally stored libopenssl.so file. > However, if all programs that used libopenssl.so had their own local copy (say > statically compiled, or otherwise) the fix would be a headache. In the land > of Ports, we would need to patch (or wait for an update of) every single port > that used OpenSSL. > > This is obviously a problematic situation to be in. Philosophically it is one > of the differences between Windows (everyone bundles all their dependencies) > and Unix [1] (all dependencies are centrally available). My perspective is that the entire point of Nuget is allow a developer to intrinsically link his project to a binary file of a specific version and be confident that the package manager will always download and link to that version (see the answer here: https://stackoverflow.com/questions/19817378/is-it-possible-to-add-update-assemblies-to-the-gac-via-a-nuget-package.). If the developer *wants* to always use the latest version, that is something the developer can configure (see https://stackoverflow.com/questions/24765802/nuget-spec-dependencies-get-latest-version). Though I agree with your point, I don't agree that this is a Unix/Windows difference. There are plenty of packages and applications on Unix where the developer chose not to use the global version and "Library Hell" is a real thing that FreeBSD handles very manually by specifying the version in the port name (Lua is a great example having lua51, lua52 and lua53). Conversely, Windows spent a long time using the registry (shudder) and the GAC has existed since the inception of DotNet. For DotNet, the decision to move to per-installation libraries has been a conscious choice made irrespective of OS philosophy. >> Nuget is designed for local, per project resources. It is particularly >> effective when developing across many developers as it will go and get >> the packages for you automatically at build time (wicked cool feature, >> which seamlessly mixes source with binary distribution). Items that >> are supposed to live system wide are to be stored in the General >> Assembly Cache (GAC) and should be designed to be put there. You can >> get Nuget to drop things in the GAC but have not used this feature. >> The GAC is designed around large scale software deployments which, >> sadly, I don't think will ever apply to mono on FreeBSD. > > In a limited sense, nuget is redundant on FreeBSD thanks to the Ports > Collection and pkg - but I do see the need on Windows and more generally in > the .NET ecosystem. > > Do you perhaps have any links that detail how nu
