Re: [osol-discuss] Fwd: [OT] Openindiana mailing list
Harry, I tried entering your email in the subscription form, and there was no problem. I guess there was a typo in the address during your previous attempt to subscribe. If you clicked through the confirmation message, you should be subscribed now. -Albert ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] multibyte support for FTP in Solaris
Hello, I need to know if FTP has support for multibyte languages. Meaning, if the locale is set to be multibyte languages like Japanese/ Chinese, does FTP/FTPD in solaris support it? With Regards, Shilpa. What sort of support? AFAIK, the ftp protocol transfers either raw binary data, or ASCII, or optionally EBCDIC, or perhaps optionally deals with nonstandard byte sizes. I don't see anything in RFC 959 about code conversions other than to/from ASCII; converting multibyte to ASCII would be very lossy (or else fail), I imagine, so I don't think it even tries. The ftpd (server side) has no way of knowing about the locale the client is using, as far as I know. So it can hardly be expected to adapt its behavior. All you can do to get the transfers right is be sure to issue the ftp command binary OR type image OR type binary to be sure that neither end is trying to convert text to/from ASCII. Solaris ftp assumes (and last I checked) only supports file as the struct, and stream as the mode, and may complain if struct or mode commands are issued at all. Those settings, together with type image, are adequate for arbitrary byte stream data between systems that agree on how to interpret it. The only thing left would be localizing the human-readable messages produced by the client ftp program. I don't see any gettext() calls in the source for ftp, so I don't think that's been done. I could argue that there are enough folks that try to script ftp (not a good move, except maybe using expect to deal with success or failure of individual ftp commands; better to use perl CPAN code that lets one test the result of each ftp command individually), that localizing ftp might break something. But assuming that as it appears to me, it wasn't localized, I don't know if that was the reason. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] multibyte support for FTP in Solaris
What i wanted to know was, if the filename has got multibyte characters, and not if the content of the file is multibyte. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] virtual windows on a hot Osol machine
Gary gdri...@gmail.com writes: It occurred to me that you might get better graphics performance by _not_ running your Windows apps in a virtual machine. If that's critical then you may want to virtualize Solaris instead. Or dual boot. Just a thought... Not sure why I never thought of that... But I think you are probably right. A heavy duty machine running windows 7 makes more sense to deal with windows apps such as photoshop and its pals in the Adobe suites. The Opensolaris NAS could be run virtual quite well I suspect. And especially since my usage is more commandline than GUI in opensolaris. Long as I have plenty of discs attached to the machine. My current setup has 3 sets of mirrored discs. Two of 500GB and 1 of 750GB so 6 discs in all. Then maybe two more (not mirrored) 750GB for the windows install and working room for video and graphics work plus enough space for temporary bckups of working projects. (I only send them to the NAS when they are completed) That would still be a way of killing two birds with one heavy duty machine, and be a serious upgrade all around. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] virtual windows on a hot Osol machine
Dmitry G. Kozhinov d...@desktopfay.com writes: It occurred to me that you might get better graphics performance by _not_ running your Windows apps in a virtual machine. If that's critical then you may want to virtualize Solaris instead. Or dual boot. Just a thought... I had exactly the same thought (but not expressed it somehow). Virtualized Windows 7 should work well for calculations such as rendering, but not real-time rendering on screen. Virtual graphics card is far less good than a real one. I think you guys are right... Not sure why I didn't think of it... A seniour moment or just a `Duh' moment. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Fwd: [OT] Openindiana mailing list
Albert Lee tr...@opensolaris.org writes: Harry, I tried entering your email in the subscription form, and there was no problem. I guess there was a typo in the address during your previous attempt to subscribe. If you clicked through the confirmation message, you should be subscribed now. Well thanks for the taking the time. I did check my address several times while at the subscription page. But it would not be the first time I was blind to some error. When you mention the `confirmation message' are you referring to one from gmane or do you mean I should have gotten something from the list itself? If the latter then I have received nothing. Going thru the subscription process again and you are right that my email address is not rejected. I should be good now Thanks again ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] multibyte support for FTP in Solaris
What i wanted to know was, if the filename has got multibyte characters, and not if the content of the file is multibyte. Between two Unix systems, it shouldn't matter, since the convention there would be to use UTF-8 encoding for multibyte names. UTF-8 is friendly to anything that is 8-bit clean, since it doesn't use ASCII bytes to encode higher characters. (I've tried this and it seems to work, sending or receiving.) I _think_ a Mac (OS X) would for those purposes behave like a Unix system. I can't try that right now. No idea what would happen with Mac OS older than OS X. I looked around a little more to see about the possibility of additional multibyte support in ftp. Most modern ftp is at least RFC 959 compliant - written in 1985. I wouldn't assume interoperability of any sort with anything older than that. Newer, and relevant to multibyte name support (and localization of messages) is RFC2640 (1999). RFC2640 specifies that multibyte filenames be passed in UTF-8. On Solaris, that works. Whether or not the other end (when it's some other OS) complies is anyone's guess. Also, not only do other platforms not natively use UTF-8 for filenames (Windows uses UTF-16), some platforms have naming conventions that would rule out multibyte names (like native, i.e. non-Unix, file names on an IBM mainframe). However, that works simply because UTF-8 is the native (on Solaris or for that matter Linux) way of representing multibyte characters in a file name, not because Solaris's ftp has any special support for that. RFC2640 also specifies a way for clients to communicate their preferred locale for human-readable messages to the server. Unfortunately, I don't think the Solaris ftp client supports that (so it clearly doesn't fully support RFC2640). The Solaris ftpd server (basically WU-FTPD now, which is a very configurable open source ftp server; in Solaris 8 and before, Solaris used its own ftp server, which was not nearly as capable) does _not_ appear to me to support the LANG command for communicating the preferred locale for messages. If WU-FTPD, one of the more advanced ftpd implementations, doesn't do that, I'm guessing that most others don't either. So...multibyte filenames should survive ftp between most Unix systems, and the Solaris ftpd server and command line ftp client shouldn't cause any problems there (although they don't specifically advertise the capability, which might just confuse an ftp server or client on another system that was trying to be a little too smart about things). But between Solaris and some non-Unix system, I would generally expect that it _wouldn't_ work. And I don't think messages to the user will be localized. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] 32-bit noexec_user_stack on per-process basis?
On 10/20/10 21:42, Richard L. Hamilton wrote: While I still like the idea of a runtime function (new syscall or extension to mprotect()) to control default stack or heap permissions (mainly for use with a preloadable shared object to apply to existing binaries that don't have a spare program header, although some other runtime uses might be imaginable), leaving oneself the leeway to patch a binary statically also seems desirable. I gather that something had been done to leave some room so that for newer binaries, one could patch in runpath changes longer than the original runpath (whereas for older ones, one might well have been limited to a new runpath that fit in the same space as the old one). Are there any _current_ uses you can see for a spare unused (PT_NULL) program header other than changing it into a PT_SUNWSTACK header? (I imagine that there's always a good chance that future uses as yet unsupported might turn up, i.e. some future feature that could be retrofitted into existing binaries given a spare header to put it into; but I'm thinking now in terms of current possibilities.) The something was 6516118 Reserved space needed in ELF dynamic section and string table PSARC 2007/127 Reserved space for editing ELF dynamic sections This is definitely a similar idea, elfedit being the common thread. I don't see another use for a spare program header, other than for this SUNWSTACK purpose, at this time. However, the cost of an extra program header is nil, so that doesn't worry me. We'll see... - Ali ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [OT] Openindiana mailing list
My request is rejected with: Your subscription is not allowed because the email address you gave is insecure Try to contact Alasdair Lumsden at alasdai...@googlemail.com - he is the creator of OpenIndiana project. - Dmitry. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Fwd: [OT] Openindiana mailing list
On Thu, Oct 21, 2010 at 8:16 AM, Harry Putnam rea...@newsguy.com wrote: Albert Lee tr...@opensolaris.org writes: Harry, I tried entering your email in the subscription form, and there was no problem. I guess there was a typo in the address during your previous attempt to subscribe. If you clicked through the confirmation message, you should be subscribed now. Well thanks for the taking the time. I did check my address several times while at the subscription page. But it would not be the first time I was blind to some error. When you mention the `confirmation message' are you referring to one from gmane or do you mean I should have gotten something from the list itself? There should've been one from our list software, Mailman, after you submit the form (or in that case, me impersonating you), with the instructions to accept the subscription. If the form is working and you're still not receiving any mail, we can look into it, although chances are it's not a problem we can solve on our end. -Albert ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
