Re: Wine on Darwin
On Tue, 05 Oct 2004 10:14, Carl Cerecke wrote: Steve Bell wrote: Thanks Lee - I think I now understand that the same OS on a different processor must use quite different system calls. Not really. System Calls are at the level of the OS. They will vary between different OSes on the same hardware, but not the same OS on different hardware. It's the internals of the system calls that must vary. The absurd consequence of this is that an Operating System like FreeVMS, the F/LOSS OpenVMS clone, can be built on top of the Linux kernel; it uses the original Linux code, as is, where is; it just changes how a system call is handled, how it behaves, some of its data structures, etc. Although, that said and done, I'm still getting my head around how so many linux apps seem to be ported to run in FreeBSD on PPC in next to no time. Because they are distributed as C (or some other) source code. This code can be recompiled for the different hardware. And, as far as OSes go, Linux and FreeBSD look pretty much the same to most application-level software. Hmm, though is the case with WINE that there's two layers of system calls to be translated, first to port WINE from running on X86 to PPC, then to have software to pretend the PPC is an X86? WINE is different sort of beast. Wine only (AFAIK) intercepts system calls (calls to the MS Windows system call interface). It does not do any translation for normal (x86) code. There was a complete x86 emulator called Bochs, a while ago. That is, it emulates an entire PC, including the instruction set, so you can install any x86 OS within Bochs on your (possibly non-x86) machine. Don't expect it to be fast though. Note that this is different yet again from VMWare, which only works on x86, and is, consequently, much faster, as it doesn't have to interpret every single x86 instruction - it allows most instructions to execute directly on the CPU. What they call emulation versus virtualization. Bochs, as you've said, emulates every instruction of the x86 cpu, even on an IBM z900 cpu; VMWare, Plex86, Qemu, etc, virtualize, that is they act like virtual cpus, but hand off at least 50 percent of all instructions directly to the host cpu. The rest they interpret. Cheers, Carl. -- Wesley Parish * * * Clinersterton beademung - in all of love. RIP James Blish * * * Mau e ki, He aha te mea nui? You ask, What is the most important thing? Maku e ki, He tangata, he tangata, he tangata. I reply, It is people, it is people, it is people.
Re: Wine on Darwin
On Oct 4, 2004, at 11:23 PM, Lee Begg wrote: On Mon, 04 Oct 2004 23:08, Steve Bell wrote: Does this mean with the X11 window system thingie installed on OS X (that I use to run openoffice) that I could try and run Wine? No. Wine tells the operating system to execute the code, and catches the system calls. The executable will not run on the PPC. That's what I would have said a year ago. In fact (on another list), I did. http://darwine.opendarwin.org/ This project is at developer release level (i.e. not yet fully functional) but has been up for over a year, and is now happily working with QEMU (a CPU emulator). The intention is to have as many of the WinLib calls result in equivalent Carbon/Quartz operations, rather than run everything through X11. I don't believe that they can yet run a win32 executable on a powerPC, but they will be able to real soon now. In the meantime, I understand that they can happily run win32 executables on Darwin on an x86. -jim
Re: Wine on Darwin- Bochs
Hi I have over the past week set up and played around with bochs. I have managed to get dos 7.10, free dos, win311 and win95 working in it. Performance seems to vary depending on what is happening on the guest os. You can start multiple oses if you want though with performance degradation. Instillation seems to be really bad for windows 98 and as of yet I have not got it installed well thats my 3 cents hope it informs some body Brendan WINE is different sort of beast. Wine only (AFAIK) intercepts system calls (calls to the MS Windows system call interface). It does not do any translation for normal (x86) code. There was a complete x86 emulator called Bochs, a while ago. That is, it emulates an entire PC, including the instruction set, so you can install any x86 OS within Bochs on your (possibly non-x86) machine. Don't expect it to be fast though. Note that this is different yet again from VMWare, which only works on x86, and is, consequently, much faster, as it doesn't have to interpret every single x86 instruction - it allows most instructions to execute directly on the CPU. Cheers, Carl.
Re: Suse 9.1 OpenOffice problem
On Tue, 05 Oct 2004 14:10, Volker Kuhlmann wrote: See, Gentoo does it correctly. Feel better now? Not really, it's not of any real consequence. I'm merely stating a fact. I'm fully aware that you can take a horse to water but cannot make it drink. -- Sincerely etc., Christopher Sawtell
Re: Suse 9.1 OpenOffice problem
Its always nice to start the morning with a bit of humor . Dale. Christopher Sawtell wrote: On Tue, 05 Oct 2004 14:10, Volker Kuhlmann wrote: See, Gentoo does it correctly. Feel better now? Not really, it's not of any real consequence. I'm merely stating a fact. I'm fully aware that you can take a horse to water but cannot make it drink.
Re: Wine on Darwin
Yay, Jim - that's the bit I didn't understand. That is the page that originally got me questioning (hmm, maybe I should have offered that link in the first place :-?). So does that mean that if I have X11 installed on my mac that (if I installed darwine) I could try to run a win32 app? And that soon it won't even need X11? Thanks all for your input so far - I'm tryna take it all in! Steve Jim Cheetham wrote: On Oct 4, 2004, at 11:23 PM, Lee Begg wrote: On Mon, 04 Oct 2004 23:08, Steve Bell wrote: Does this mean with the X11 window system thingie installed on OS X (that I use to run openoffice) that I could try and run Wine? No. Wine tells the operating system to execute the code, and catches the system calls. The executable will not run on the PPC. That's what I would have said a year ago. In fact (on another list), I did. http://darwine.opendarwin.org/ This project is at developer release level (i.e. not yet fully functional) but has been up for over a year, and is now happily working with QEMU (a CPU emulator). The intention is to have as many of the WinLib calls result in equivalent Carbon/Quartz operations, rather than run everything through X11. I don't believe that they can yet run a win32 executable on a powerPC, but they will be able to real soon now. In the meantime, I understand that they can happily run win32 executables on Darwin on an x86. -jim
Re: Wine on Darwin
Duh, sorry, I didn't read the last word of your post - x86. Ignore previous second paragraph of stupidity. Steve Bell wrote: Yay, Jim - that's the bit I didn't understand. That is the page that originally got me questioning (hmm, maybe I should have offered that link in the first place :-?). So does that mean that if I have X11 installed on my mac that (if I installed darwine) I could try to run a win32 app? And that soon it won't even need X11? Thanks all for your input so far - I'm tryna take it all in! Steve Jim Cheetham wrote: On Oct 4, 2004, at 11:23 PM, Lee Begg wrote: On Mon, 04 Oct 2004 23:08, Steve Bell wrote: Does this mean with the X11 window system thingie installed on OS X (that I use to run openoffice) that I could try and run Wine? No. Wine tells the operating system to execute the code, and catches the system calls. The executable will not run on the PPC. That's what I would have said a year ago. In fact (on another list), I did. http://darwine.opendarwin.org/ This project is at developer release level (i.e. not yet fully functional) but has been up for over a year, and is now happily working with QEMU (a CPU emulator). The intention is to have as many of the WinLib calls result in equivalent Carbon/Quartz operations, rather than run everything through X11. I don't believe that they can yet run a win32 executable on a powerPC, but they will be able to real soon now. In the meantime, I understand that they can happily run win32 executables on Darwin on an x86. -jim
Re: Wine on Darwin
Steve Bell wrote: So does that mean that if I have X11 installed on my mac that (if I installed darwine) Just a note.. you dont need to install Darwin to get X and co to build from source etc , X comes bundled with most recent OSX versions and to get a toolchain /base for building from source etc all is required is Xcode and fink . Cheers Dale. Thanks all for your input so far - I'm tryna take it all in! Steve
SOLVED: Debian upgrade stable - unstable fails
Thanks to those who responded on- and off-list. Resolved by: - modifying sources.list to use stable only [0] - apt-get clean - apt-get -f install - ensuring that libdb1-compat wasn't installed - modifying sources.list to use testing only - apt-get install kernel-image - apt-get dist-upgrade Result: a happy system running testing (I won't bother with unstable) and a 2.4.26 kernel. Cheers, Roy. On 05/10/04 13:53, Roy Britten wrote: From where this neophyte sits it appears that upgrading glibc requires a newer kernel, and to install a newer kernel I need a newer glibc. [0] my box generated an out-of-memory error (thick-fingerdly closed the terminal before getting the exact message, grrr) when attempting to build the dependency tree for both stable and testing. -- Roy Britten, Lead Software Developer, Information Systems Team National Institute of Water and Atmospheric Research P.O. Box 8602, Christchurch, New Zealand P:+64-3-343-7818; F:+64-3-348-5548; PGP-KeyID:0x58959E31
Re: nautilus, icons, debian
Andrew, 2004-09-28 16:52:46: I apt-get install'd nautilus. However, rather unhelpfully, the icons are all generic-looking bits of paper with a folded corner. Except for the images, which are thumbnails. [...] I'm using the testing distribution, btw. If you haven't had any luck yet, there's a short thread on the linux.debian.user newsgroup that might be relevant. (The topic is Icon bug in Nautilus (SARGE) still not fixed ?, and it was started on 2004-10-03.) A suggested fix is to start gnome-settings-daemon (say, in your ~/.xsession file) while starting up X. (Assuming you're using nautilus without the full GNOME desktop.) Someone else suggested installing the packages recommended by the Debian nautilus package: http://packages.debian.org/testing/gnome/nautilus Of those, you've said you already have gnome-icon-theme, but what about desktop-base? Anyway, just posting this coz I was reminded of your problem - will shut up again now. -- Timothy Musson - [EMAIL PROTECTED] http://homepages.ihug.co.nz/~trmusson/
Re: Pike Users Worldwide Converge on Essen Next Week
Martin Bähr wrote: About Pike Pike is a dynamic programming language with a syntax similar to Java and C. It is simple to learn, does not require long compilation passes and has powerful built-in data types allowing simple and really fast data manipulation. Pike is a reimplementation of the LPC language, its application domain spans anything from the world of the Net to the world of multimedia applications, or environments where your shell could use some spicy text processing or system administration tools. Your imagination sets the limit, but Pike will probably extend it far beyond what you previously considered within reach. I'll stick with python, thanks :-) (Unless there's some major advantage of pike over python that I'm missing) Cheers, Carl.
Re: Pike Users Worldwide Converge on Essen Next Week
On Wed, Oct 06, 2004 at 04:28:13PM +1300, Carl Cerecke wrote: I'll stick with python, thanks :-) (Unless there's some major advantage of pike over python that I'm missing) speed and true encapsulation. (python objects don't have private data, (at least they didn't last we checked) sTeam, a server where users are allowed to run their own pike scripts, would not be possible without protected data. but apart from that, and a few very nice syntactic features of pike operators python and pike are quite up to par. and i like pythons syntax too. greetings, martin. -- - Pike - Caudium - sTeam - psycMUVE - LPC - Pike Camp, October 13 - 19, 2004, Unperfekthaus, Essen, Germany -- pike programmer travelling and working in europeopen-steam.org unix system- is.schon.org camp.gotpike.org administrator bahai.or.at iaeste.(tuwien.ac|or).at Martin Bähr http://www.iaeste.or.at/~mbaehr/
Re: Pike Users Worldwide Converge on Essen Next Week
Martin Baehr wrote: On Wed, Oct 06, 2004 at 04:28:13PM +1300, Carl Cerecke wrote: I'll stick with python, thanks :-) (Unless there's some major advantage of pike over python that I'm missing) speed and true encapsulation. (python objects don't have private data, (at least they didn't last we checked) sTeam, a server where users are allowed to run their own pike scripts, would not be possible without protected data. Python is not as slow as it used to be. Especially with packages like psyco (a dynamic x86 optimiser for python) it can approach the speed of C for some code. In fact, it can even be *faster* than C, because it can do dynamic optimsations on running code that a static compiler can't do. You're right about the encapsulation though. Python only provides pseudo-private fields/methods. You can do restricted execution, but the latest python docs say: Warning: In Python 2.3 these modules have been disabled due to various known and not readily fixable security holes. but apart from that, and a few very nice syntactic features of pike operators python and pike are quite up to par. and i like pythons syntax too. M. Python syntax. Very nice. Cheers, Carl.
Re: Pike Users Worldwide Converge on Essen Next Week
On Wed, Oct 06, 2004 at 05:03:42PM +1300, Carl Cerecke wrote: Python is not as slow as it used to be. Especially with packages like psyco (a dynamic x86 optimiser for python) it can approach the speed of C for some code. In fact, it can even be *faster* than C, because it can do dynamic optimsations on running code that a static compiler can't do. right, the same has been true for pike all along. M. Python syntax. Very nice. indeed, after starting to learn python, my first reaction to pike was: can't we change pike to get rid of those braces? (should even be possible, pike has a python parser, which doesn't handle everything in python, but it would be enough for a pike based on indenting (hmm, pikon ;-)) greetings, martin. -- - Pike - Caudium - sTeam - psycMUVE - LPC - Pike Camp, October 13 - 19, 2004, Unperfekthaus, Essen, Germany -- pike programmer travelling and working in europeopen-steam.org unix system- is.schon.org camp.gotpike.org administrator bahai.or.at iaeste.(tuwien.ac|or).at Martin Bähr http://www.iaeste.or.at/~mbaehr/
