4 ms·

As a French-speaking person, I cannot tell you how much the announcement[0] that after 5.8, basic utilities, including mg(1), will be UTF-8 ready pleases me. I

As a French-speaking person, I cannot tell you how much the announcement[0] that after 5.8, basic utilities, including mg(1), will be UTF-8 ready pleases me. I'm a huge Emacs fan, but I like to use mg(1) for quick edits and this is very exciting news for me! [0] http://undeadly.org/cgi?action=article&sid=20150722182236 http://undeadly.org/cgi?action=article&sid=20150722182236

busterarm 11y ago
Funny thing about Emacs and OpenBSD... ...Emacs is the only package in the entire ports tree that can't use ASLR.
- kaoD 11y ago
  Why is it?
  - dietrichepp 11y ago
    Not sure, but I can tell you that Emacs is weird inside, in a lot of ways. It runs an interpreter for a language that nobody else uses, which has been heavily optimized because otherwise Emacs would be too slow. Then they use tricks to speed up executable loading, like loading Emacs and then writing the contents of memory to disk, so it can be loaded more quickly the next time.
    - busterarm 11y ago
      Yes, from what I hear, basically it's Emacs' issue.
- 4ad 11y ago
  That can't possibly be true, the Go port also doesn't use ASLR.
  - busterarm 11y ago
    I'm just quoting what an OpenBSD dev mentioned to me. I guess there could be more.
david-given 11y ago
AIUI, one of the big problems with using UTF-8 universally is that it's rather unfriendly to Asian character sets. e.g. apparently UTF-8 is three times bigger than TIS-620 for Thai characters (from http://www.micro-isv.asia/2009/03/why-not-use-utf-8-for-everything http://www.micro-isv.asia/2009/03/why-not-use-utf-8-for-ever...).
- stsp 11y ago
  I spoke to several Japanese OpenBSD developers about this. They told me UTF-8 is not perfect but it's the least of available evils. They'd be more happy with a UTF-8 capable base system than with the current state of things where with few exceptions UTF-8 is supported only by 3rd party applications installed from ports. And note that this is about system locales which mostly concerns libc APIs. Applications are still free to support additional character sets via other means (e.g. iconv). For some problems a locale may not be the best answer. For instance, during these conversations I learned that Japanese android phones expose filenames as Shift-JIS which cannot be listed by ls(1) when the phone's filesystem is mounted in OpenBSD. In my opinion what's needed is not a system locale that switches everything to Shift-JIS but a translation layer which presents filenames as UTF-8 to the rest of the system. Perhaps a fuse filesystem module which links to libiconv in userspace to perform the necessary translation, and presents the result at an auxiliary mount point.

busterarm 11y ago

Funny thing about Emacs and OpenBSD... ...Emacs is the only package in the entire ports tree that can't use ASLR.

kaoD 11y ago
Why is it?
- dietrichepp 11y ago
  Not sure, but I can tell you that Emacs is weird inside, in a lot of ways. It runs an interpreter for a language that nobody else uses, which has been heavily optimized because otherwise Emacs would be too slow. Then they use tricks to speed up executable loading, like loading Emacs and then writing the contents of memory to disk, so it can be loaded more quickly the next time.
  - busterarm 11y ago
    Yes, from what I hear, basically it's Emacs' issue.
4ad 11y ago
That can't possibly be true, the Go port also doesn't use ASLR.
- busterarm 11y ago
  I'm just quoting what an OpenBSD dev mentioned to me. I guess there could be more.

david-given 11y ago

AIUI, one of the big problems with using UTF-8 universally is that it's rather unfriendly to Asian character sets. e.g. apparently UTF-8 is three times bigger than TIS-620 for Thai characters (from http://www.micro-isv.asia/2009/03/why-not-use-utf-8-for-everything http://www.micro-isv.asia/2009/03/why-not-use-utf-8-for-ever...).

stsp 11y ago
I spoke to several Japanese OpenBSD developers about this. They told me UTF-8 is not perfect but it's the least of available evils. They'd be more happy with a UTF-8 capable base system than with the current state of things where with few exceptions UTF-8 is supported only by 3rd party applications installed from ports. And note that this is about system locales which mostly concerns libc APIs. Applications are still free to support additional character sets via other means (e.g. iconv). For some problems a locale may not be the best answer. For instance, during these conversations I learned that Japanese android phones expose filenames as Shift-JIS which cannot be listed by ls(1) when the phone's filesystem is mounted in OpenBSD. In my opinion what's needed is not a system locale that switches everything to Shift-JIS but a translation layer which presents filenames as UTF-8 to the rest of the system. Perhaps a fuse filesystem module which links to libiconv in userspace to perform the necessary translation, and presents the result at an auxiliary mount point.