Re: nc(1) shutdown(2) typo
On Wed, Mar 20, 2013 at 12:43:37AM +, Creamy wrote: On Tue, Mar 19, 2013 at 06:34:31PM -0600, Theo de Raadt wrote: Using netcat to reliably get data is never going to be appropriate for a production system, IMHO. Wow. You sure do set the bar low. Probably a lot of people are glad that I don't accept that kind of balony. Then make the concept work. Oh, you can't, because it's broken by design. Are you seriously suggesting that an enterprise WAN solution can be built on netcat? -- Creamy No, but at the same time I want my tools to be high quality and predictable, whether I use them for diagnostics or a quick script. -Otto
Adds product ATI RADEON_HD5570
patch attached. ok? hd5570.patch Description: Binary data
Re: nc(1) shutdown(2) typo
Whatever behavior you settle on for netcat, it will break somebody's script somewhere. That is the point I was trying to make. And that right there is your misunderstanding. Currently, it not possible to write a script with nc that works reliably. Every script is already broken now. We're totally agreed on that point. Authors of the scripts in question may be of the opinion that it works for them, and that any change will break it. You are then claiming that it can be fixed. Show me the fix that makes all of the netcat scripts out there in the wild 'just work'. The rest of what you are yapping about does not matter. Could you qualify whether 'the rest of what you are yapping about' covers just this thread, or my subscription to -tech in general? If OpenBSD development is a closed shop, just tell me and I'll happily go back to working in isolation from the rest of you, as I have been for the last few years. If you don't like nc, don't use it. Do you think we care? Why should you? You really mis-understand my whole stance on this. -- Creamy
Re: nc(1) shutdown(2) typo
On Wed, Mar 20, 2013 at 09:21:10AM +0100, Otto Moerbeek wrote: On Wed, Mar 20, 2013 at 12:43:37AM +, Creamy wrote: On Tue, Mar 19, 2013 at 06:34:31PM -0600, Theo de Raadt wrote: Using netcat to reliably get data is never going to be appropriate for a production system, IMHO. Wow. You sure do set the bar low. Probably a lot of people are glad that I don't accept that kind of balony. Then make the concept work. Oh, you can't, because it's broken by design. Are you seriously suggesting that an enterprise WAN solution can be built on netcat? No, but at the same time I want my tools to be high quality and predictable, whether I use them for diagnostics or a quick script. I totally agree - see my later post. Maybe I was wrong to say, 'for a production system', when what I really meant was that it is wrong to use script+netcat as a generic replacement for a socket library. -- Creamy
Re: UPDATE: xkeyboard-config 2.8
On 20/03/13(Wed) 00:03, Alexandr Shadchin wrote: Hi, This update xkeyboard-config to the latest release 2.8. http://koba.devio.us/distfiles/xkeyboard-config-2.8.diff Change: * 18 bugs fixed * Most important change: a lot of materials updated from Oracle (Sun keyboards) * Updated translations Tested on amd64. Comments ? OK ?. Works fine on macppc w/ ADB. ok mpi@
Re: LC_CTYPE for spanish speaking countries
On Tue, Mar 19, 2013 at 06:44:59PM -0500, Vladimir Támara Patiño wrote:
+#http://en.wikipedia.org/wiki/List_of_countries_where_Spanish_is_an_official_language
+ES_COUNTRIES= AR BO CH CO CR CU DO EC ES GQ GT HN MX NI PA PE PR PY SV UY VE
Sorry, but I don't really see the point of this.
All these names are going to map to the same ctype definitions.
That just clutters the /usr/share/locale directory. Why can't people
just use es_ES?
I don't think locale names are standardized, so there should be nothing
that forces us to support a certain set of locale names.
+ES_ENCODINGS= ISO8859-1 ISO8859-15 UTF-8
+.for c in ${ES_COUNTRIES}
+LOCALES += es_${c}.UTF-8
+LOCALESRC_es_${c}.UTF-8 = en_US.UTF-8
+LOCALES += es_${c}.ISO8859-1
+LOCALESRC_es_${c}.ISO8859-1 = en_US.ISO_8859-1
+LOCALES += es_${c}.ISO8859-15
+LOCALESRC_es_${c}.ISO8859-15 = en_US.DIS_8859-15
+.endfor
LOCALES += fa_IR.UTF-8
LOCALESRC_fa_IR.UTF-8 = en_US.UTF-8
Re: Updating src/share/locale/ctype with NetBSD
On Tue, Mar 19, 2013 at 09:44:37PM -0500, Vladimir Támara Patiño wrote: Attached --includes patch for spanish speaking countries. I don't think it makes sense to manually update the en_US.UTF-8 file. Rather, I think we should have a script which generates en_US.UTF-8 from unicode.org XML data files (see http://www.unicode.org/Public/6.2.0/ucdxml/). As a first step, such a script would generate an en_US.UTF-8 file containing the same character definition blocks as the current file, possibly containing corrections within these blocks. In a later step we could think about adding more blocks if doing so would be useful. A suitable scripting language would be Perl since Perl exists in the base system and supports XML parsing. Your diff is adding ctype definitions for character sets which our libc doesn't support, such as euc-jp. I don't see any reason to add such files as long as libc doesn't support the corresponding encodings. I don't even see much reason to add support for additional encodings unless you can provide a convincing reason to do so. UTF-8 should cover most, if not all, needs.
Re: LC_CTYPE for spanish speaking countries
On Wed, Mar 20, 2013 at 2:50 PM, Stefan Sperling s...@openbsd.org wrote:
On Tue, Mar 19, 2013 at 06:44:59PM -0500, Vladimir Támara Patiño wrote:
+#http://en.wikipedia.org/wiki/List_of_countries_where_Spanish_is_an_official_language
+ES_COUNTRIES= AR BO CH CO CR CU DO EC ES GQ GT HN MX NI PA PE PR PY SV UY VE
Sorry, but I don't really see the point of this.
All these names are going to map to the same ctype definitions.
That just clutters the /usr/share/locale directory. Why can't people
just use es_ES?
Because that's wrong. es_VE for ctype alone won't make a difference,
but BSF isn't the same as Euro, is it? (hah) Date formats, etc., are
different. And dictionary files (e.g., spellings for common cities)
are also different.
The way you specify locales, ll_CC.CHARTYPE, where ll is language and
CC is country-code, is unfortunate because it makes unnecesary
duplication for fields where it shouldn't make a difference, like
ctype, but that's just the way it is
I don't think locale names are standardized, so there should be nothing
that forces us to support a certain set of locale names.
+ES_ENCODINGS= ISO8859-1 ISO8859-15 UTF-8
+.for c in ${ES_COUNTRIES}
+LOCALES += es_${c}.UTF-8
+LOCALESRC_es_${c}.UTF-8 = en_US.UTF-8
+LOCALES += es_${c}.ISO8859-1
+LOCALESRC_es_${c}.ISO8859-1 = en_US.ISO_8859-1
+LOCALES += es_${c}.ISO8859-15
+LOCALESRC_es_${c}.ISO8859-15 = en_US.DIS_8859-15
+.endfor
LOCALES += fa_IR.UTF-8
LOCALESRC_fa_IR.UTF-8 = en_US.UTF-8
Re: LC_CTYPE for spanish speaking countries
On Wed, Mar 20, 2013 at 04:50:39PM -0430, Andres Perera wrote: On Wed, Mar 20, 2013 at 2:50 PM, Stefan Sperling s...@openbsd.org wrote: On Tue, Mar 19, 2013 at 06:44:59PM -0500, Vladimir Támara Patiño wrote: +#http://en.wikipedia.org/wiki/List_of_countries_where_Spanish_is_an_official_language +ES_COUNTRIES= AR BO CH CO CR CU DO EC ES GQ GT HN MX NI PA PE PR PY SV UY VE Sorry, but I don't really see the point of this. All these names are going to map to the same ctype definitions. That just clutters the /usr/share/locale directory. Why can't people just use es_ES? Because that's wrong. es_VE for ctype alone won't make a difference, but BSF isn't the same as Euro, is it? (hah) Date formats, etc., are different. And dictionary files (e.g., spellings for common cities) are also different. Yes, but unfortunately OpenBSD's locale implemnentation doesn't yet support much of what you mention above. AFAIK we currently only support the LC_CTYPE locale category. Please show me a real benefit of this change within the current implementation, or extend the implementation to create a benefit. Or you could identify some ports which install message files where adding new spanish locale variants will really make a difference. If such ports exist, I'm happy to add the corresponding locale variants. But I'm not going to bother making no-op changes to the system.
