Re: [osol-discuss] Re: Re: Software for Solaris (was Re:
Artem Kachitchkine [EMAIL PROTECTED] wrote: One thing I don't get yet is why vold been dropped (was it?) over rmvolmgr? And will vold co-exist with rmvolmgr? But may be I just misread the document... As I replied to you earlier, section 8, Vold EOF and backward compatibility describes this in detail. vold and HAL cannot co-exist. vold will be removed, but some level of backward compatibility will be preserved as much as practical. Could you please give me a hint what 'section 8, Vold EOF and backward compatibility' refers to? Not sure what you are talking about. HAL is an abstraction layer. It doesn't re-implements anything. Joerg is talking about polling of the CD/DVD devices. HAL needs to maintain a consistent view of hardware, it does so by consuming asynchronous kernel events. There are cases, however, when events are not available, so HAL has to poll. One such case is media insertion/removal. In Solaris, this can be done either with the DKIOCSTATE ioctl (in which case the kernel does polling for you) or directly via uscsi interface. We are currently using the former, but are likely to transition to the latter in order to detect hardware eject button presses. The polling done by the Solaris driver has been proven to be no problem. If we are talking about extending the current vold features, there is an important thing that vold currently cannot do: In case that you load a blank CD, vold stays quiet and allows cdrecord to work. In case that you enter a previously written CD/DVD and like to add a new session, we have a problem. Vold sees a written CD/DVD and mounts it. Cdrecord/mkisofs would need a way to tell vold to unmount the medium and stay quiet until a new medium change event occurs. In respect to CD/DVD writing, it is our high priority not to break it. I know cdrecord found a way to coexist with it, but it works more by coincidence than by design; whatever vold workarounds are out there, they never broke simply because noone dared to touch vold for many years. There is a risk that some things will break now, but it's an attribute of change and, as others pointed out, vold had to go sooner or later. THe way it currently works is reliable because it does not use O_EXCL. Linux likes to see O_EXCL for opening the devices in order to keep hald quiet. This causes problems as it only works in a useful way if there is no more than a single CD/DVD writer. If we like the new method to be reliable and useful, it should allow nice applications to issue a test unit ready or a inquiry while a device is in use by another application. In respect to things being similar to Linux, the Tamarack proposal has section 2.2 Why HAL specifically to address this. In short, if Sun is serious about making GNOME its primary desktop, Solaris has to have HAL, there's just no way around it. It doesn't mean, however, that HAL *implementation* has to be similar to Linux, deviations are inevitable, though we do strive to share a lot of code. BTW, FreeBSD is also getting HAL very soon. Finally, I'd like to invite those interested to the tamarack-discuss mailing list. I tend to have to ignore runaway threads on opensolaris-discuss. Let us discuss this after I could read it It may be that you need hal if you like GNOME. It may be that you need to change hal if you like seamless CD/DVD recording at the same time. This may come up because nobody from the hal camp did ask me before defining how hal should work. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Software for Solaris (was Re: AdobeAcrobat for Solari
Let's be even more realistic then -- those people should not be programming then, period. Those people could be students who may be writing their first program... Or scientists who cares about the result and not the process... At any rate, I woudn't blame them, instead I would greatly appreciate what they doing at their free time. You're kidding me. I'm sorry for the kid's bad code, but it's not very likely I'm going to be appreciative of fixing some clueless kid's mess because s/he's learning how to program wrongly. At that price, I might just as well go and write the specification, and implement the thing myself. a) it will be done properly b) there will be quality control c) there will be documentation Much better then fixing some kid's code, while s/he informs me via e-mail that s/he can't support Solaris because s/he only has Linux. The right thing to do here is to teach the kid how to do it properly, or steer him/her in the right direction. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Software for Solaris (was Re: AdobeAcrobat for Solari
On 6/1/06, a b [EMAIL PROTECTED] wrote: Let's be even more realistic then -- those people should not beprogramming then, period.Those people could be students who may be writing their first program...Or scientists who cares about the result and not the process... At any rate, I woudn't blame them, instead I would greatly appreciatewhat they doing at their free time.You're kidding me.I'm sorry for the kid's bad code, but it's not very likely I'm going to be appreciative of fixing some clueless kid's mess because s/he's learning howto program wrongly. At that price, I might just as well go and write thespecification, and implement the thing myself.a) it will be done properly b) there will be quality controlc) there will be documentationMuch better then fixing some kid's code, while s/he informs me via e-mailthat s/he can't support Solaris because s/he only has Linux. The right thing to do here is to teach the kid how to do it properly, orsteer him/her in the right direction.I agree - when I was at polytech learning how to programme; the number of times I was sent back projects because they were of an 'unacceptable standard' in regards to messy code, incorrect indentation etc. etc. I hated it, but in the end, it served me well, and provided a good platform for future learning. Matty ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Re: Software for Solaris (was Re: Adobe Acrobat for Solaris x86)
yep. And lets be real here, it is much easier for us to fix GCC compiler to work properly on OpenSolaris than to fix or change mentality of those lazy programmers... Let's be even more realistic then -- those people should not be programming then, period. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Software for Solaris (was Re: Adobe Acrobat for Solaris x86)
On Tue, 2006-05-30 at 04:28 -0700, UNIX admin wrote: yep. And lets be real here, it is much easier for us to fix GCC compiler to work properly on OpenSolaris than to fix or change mentality of those lazy programmers... Let's be even more realistic then -- those people should not be programming then, period. Those people could be students who may be writing their first program... Or scientists who cares about the result and not the process... At any rate, I woudn't blame them, instead I would greatly appreciate what they doing at their free time. Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Re: Software for Solaris (was Re:
One thing I don't get yet is why vold been dropped (was it?) over rmvolmgr? And will vold co-exist with rmvolmgr? But may be I just misread the document... As I replied to you earlier, section 8, Vold EOF and backward compatibility describes this in detail. vold and HAL cannot co-exist. vold will be removed, but some level of backward compatibility will be preserved as much as practical. Not sure what you are talking about. HAL is an abstraction layer. It doesn't re-implements anything. Joerg is talking about polling of the CD/DVD devices. HAL needs to maintain a consistent view of hardware, it does so by consuming asynchronous kernel events. There are cases, however, when events are not available, so HAL has to poll. One such case is media insertion/removal. In Solaris, this can be done either with the DKIOCSTATE ioctl (in which case the kernel does polling for you) or directly via uscsi interface. We are currently using the former, but are likely to transition to the latter in order to detect hardware eject button presses. In respect to CD/DVD writing, it is our high priority not to break it. I know cdrecord found a way to coexist with it, but it works more by coincidence than by design; whatever vold workarounds are out there, they never broke simply because noone dared to touch vold for many years. There is a risk that some things will break now, but it's an attribute of change and, as others pointed out, vold had to go sooner or later. In respect to things being similar to Linux, the Tamarack proposal has section 2.2 Why HAL specifically to address this. In short, if Sun is serious about making GNOME its primary desktop, Solaris has to have HAL, there's just no way around it. It doesn't mean, however, that HAL *implementation* has to be similar to Linux, deviations are inevitable, though we do strive to share a lot of code. BTW, FreeBSD is also getting HAL very soon. Finally, I'd like to invite those interested to the tamarack-discuss mailing list. I tend to have to ignore runaway threads on opensolaris-discuss. -Artem. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Software for Solaris (was Re:
On Tue, 2006-05-30 at 11:40 -0700, Artem Kachitchkine wrote: One thing I don't get yet is why vold been dropped (was it?) over rmvolmgr? And will vold co-exist with rmvolmgr? But may be I just misread the document... As I replied to you earlier, section 8, Vold EOF and backward compatibility describes this in detail. vold and HAL cannot co-exist. vold will be removed, but some level of backward compatibility will be preserved as much as practical. Not sure what you are talking about. HAL is an abstraction layer. It doesn't re-implements anything. Joerg is talking about polling of the CD/DVD devices. HAL needs to maintain a consistent view of hardware, it does so by consuming asynchronous kernel events. There are cases, however, when events are not available, so HAL has to poll. One such case is media insertion/removal. In Solaris, this can be done either with the DKIOCSTATE ioctl (in which case the kernel does polling for you) or directly via uscsi interface. We are currently using the former, but are likely to transition to the latter in order to detect hardware eject button presses. In respect to CD/DVD writing, it is our high priority not to break it. I know cdrecord found a way to coexist with it, but it works more by coincidence than by design; whatever vold workarounds are out there, they never broke simply because noone dared to touch vold for many years. There is a risk that some things will break now, but it's an attribute of change and, as others pointed out, vold had to go sooner or later. In respect to things being similar to Linux, the Tamarack proposal has section 2.2 Why HAL specifically to address this. In short, if Sun is serious about making GNOME its primary desktop, Solaris has to have HAL, there's just no way around it. It doesn't mean, however, that HAL *implementation* has to be similar to Linux, deviations are inevitable, though we do strive to share a lot of code. BTW, FreeBSD is also getting HAL very soon. Cool. You guys doing a great job! Appreciated. Will Tamarack beat Utopia? I guess it will. :-) Finally, I'd like to invite those interested to the tamarack-discuss mailing list. I tend to have to ignore runaway threads on opensolaris-discuss. I'm in. Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Re: Software for Solaris (was Re: Adobe Acrobat for Solaris x86)
You can try: - set the optimization level to -xO4 or higher - pass -xinline=%auto To this I'd also add, don't use __inline (which GCC won't bark on), but inline instead. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Re: Software for Solaris (was Re: Adobe Acrobat for Solaris x86)
You sure do not like GCC... :-) Well, I like it, even I know it is buggy sometimes.. No I don't, can you tell? (:-) Especially after suffering at its braindead mercy, I'd like to not have to ever have to deal with GCC again. Ever. btw, do you know by any chance how to say Sun C compiler to always respect inlines statements? I tried different switches, never worked for me... Depends on what you're inlining. How do you know that it's not working? Did you look at the assembler output with -S? And use inline instead of __inline. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Re: Software for Solaris (was Re: Adobe Acrobat for Solaris x86)
There is a lot more Linux specific on GNOME. THe most important task we have with OpenSolaris is to convince people that trying to compile on Solaris is a must for every OpenSource project. Actually, we should be teaching people to switch to Solaris as the main development platform to begin with, then these problems will go away. Of course, the guys that do come over expect Solaris to behave like Linux. This is obviously a problem, since Solaris is not Linux. The core of the problem is that these guys don't (yet) know or understand that Solaris is light years ahead, and that that's what they should be learning instead of trying to replicate something that's crap. That's one of the things we need to work on. For this reason, it is important to better advertize the free Sun Studio Tools. Agreed. These tools are fenomenal, they're free, and they're also available on Linux now. So there's no excuse not to use them. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Re: Software for Solaris (was Re: Adobe Acrobat for Solaris x86)
Few comments: a) too late for wishes like that; There is always hope; remember that. b) majority of developers using GNU userland all over, even on Windows they prefer Cygwin over anything else; That's because they don't know any better. Our job should be to teach them to know better than that. I for one am working on bringing this to the attention of the people around me, and raising awareness of the issue. d) we do not port Linux-only software. i.e. which is not design to work on any platform other than Linux, such us kernel-specific software. FYI, Debian new package acceptance policy saying that software which willing to be accepted to the main should run at least on two architectures. Usually it is Linux and FreeBSD... Look, I know that you do a tremendous amount of work -- I'm not actually a UNIX admin any more, but a system engineer, so I know how much work must go into a project like that. But I'm going to ask you an honest question, so I'd like you to think about it long and hard before you answer me. Can you ever see Nexenta being run in a bank for the most mission critical stuff? Or in an insurance company? Or powering an ATM? Or a life support system? This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Re: Software for Solaris (was Re: Adobe Acrobat for Solaris x86)
Right. In addition I'd like to add that porting (C, C++ code) to Nexenta == porting to Solaris. Zero differences for both drivers and apps. So, it doesn't really matter where developers will settle at Nexenta or at Solaris. Besides, all SUN userland is provided at /usr/sun/bin, so SUN personality could be provided/enabled too. While I can certainly see that for apps that depend on drivers, would you please mind explaining how are you porting to Solaris when you compile and link against GNU / Ubuntu userland? This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Software for Solaris (was Re: Adobe Acrobat for Solaris x86)
On Mon, 2006-05-29 at 13:22 -0700, UNIX admin wrote: Right. In addition I'd like to add that porting (C, C++ code) to Nexenta == porting to Solaris. Zero differences for both drivers and apps. So, it doesn't really matter where developers will settle at Nexenta or at Solaris. Besides, all SUN userland is provided at /usr/sun/bin, so SUN personality could be provided/enabled too. While I can certainly see that for apps that depend on drivers, would you please mind explaining how are you porting to Solaris when you compile and link against GNU / Ubuntu userland? I missed the point completely... :-) -- Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
