From nobody Wed Jan 31 22:44:49 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TQHD94LCqz58SZ4 for ; Wed, 31 Jan 2024 22:44:57 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [104.236.120.189]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TQHD86PKFz436Z for ; Wed, 31 Jan 2024 22:44:56 +0000 (UTC) (envelope-from karl@denninger.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=denninger.net; spf=pass (mx1.freebsd.org: domain of karl@denninger.net designates 104.236.120.189 as permitted sender) smtp.mailfrom=karl@denninger.net Received: from denninger.net (096-033-195-197.res.spectrum.com [96.33.195.197]) by colo1.denninger.net (Postfix) with ESMTP id CE55E2110B2 for ; Wed, 31 Jan 2024 17:45:16 -0500 (EST) Received: from [192.168.10.25] (D15.Denninger.Net [192.168.10.25]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id B982737C2F6 for ; Wed, 31 Jan 2024 17:44:49 -0500 (EST) Message-ID: Date: Wed, 31 Jan 2024 17:44:49 -0500 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: The Case for Rust (in the base system) Content-Language: en-US To: freebsd-hackers@freebsd.org References: <3DCF4236-4DFA-448E-A378-DE04EC147B50@FreeBSD.org> <20240201000734.83a86f486691276e533530e4@dec.sakura.ne.jp> <782FA00C-3B90-49C8-85F7-AF784F42A3CC@FreeBSD.org> <6af9739e-2be3-d0a8-bcb0-fd63196246e5@puchar.net> From: Karl Denninger In-Reply-To: <6af9739e-2be3-d0a8-bcb0-fd63196246e5@puchar.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms000907060606090808030305" X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.67 / 15.00]; SIGNED_SMIME(-2.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.997]; NEURAL_HAM_LONG(-0.99)[-0.992]; DMARC_POLICY_ALLOW(-0.50)[denninger.net,none]; NEURAL_SPAM_MEDIUM(0.20)[0.204]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; R_SPF_ALLOW(-0.20)[+mx]; XM_UA_NO_VERSION(0.01)[]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:14061, ipnet:104.236.64.0/18, country:US]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; FREEFALL_USER(0.00)[karl]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; HAS_ATTACHMENT(0.00)[] X-Rspamd-Queue-Id: 4TQHD86PKFz436Z This is a cryptographically signed message in MIME format. --------------ms000907060606090808030305 Content-Type: multipart/alternative; boundary="------------G78ozs15shRv04Umr5KvQjYb" --------------G78ozs15shRv04Umr5KvQjYb Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 1/31/2024 16:31, Wojciech Puchar wrote: > > On Wed, 31 Jan 2024, David Chisnall wrote: > >> On 31 Jan 2024, at 15:07, Tomoaki AOKI >> wrote: >>> >>> First of all, NO MEMORY-SAFE language can write codes using volatile >>> memory objects, most notably, memory-mapped I/O and/or DMA driver. >> >> The first half of that is obvious nonsense.  Memory-mapped I/O is not >> intrinsically unsafe, from a memory-safety perspective. Even Java has >> volatile objects and Sun Labs used Java for device drivers twenty >> years ago.  Having a memory-safe interface for MMIO is helpful. > This line above is complete nonsense. as most of that discussion. > > ...... > I've read most of this thread thus far and have a few observations.  Mind you this is coming from a 60 year old who was programming in assembler before I had a driver's license and has run FreeBSD both personally and professionally all the way back to the mid 1990s when MCSNet ran on it both on our back end and in customer-facing use.  I'll try to keep this somewhat-brief as I'm not really interested in a catfight. Languages come and go in popularity.  Some concepts endure, but implementations often not-so-much.  Sometimes decisions made a long time ago wind up locking you up "almost forever"; witness Android as an example.  Sometimes much less-consequential decisions (e.g. to use something from packages) bites you; Digital Ocean, for example, no longer "supports" FreeBSD at all. They used to up to FreeBSD 11. Why no longer? Maybe (can't be proved) because they used "jq" to parse the cloud config files, that's a package, their cloud init script /forgot /to put the "REQUIRE" for "ldconfig" in there to make sure adding local libraries was run first /and thus on an upgrade to a newer version if rcorder spat things out differently it could try to run the cloud init before the linker knew where the shared libraries were and thus break all networking, appearing to be entirely dead. /It took me 30 seconds to find this and eight bytes of inserted text to fix it, I reported it back to DO but.... they haven't changed their mind on forward support.  Sad too because their infrastructure works really well with FreeBSD (in fact my blog has been on it for several years now and still is on 13.2p8) The idea of having a language at compile time cover for foolish mistakes or lack of attention sounds good but as we have all seen with various data breaches whenever you think you've made something idiot-proof Murphy comes up with a better idiot.  I'm not much of a fan of the premise that with more-rapid development of working code one also gets both correct and more-efficient code, and again I post up Android (which I do write app code for) as a counter-example. Bringing a language into base IMHO ought to be very carefully considered /as removing it might be impossible down the road and ultimately FreeBSD could pay horribly for that. /This is especially true when the language itself isn't simply a language; it also means that in practical use it has a huge number of other outside resources (e.g. containers or whatever) particularly when they're not static and might have compilation issues down the road.  I personally hate coding for Android (although I do it) because its essentially required to use their IDE to be productive at all and it changes out from under you whenever Google decides to deprecate or change something; do we really want to bring that sort of situation into FreeBSD?  In addition I've been bit several times by the "floating dependency" thing with with php over the years -- php itself is of course a package but there are /other /packages that use it as a language and a huge number of modules that are brought in to handle various things from xml parsing to database connectivity. Several times over the years I've upgraded php using "pkg upgrade" and immediately had one or more packages that allegedly should be forward-compatible break with missing dependencies that weren't originally there and thus "pkg" had no knowledge of them.  These are the risks you accept when using a "language + other things" model in all respects; it can happen with code linked against openssl, for example (e.g. Postgres was a recent one built from source that required a bit of effort to resolve as I build that in a production environment I'm responsible for from source.) I would argue that this risk in a core component should not be accepted without a showing of extraordinary benefit in the context of improvement of some element that the core system includes now, and even then only if the container problem can be resolved in a way that will not wind up screwing the ability to build -- including a retrospective release -- on an indefinite basis down the road.  That is, if you can't (for example) check out 14.x five years from now /and build it from source /then its not acceptable, which implies that whatever containerized assets are required they must also be in said tree and versioned in same without having to be pulled from an external source (which may have changed such that backward compatibility to build has been lost.)  This could get into more than just a technical question if there are potential licensing issues with those "must have to build" assets as well. My 2 bits of contribution; carry on. -- Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------G78ozs15shRv04Umr5KvQjYb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 1/31/2024 16:31, Wojciech Puchar wrote:

On Wed, 31 Jan 2024, David Chisnall wrote:

On 31 Jan 2024, at 15:07, Tomoaki AOKI <junchoon@dec.sakura.ne.jp> wrote:

First of all, NO MEMORY-SAFE language can write codes using volatile
memory objects, most notably, memory-mapped I/O and/or DMA driver.

The first half of that is obvious nonsense.  Memory-mapped I/O is not intrinsically unsafe, from a memory-safety perspective.  Even Java has volatile objects and Sun Labs used Java for device drivers twenty years ago.  Having a memory-safe interface for MMIO is helpful.
This line above is complete nonsense. as most of that discussion.

......

I've read most of this thread thus far and have a few observations.  Mind you this is coming from a 60 year old who was programming in assembler before I had a driver's license and has run FreeBSD both personally and professionally all the way back to the mid 1990s when MCSNet ran on it both on our back end and in customer-facing use.  I'll try to keep this somewhat-brief as I'm not really interested in a catfight.

Languages come and go in popularity.  Some concepts endure, but implementations often not-so-much.  Sometimes decisions made a long time ago wind up locking you up "almost forever"; witness Android as an example.  Sometimes much less-consequential decisions (e.g. to use something from packages) bites you; Digital Ocean, for example, no longer "supports" FreeBSD at all. They used to up to FreeBSD 11. Why no longer? Maybe (can't be proved) because they used "jq" to parse the cloud config files, that's a package, their cloud init script forgot to put the "REQUIRE" for "ldconfig" in there to make sure adding local libraries was run first and thus on an upgrade to a newer version if rcorder spat things out differently it could try to run the cloud init before the linker knew where the shared libraries were and thus break all networking, appearing to be entirely dead.  It took me 30 seconds to find this and eight bytes of inserted text to fix it, I reported it back to DO but.... they haven't changed their mind on forward support.  Sad too because their infrastructure works really well with FreeBSD (in fact my blog has been on it for several years now and still is on 13.2p8)

The idea of having a language at compile time cover for foolish mistakes or lack of attention sounds good but as we have all seen with various data breaches whenever you think you've made something idiot-proof Murphy comes up with a better idiot.  I'm not much of a fan of the premise that with more-rapid development of working code one also gets both correct and more-efficient code, and again I post up Android (which I do write app code for) as a counter-example.

Bringing a language into base IMHO ought to be very carefully considered as removing it might be impossible down the road and ultimately FreeBSD could pay horribly for that.  This is especially true when the language itself isn't simply a language; it also means that in practical use it has a huge number of other outside resources (e.g. containers or whatever) particularly when they're not static and might have compilation issues down the road.  I personally hate coding for Android (although I do it) because its essentially required to use their IDE to be productive at all and it changes out from under you whenever Google decides to deprecate or change something; do we really want to bring that sort of situation into FreeBSD?  In addition I've been bit several times by the "floating dependency" thing with with php over the years -- php itself is of course a package but there are other packages that use it as a language and a huge number of modules that are brought in to handle various things from xml parsing to database connectivity.  Several times over the years I've upgraded php using "pkg upgrade" and immediately had one or more packages that allegedly should be forward-compatible break with missing dependencies that weren't originally there and thus "pkg" had no knowledge of them.  These are the risks you accept when using a "language + other things" model in all respects; it can happen with code linked against openssl, for example (e.g. Postgres was a recent one built from source that required a bit of effort to resolve as I build that in a production environment I'm responsible for from source.)

I would argue that this risk in a core component should not be accepted without a showing of extraordinary benefit in the context of improvement of some element that the core system includes now, and even then only if the container problem can be resolved in a way that will not wind up screwing the ability to build -- including a retrospective release -- on an indefinite basis down the road.  That is, if you can't (for example) check out 14.x five years from now and build it from source then its not acceptable, which implies that whatever containerized assets are required they must also be in said tree and versioned in same without having to be pulled from an external source (which may have changed such that backward compatibility to build has been lost.)  This could get into more than just a technical question if there are potential licensing issues with those "must have to build" assets as well.

My 2 bits of contribution; carry on.

--
Karl Denninger
karl@denninger.net
The Market Ticker
[S/MIME encrypted email preferred]
--------------G78ozs15shRv04Umr5KvQjYb-- --------------ms000907060606090808030305 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC DbowggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4 MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1 ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD 0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24 SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E 6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5 c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9 oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK 17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/ Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA 6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBxIwggT6oAMCAQICEgLG8yH4PQFdbd9x Ugmpzl1jXzANBgkqhkiG9w0BAQsFADB7MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlk YTEZMBcGA1UECgwQQ3VkYSBTeXN0ZW1zIExMQzEYMBYGA1UECwwPQ3VkYSBTeXN0ZW1zIENB MSUwIwYDVQQDDBxDdWRhIFN5c3RlbXMgTExDIDIwMTcgSW50IENBMB4XDTIyMDYyOTE2MTYz NloXDTI3MDYyODE2MTYzNlowOjELMAkGA1UEBhMCVVMxEjAQBgNVBAgMCVRlbm5lc3NlZTEX MBUGA1UEAwwOS2FybCBEZW5uaW5nZXIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoIC AQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvW ZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B 3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTgy+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYI XgVVPgfZZrbJJb5HWOQpvvhILpPCD3xsYJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMi WapsatKm8mxuOOGOEBhAoTVTwUHlMNTg6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMb NQm1mWREQhw3axgGLSntjjnznJr5vsvXSYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZM qa20JLAF1YagutDiMRURU23iWS7bA9tMcXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5 CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1l y+5ZOZbxBAZZMod4y4b4FiRUhRI97r9lCxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY 2BlA7ExM8XShMd9bRPZrNTokPQPUCWCgCdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEE MDAuMCwGCCsGAQUFBzABhiBodHRwOi8vb2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNV HRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYI KwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCGSAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBD bGllbnQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNV HSMEgcIwgb+AFF3AXsKnjdPND5+bxVECGKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQ MA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5 c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lz dGVtcyBMTEMgMjAxNyBDQYITAORIioIQzl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJs QGRlbm5pbmdlci5uZXQwDQYJKoZIhvcNAQELBQADggIBAKquc7cu0xc8FNtAQauZvocDzWQj 7HG9YvMbWnMi+ckhiA3rdW5NwWg0HBhBho1YlnqV+ntCVE2L8ezohHWm+KAdfXgpraL86Vsn 3ywNlZu/3COMpo2ALuHln8YQtH3Y8ebvzKMdlf2b5WB+7mOFIxXIr4AnNOLKCkq5ZhzC6JW6 Jvw3P0csiGa3UrfatYID5NvPgkaQvEgimEjG3psZqwQTL2Wxohvw783PrDt3wS0XeNhvQ61g 3QJFZKuv+bmGH3YBSPo1t6NUGAr+JozX5lDihB8JGkBt/NwdYec49a08uL0BbPaAJ7NjuIPG 7Y0Ak7PXZT37yx/Zla9PzLMJFgbelOkaatdzbblMZPDEVZ27l4lGMmV83Lm3YP17sdAyS/Wp mav7WmJUkQ9iuIKzSpdc82i9Mfujl1vbBtwtkHNPPtKuulIFM4ZwrPKjlVdLqTSqD8m9yHEi Y0PuAooq63OpJWF6hvMaiIPBWEAVIaDW9uG0MshLl9DnHnMyrJTfuC33Z9mOGMz7dRBjJd5Y W02xAzYnUuEBOpj+LQv5R8XIFMHFXktqEKvQrXeM2RU+PcZqKOBkTktxBLn3NI5VfA15Jk0c 5V5XcOqo3p2hvrwvXrinrb2pEREnoqmfrkXT3zOq5Y6ryRH8u734lGEF0dILXzoV4PM7XFit oTePoEjmMYIFBDCCBQACAQEwgZEwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGEx GTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTEl MCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQQISAsbzIfg9AV1t33FSCanO XWNfMA0GCWCGSAFlAwQCAwUAoIICQzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0yNDAxMzEyMjQ0NDlaME8GCSqGSIb3DQEJBDFCBEBZ/ZFFFG+FCGL/nM9w XxJCg2fsoRK6bDUpF3tQG9qqM+q1AWjAXWw7HvO9WzebRdExzdtWAns+qWQwgFO2YqjNMGwG CSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAO BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw gaIGCSsGAQQBgjcQBDGBlDCBkTB7MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTEZ MBcGA1UECgwQQ3VkYSBTeXN0ZW1zIExMQzEYMBYGA1UECwwPQ3VkYSBTeXN0ZW1zIENBMSUw IwYDVQQDDBxDdWRhIFN5c3RlbXMgTExDIDIwMTcgSW50IENBAhICxvMh+D0BXW3fcVIJqc5d Y18wgaQGCyqGSIb3DQEJEAILMYGUoIGRMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9y aWRhMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMg Q0ExJTAjBgNVBAMMHEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0ECEgLG8yH4PQFdbd9x Ugmpzl1jXzANBgkqhkiG9w0BAQEFAASCAgBAdapxvD2fZ2BhDw1EakjUWY0k/nVRmw0lp5cb ouRW41EgFnQVvL0ihXGlnYQG5mEamh6KvqbbZ3HiIp/xoWIemRtAufNDN9lseaqbJwBZtbXM lKGvnfG5Zi/gvzFkVnCQaM6cifZceugczcdCZGlvfJW1/af+uqSTeitlATUTh7wztN2SHFFT 5u50Xhaj6RV6dha6a/kfulfkUl5T1K4h8Jq4r21t7eIcX+BeJneH7wFCIyAsvse+6z3WnnRe JB9+foNdTBPpt2CuM4ffzq22EyJBWf1hoyVO+1MuAh0AyKnPW7Rhn6jcxeWfqEAItjmtQsr5 23KjvEUKiV/zQt7lLNY1lqravSikfgQxptTqEbvAo9wQ5QCs2SHBqFxXIEMGwHRB/IueofiT TlVWlrCV9fhxcknH5M8ax9SZEKtGKYQ5yIw35pY8PTxapiiydom+4jcmDMo85X7Y7SBKhDFy UqDtWr2YUfx2k5rvu250U4o1XBhk+GHW4K0ASACfsqurwF4ZNnamKuap7+On3EimVu7Tupli u9vmAKQwZXts4FDer7hoCpylp/xWWivYmXJ5BpZlMEygvG3PF8YEWpBLxOSkSaWiAp3sV/wX gM84cB77acHvB6uzjze3bMdveuQWCpIJqxt59hfQQ8UtmhoiHCN6j6qPjRvgMGC+icvzpgAA AAAAAA== --------------ms000907060606090808030305--