Re: Wine compatibility and performance on FreeBSD 7
On Dec 10, 2007, at 10:06 PM, Tom Wickline wrote: On Dec 11, 2007 12:59 AM, Simon Cornelius P. Umacob [EMAIL PROTECTED] wrote: Whoa... I didn't know that. =) I should now be able to run Warcraft on my Linux and FreeBSD (?) boxes... Coool... [ simon.cpu ] Maayong hapon Simon, Yea it should work, Wow and Warcraft III can be run in OpenGL mode. Tom IE7 should install on WINE (assuming you have WINE setup as an XP SP2 + environment) unless M$ mickeyed it up, now that the genuine windows requirement doesn't exist anymore.. -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Wine compatibility and performance on FreeBSD 7
On Mon, 2007-12-10 at 23:44 -0500, Tom Wickline wrote: On Dec 10, 2007 11:41 PM, Brett Glass [EMAIL PROTECTED] wrote: It's worth noting that the WINE project, not long ago, abandoned the BSD license for the GPL despite urging from many sources to keep the code open and free for use by developers. We've stopped using it as a result. --Brett Glass Wins is under a free licence, its LGPL and I'm almost 100% sure you have no idea why the licence was changed! Tom Depends upon your definition of free. signature.asc Description: This is a digitally signed message part
Re: Wine compatibility and performance on FreeBSD 7
Hi, Garrett Cooper wrote: On Dec 10, 2007, at 10:06 PM, Tom Wickline wrote: On Dec 11, 2007 12:59 AM, Simon Cornelius P. Umacob [EMAIL PROTECTED] wrote: Whoa... I didn't know that. =) I should now be able to run Warcraft on my Linux and FreeBSD (?) boxes... Coool... [ simon.cpu ] Maayong hapon Simon, Yea it should work, Wow and Warcraft III can be run in OpenGL mode. Tom IE7 should install on WINE (assuming you have WINE setup as an XP SP2+ environment) unless M$ mickeyed it up, now that the genuine windows requirement doesn't exist anymore.. -Garrett This sound very interesting for me. Does anyone tried it already? Someone care to make small HOWTO ? :P ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Disk sync at shutdown and fusefs filesystems
On Mon, 10 Dec 2007 20:18:26 -0800
Doug Barton [EMAIL PROTECTED] wrote:
Alejandro Pulver wrote:
Then I have to look for some way to manually
unmount FUSE filesystems at shutdown, because they are already mounted
at startup. I thought about instructing the fusefs-kmod rc.d script to
unmount FUSE filesystems before attempting to unload the kernel module
(currently it only loads/unloads fuse.ko).
Yes, I think that given what we're working with here, that would be a
good idea regardless. It should be pretty easy to do, you can find a
sample of something like what you would want in /etc/rc.d/dumpon. Let
me know if you need help, I'm more than a little interested in getting
fuse-ntfs set up here.
Thanks, here is what I've got so far: it seems /dev/fuse[0-9]* devices
aren't removed after the corresponding filesystem is unmounted (I guess
they are reused), so instead of listing /dev the list has to be taken
from 'mount'. Also there should be a delay between the 'umount' and
'kldunload' commands. What do you think about the following
(replacement for fusefs_stop function)?
echo Stopping ${name}.
for fs in `mount | grep '^/dev/fuse[0-9]*' | cut -d ' ' -f 1`; do
umount $fs
done
sleep 2
kldunload $kmod
Unfortunately it doesn't have a status function to avoid loading when
already loaded and the other way, but can easily be added.
Best Regards,
Ale
signature.asc
Description: PGP signature
Re: Wine compatibility and performance on FreeBSD 7
On Mon, 10 de Diciembre de 2007, 10:41 pm, Brett Glass wrote: It's worth noting that the WINE project, not long ago, abandoned the BSD license for the GPL despite urging from many sources to keep the code open and free for use by developers. We've stopped using it as a result. You can find the story of what happened in the Wikipedia. There is still this: http://www.cedega.com/rewind/, if you like better the X11 license. You still have *freedom* of choice. Regardless of the current license of Wine they have merit for what they have done. Any open source developer regardless of his Creed has merit in fact. ;-) At 10:59 AM 12/6/2007, Tom Wickline wrote: Oh yea, were seeking contributors... if your interested in Wine on FreeBSD and believe you can help us out see : http://wine-review.blogspot.com/2007/12/wine-review-is-currently-seeking.html ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Wine compatibility and performance on FreeBSD 7
Tom Wickline [EMAIL PROTECTED], thread to all: [EMAIL PROTECTED], [EMAIL PROTECTED], freebsd-hackers@freebsd.org, [EMAIL PROTECTED] [EMAIL PROTECTED], Trimmed to just [EMAIL PROTECTED] (Though finding just where cross posting policy is deprecated in http://freebsd.org's own searcher, is not easy). Braulio wrote: You can find the story of what happened in the Wikipedia. http://en.wikipedia.org/wiki/Wine_%28software%29 ... originally released Wine under the same MIT License as the X Window System, but owing to concern about proprietary versions of Wine not contributing their changes back to the core project, work as of March 2002 has used the LGPL Brett wrote: ...WINE project, not long ago, abandoned 2002 or recent ? Are we considering real old news ? Braulio wrote: http://www.cedega.com/rewind/ cd /pub/FreeBSD/branches/-current/ports/emulators echo #wine* # linux-winetools wine wine-doors more *wine*/pkg-descr If a wine user who doesnt like GPL, creates uses send-pr for eg emulators/wine-rewind it could divorce lists from debating licence issue :-) -- Julian Stacey. Munich Computer Consultant, BSD Unix C Linux. http://berklix.com Ihr Rauch = mein allergischer Kopfschmerz. Dump cigs 4 snuff. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Disk sync at shutdown and fusefs filesystems
On Tue, 11 Dec 2007, Alejandro Pulver wrote: Thanks, here is what I've got so far: it seems /dev/fuse[0-9]* devices aren't removed after the corresponding filesystem is unmounted (I guess they are reused), so instead of listing /dev the list has to be taken from 'mount'. Yeah, I think that's better than using fstab anyway, since this way we get them all with limited processing. Wish I'd thought of it. :) Also there should be a delay between the 'umount' and 'kldunload' commands. What do you think about the following (replacement for fusefs_stop function)? I suppose this is mostly a style difference, but I like to avoid all those subshells if we can. I also think it might be a good idea to wait a second between unmounts, just to be paranoid. How about: mount | while read dev d1 mountpoint d2; do case $dev in /dev/fuse[0-9]*) umount $mountpoint ; sleep 1 ;; esac done sleep 1 kldunload $kmod hth, Doug -- This .signature sanitized for your protection ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Disk sync at shutdown and fusefs filesystems
On Tue, 11 Dec 2007 12:22:35 -0800 (PST)
Doug Barton [EMAIL PROTECTED] wrote:
On Tue, 11 Dec 2007, Alejandro Pulver wrote:
Thanks, here is what I've got so far: it seems /dev/fuse[0-9]* devices
aren't removed after the corresponding filesystem is unmounted (I guess
they are reused), so instead of listing /dev the list has to be taken
from 'mount'.
Yeah, I think that's better than using fstab anyway, since this way we get
them all with limited processing. Wish I'd thought of it. :)
Actually, I tried first with umount -a -t {fusefs,ntfs-3g,fuse,...}
but didn't work.
Also there should be a delay between the 'umount' and
'kldunload' commands. What do you think about the following
(replacement for fusefs_stop function)?
I suppose this is mostly a style difference, but I like to avoid all those
subshells if we can. I also think it might be a good idea to wait a second
between unmounts, just to be paranoid. How about:
mount | while read dev d1 mountpoint d2; do
case $dev in
/dev/fuse[0-9]*) umount $mountpoint ; sleep 1 ;;
esac
done
sleep 1
It looks fine to me. And what about echoing the mountpoints as they are
unmounted?
mount | while read dev d1 mountpoint d2; do
case $dev in
/dev/fuse[0-9]*)
echo fusefs: unmounting ${mountpoint}.
umount $mountpoint ; sleep 1
;;
esac
done
Also this checks would avoid kldload/kldunload errors:
In fusefs_start:
if kldstat | grep -q fuse\\.ko; then
echo ${name} is already running.
return 0
fi
In fusefs_stop:
if ! kldstat | grep -q fuse\\.ko; then
echo ${name} is not running.
return 1
fi
Well, the word loaded instead of running would be better. Also a
status command could be added, but I don't think it's needed.
Also
signature.asc
Description: PGP signature
Re: Wine compatibility and performance on FreeBSD 7
At 10:01 AM 12/11/2007, Julian H. Stacey wrote: http://en.wikipedia.org/wiki/Wine_%28software%29 ... originally released Wine under the same MIT License as the X Window System, but owing to concern about proprietary versions of Wine not contributing their changes back to the core project, work as of March 2002 has used the LGPL What apparently happened is that one or two of the developers of Wine got their knickers in a twist about the idea that -- heaven forbid! -- someone might possibly make some money for the enhancements they made to Wine. (Never mind that the marketing and development costs for their commercial versions of Wine were eating all of their profits, and it was unclear whether they actually WOULD make any money.) Also, it is rumored (though I have not seen proof of it) that John Gilmore, an underwriter of the Wine project, threatened to withdraw support from some of these developers unless the license was switched to the GPL, thus forcing their hands. --Brett Glass ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Disk sync at shutdown and fusefs filesystems
On Tue, 11 Dec 2007 12:22:35 -0800 (PST), Doug Barton wrote: I suppose this is mostly a style difference, but I like to avoid all those subshells if we can. I also think it might be a good idea to wait a second between unmounts, just to be paranoid. How about: mount | while read dev d1 mountpoint d2; do case $dev in /dev/fuse[0-9]*) umount $mountpoint ; sleep 1 ;; esac done sleep 1 Hmm, if you truly want to be paranoid, you probably should be unmounting those in reverse order, because someone might be mounting one fuse-fs inside another ;) just my 2 cents, Karsten -- Open source is not about suing someone who sells your software. It is about being able to walk behind him, grinning, and waving free CDs with the equivalent of what he is trying to sell. signature.asc Description: PGP signature
Re: Wine compatibility and performance on FreeBSD 7
Brett Glass wrote: At 10:01 AM 12/11/2007, Julian H. Stacey wrote: http://en.wikipedia.org/wiki/Wine_%28software%29 ... originally released Wine under the same MIT License as the X Window System, but owing to concern about proprietary versions of Wine not contributing their changes back to the core project, work as of March 2002 has used the LGPL What apparently happened is that one or two of the developers of Wine got their knickers in a twist about the idea that -- heaven forbid! -- someone might possibly make some money for the enhancements they made to Wine. Don't FUD. Nothing stops anyone from making money off GPL'ed software. The real reason is that TransGaming et al weren't contributing anything back and wouldn't provide the source to users who bought binaries in a usable fashion. (Never mind that the marketing and development costs for their commercial versions of Wine were eating all of their profits, and it was unclear whether they actually WOULD make any money.) Also, it is rumored (though I have not seen proof of it) that John Gilmore, an underwriter of the Wine project, threatened to withdraw support from some of these developers unless the license was switched to the GPL, thus forcing their hands. -- Russell A. Jackson [EMAIL PROTECTED] Network Analyst California State University, Bakersfield Iam not very happy acting pleased whenever prominent scientists overmagnify intellectual enlightenment smime.p7s Description: S/MIME Cryptographic Signature
Re: Wine compatibility and performance on FreeBSD 7
If you don't like the license, don't use the software. If you want to complain/explain/debate about the license, find another forum. This subject is not on topic for the FreeBSD mailing lists. Thanks, Doug -- This .signature sanitized for your protection ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Wine compatibility and performance on FreeBSD 7
Garrett Cooper wrote: On Dec 10, 2007, at 10:06 PM, Tom Wickline wrote: On Dec 11, 2007 12:59 AM, Simon Cornelius P. Umacob [EMAIL PROTECTED] wrote: Whoa... I didn't know that. =) I should now be able to run Warcraft on my Linux and FreeBSD (?) boxes... Coool... [ simon.cpu ] Maayong hapon Simon, Yea it should work, Wow and Warcraft III can be run in OpenGL mode. Tom IE7 should install on WINE (assuming you have WINE setup as an XP SP2+ environment) unless M$ mickeyed it up, now that the genuine windows requirement doesn't exist anymore.. -Garrett Uhm, I don't know if anyone's tried it, but it won't be an easy feat. You need to get XP SP2+ setup on the machine with Wine, have IE6 setup first, then take that and update to IE7. -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Wine compatibility and performance on FreeBSD 7
On Dec 11, 2007 7:22 PM, Garrett Cooper [EMAIL PROTECTED] wrote: IE7 should install on WINE (assuming you have WINE setup as an XP SP2+ environment) unless M$ mickeyed it up, now that the genuine windows requirement doesn't exist anymore.. -Garrett Uhm, I don't know if anyone's tried it, but it won't be an easy feat. You need to get XP SP2+ setup on the machine with Wine, have IE6 setup first, then take that and update to IE7. -Garrett IE 7 shouldn't be that hard, well unless you want to do all the work and set it up yourself. IE 6 works as good on FreeBSD as it does on Linux, see: http://wine-review.blogspot.com/2007/12/ies-4-freebsd-internet-explorer-50-55.html IEs4Linux has beta support for IE 7 see: http://wine-review.blogspot.com/2007/12/ies-4-linux-2990-better-than-ever.html They will even have a GUI in 3.x releases. Ive not tried IE7 yet, but im sure ill get around to it. Cheers, Tom ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
results of ports re-engineering survey
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 *PLEASE ONLY REPLY TO ME OR [EMAIL PROTECTED] A few disclaimers: Neither I or anyone else is asking for FreeBSD to incorparate any modifications to the current base system and/or ports collection. If and when any code is developed from this process it will be committed using normal commit and review processes. The following summary of results is based on my eyeballing of answers and should not be interpreted as being any sort of mathematically and/or scientifically valid in any manner. Number of responses: roughly 30 Summary of results: 1. Most respondents stated that both the underlaying OS and the ports collection are equally important. When a preference was shown it was for the underlaying OS in most cases. 2. On average people tend to interact with the port system once or twice a week 3. The single best aspect of the ports system according to respondents is dependency tracking when installing new ports 4. The single worst aspect of the ports system according to respondents is dependency tracking when updating or deleting existing ports 5. Most respondents would not change there answers tothe survey if they where new to FreeBSD 6. Almost all respondents would use a new system if it fixed their personal worst aspect of the current system 7. About 50% of respondents would use a new system if it broke the best aspect of the ports system but fixed the worst aspect 8. Length of FreeBSD usage: rough avr. of 8 years with roughly 3 year std. dev. 9. Prefered install method: ports 10. Usage roughly evenly spread among desktop, development and servers 11. Subsystem ratings (rough avr's): UI: 6 Constancy: 9 Dependancy tracking: 7 Record keeping: 9 Granularity: 9 12. Most users are either sysadmins and/or developers Orginial Survey: As has been hashed out in -ports@ over the last few days there is at least a need to examine weither or not the current ports system should remain as is or potentially be re-engineered in the future (estimates if and when needed vary from ASAP to 10-15 years). I have volunteered to undertake a feasibility/pilot project to examine what changes (if any) are needed in the system (for the purposes of this thread I will not venture any of my own suggestions). I have the following broad questions for people: 1. What is more important to your personal use of FreeBSD (the ports system, the underlaying OS, some other aspect)? 2. How frequently do you interact with the ports systems and what is the most common interaction you have with it? 3. What is the single best aspect of the current system? 4. What is the single worst aspect of the current system? 5. If you where a new FreeBSD user how would your answers above change? If you where brand new to UNIX how whould they change? 6. Assuming that there was no additional work on your behalf would you use a new system if it corrected your answer to number 4? 7. Same as question 6 but for your answer on question 3? 8. How long have you used FreeBSD and/or UNIX in general? 9. That is your primary use(s) for your FreeBSD machine(s) (name upto 3)? 10. Assuming there is no functional difference what is your preferred installation method for 3rd party software? 11. On a scale from 1 to 10 (10 being the best) please rate the importance of the following aspects of the ports system? a. User Interface b. Consistency of behaviors and interactions c. Accuracy in dependant port installations d. Internal record keeping e. Granularity's of the port management system 12. Please rate your personal technical skill level? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHX3MyzIOMjAek4JIRAqqjAJ9YlNJW9Uqa21yK+sm1IST+KmO7QACfeum+ 9rhuEkdKX6BKkFZr6WGmbDU= =jhg0 -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
results of ports re-engineering survey
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 *PLEASE ONLY REPLY TO ME OR [EMAIL PROTECTED] A few disclaimers: Neither I or anyone else is asking for FreeBSD to incorparate any modifications to the current base system and/or ports collection. If and when any code is developed from this process it will be committed using normal commit and review processes. The following summary of results is based on my eyeballing of answers and should not be interpreted as being any sort of mathematically and/or scientifically valid in any manner. Number of responses: roughly 30 Summary of results: 1. Most respondents stated that both the underlaying OS and the ports collection are equally important. When a preference was shown it was for the underlaying OS in most cases. 2. On average people tend to interact with the port system once or twice a week 3. The single best aspect of the ports system according to respondents is dependency tracking when installing new ports 4. The single worst aspect of the ports system according to respondents is dependency tracking when updating or deleting existing ports 5. Most respondents would not change there answers tothe survey if they where new to FreeBSD 6. Almost all respondents would use a new system if it fixed their personal worst aspect of the current system 7. About 50% of respondents would use a new system if it broke the best aspect of the ports system but fixed the worst aspect 8. Length of FreeBSD usage: rough avr. of 8 years with roughly 3 year std. dev. 9. Prefered install method: ports 10. Usage roughly evenly spread among desktop, development and servers 11. Subsystem ratings (rough avr's): UI: 6 Constancy: 9 Dependancy tracking: 7 Record keeping: 9 Granularity: 9 12. Most users are either sysadmins and/or developers Orginial Survey: As has been hashed out in -ports@ over the last few days there is at least a need to examine weither or not the current ports system should remain as is or potentially be re-engineered in the future (estimates if and when needed vary from ASAP to 10-15 years). I have volunteered to undertake a feasibility/pilot project to examine what changes (if any) are needed in the system (for the purposes of this thread I will not venture any of my own suggestions). I have the following broad questions for people: 1. What is more important to your personal use of FreeBSD (the ports system, the underlaying OS, some other aspect)? 2. How frequently do you interact with the ports systems and what is the most common interaction you have with it? 3. What is the single best aspect of the current system? 4. What is the single worst aspect of the current system? 5. If you where a new FreeBSD user how would your answers above change? If you where brand new to UNIX how whould they change? 6. Assuming that there was no additional work on your behalf would you use a new system if it corrected your answer to number 4? 7. Same as question 6 but for your answer on question 3? 8. How long have you used FreeBSD and/or UNIX in general? 9. That is your primary use(s) for your FreeBSD machine(s) (name upto 3)? 10. Assuming there is no functional difference what is your preferred installation method for 3rd party software? 11. On a scale from 1 to 10 (10 being the best) please rate the importance of the following aspects of the ports system? a. User Interface b. Consistency of behaviors and interactions c. Accuracy in dependant port installations d. Internal record keeping e. Granularity's of the port management system 12. Please rate your personal technical skill level? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHX3MyzIOMjAek4JIRAqqjAJ9YlNJW9Uqa21yK+sm1IST+KmO7QACfeum+ 9rhuEkdKX6BKkFZr6WGmbDU= =jhg0 -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
