In response to Ghtry
As I said in this post before, it would be better worth Tom's time to get BYOND working 100% with WINE, then use winelibs to port it to other platforms from there.
In response to Flame Sage
In response to Flame Sage
For an example of a program that has done this successfully is Google's Picasa. It's a great program that works almost as good on Linux as it does on Windows. The vast majority of it is run using WINE(with some things setup for Linux users) so it probably takes almost no time at all to make changes to all versions, Windows or Linux.
In response to Ghtry
Yep, I think I'm out of here until I see some improvement at the least, as well. So with my last regards I do hope that the so called "money issues" become how they used to... I remember a time when BYOND was really freeware and the developers worked on the project regardless of whether it put money into their pockets. It's like a Bill Gates crisis all over again heh. Good luck to all of you other BYOND developers and cheers.

Sincerely,
Justin C. Kinnaird
JCHS Technology Administrator
In response to Tekken
BYOND is still freeware. Developers still make games for the fun of it. Seems you need to get your eyes checked.
In response to Danial.Beta
In response to Ghtry
I suppose because the pager has slightly reduced functionality, that could be seen as shareware. But label it how you want. It's free to build, it's free to play. How much more free can you expect?
In response to Tekken
Do you also remember how slow the development process was before Lummox was hired full-time? Oh, did you forget about that? Well maybe you also forgot that you need money in your pockets to pay for help in the first place.



In response to Ghtry
Actually, it's freeware. Everything in the BYOND suite is free of charge. The only perks you really get for paying for a BYOND Membership are perks on the website itself.
In response to Tekken
Tekken babbled:
I remember a time when BYOND was really freeware and the developers worked on the project regardless of whether it put money into their pockets. It's like a Bill Gates crisis all over again heh.


Wow... that almost made me use the word 'LOL' in a sentence.

As mentioned before, it would be a bit faster for Linux users to help in testing BYOND, since about 70% of it is already working under Wine. A little collaboration between BYOND users, developers, and the Wine people should knock out the remaining hurdles far faster than for Lummox to build up API documentation (of course that should probably happen at some point too).
In response to Tekken
Yeah, lets go back to the days where Tom was shoveling money into BYOND and getting nothing out of it. Things were much more fair back then.
In response to digitalmouse
No offense to Tom, and co..
They really didn't do much in the way of getting it working with wine, aside from building the BYOND Suite =)
In response to Flame Sage
Flame Sage wrote:
No offense to Tom, and co..
They really didn't do much in the way of getting it working with wine, aside from building the BYOND Suite =)


No offense to the Wine guys, but wouldn't it be their problem if BYOND works in Windows and they're making a Windows emulator? I'd rather see the development team work on the Linux version itself.

Of course, I understand that it takes time, which costs money. Shockingly, it may take even more than the $100 "financial support" that was offered.
In response to Lummox JR
I'm really glad you're looking into this. I'd probably recommend you just let Doxygen crunch over the the whole lot (producing quite a mess of internal and external documentation stubs), then let us mark the exported symbols and internal data structures appropriately. I really don't know how you intend to handle this though, if the shared objects were open source, I'm sure we could throw patches for documentation back upstream (to you) after suitable cross-checking amongst ourselves and then we regen the documentation after it's applied.

The situation we face at the moment for a proper native Linux solution would revolve around reverse engineering those shared objects and repeating that process for new releases, which is not pleasant in the slightest. Anything you can throw us that improves on that (even if it's "the source is available as-is, go play"), while not incurring you too much hassle, would be greatly appreciated.

We essentially have two options, get BYOND working under WINE, or develop a native solution. With either, it will be us doing pretty much all the work, be it contributing to WINE, or taking charge of a native project ourselves. I personally prefer the native solution and I'm glad BYOND is considering taking steps to seriously reduce the barriers to development, even if that is making an open read-only repository for us to pull sources from, or throwing us API-stubs, because even that makes the native solution a lot easier for us than the current situation. I would not be concerned for feeling that you are dumping on us, we asked for a solution even though we are the minority, we should be the ones working for it. Ultimately, you could even not bother accepting feedback from us, if processing that creates too much work. I feel we just need that first step, to get the ball rolling.

I'm gonna have to pour scorn on some of the Linux users that have posted here thus far. Have a think about the sort of OS Linux is, and how it progresses. Linux works by it's userbase taking ownership of the various technical problems we face, because we are supposed to be the technically adept ones, with the better tool-chains and the engineering ethos. WINE is a great example of this, the project exists because Linux users cannot just expect to hassle application developers into making things OS-portable, it's just not reasonable a lot of the time. So the WINE people took ownership of the problem, and developed a solution themselves.
In response to Tom
If so much money is needed for this kind of task why not put a donation goal on the front page for all us mac/linux users to reach? With a community of 4000+, I think we'd achieve whatever goal needed to recruit an extra worker or two easily. Loads of sites do this and they often complete their goals within weeks. With ours being a goal within the 1000's, I don't see how we couldn't reach this goal in months.

Think of a single dedicated donator such as this topic starter, he pays his 100 and gets his friends to help out, so on and so on. Then there's the younger kids who'll get money from their parents and other relatives. It's hard to forget that this is a strong community with loyal people who stick around just to give back to this place and help it develop.

I've met many people on this site and in my short seven years of observation time it's surprising how much they're willing to dish out. The other day there was some guy randomly giving out memberships to the first people who visited his blogs.
In response to Hulio-G
$30,000+ per annum for a full-time Software Engineer, that's being conservative too. It strikes me as being both more practical and more 'the Linux way' (if you'll excuse the notion) to employ a mechanism that taps into the technical capabilities of the Linux userbase.
In response to Stephen001
Stephen001 wrote:
$30,000+ per annum for a full-time Software Engineer, that's being conservative too. It strikes me as being both more practical and more 'the Linux way' (if you'll excuse the notion) to employ a mechanism that taps into the technical capabilities of the Linux userbase.

If each of the 4000 (this is excluding each individuals outside connections) just donated $7.5. We could afford that worker for that one year.

Now these people are getting paid something like $15 an hour, so money from the piggy bank is getting weeded out slowly regardless. And take into account the site is growing from this extra hand so more people will come (a small portion will become members). More people, more money. Sooner or later Tom & company would be well off.

Regardless if people even donate in the masses (obviously barely half the 4000 will contribute), it'll be the individuals that are most dedicated (linux/mac users) to this goal that will give up their own earnings for the reward. This is a long term process that would benefit us in the future; sacrifice today and benefit in 09, 010.
In response to Hulio-G
Hulio-G wrote:
If each of the 4000 (this is excluding each individuals outside connections) just donated $7.5. We could afford that worker for that one year.

How's that worker going to feel about having no job security? Why would he/she quit his/her current job? What would make them pass up any other job opportunities that came along while they were employed for a year?
In response to Stephen001
We essentially have two options, get BYOND working under WINE, or develop a native solution. With either, it will be us doing pretty much all the work, be it contributing to WINE, or taking charge of a native project ourselves. I personally prefer the native solution and I'm glad BYOND is considering taking steps to seriously reduce the barriers to development, even if that is making an open read-only repository for us to pull sources from, or throwing us API-stubs, because even that makes the native solution a lot easier for us than the current situation. I would not be concerned for feeling that you are dumping on us, we asked for a solution even though we are the minority, we should be the ones working for it. Ultimately, you could even not bother accepting feedback from us, if processing that creates too much work. I feel we just need that first step, to get the ball rolling.

I'm gonna have to pour scorn on some of the Linux users that have posted here thus far. Have a think about the sort of OS Linux is, and how it progresses. Linux works by it's userbase taking ownership of the various technical problems we face, because we are supposed to be the technically adept ones, with the better tool-chains and the engineering ethos. WINE is a great example of this, the project exists because Linux users cannot just expect to hassle application developers into making things OS-portable, it's just not reasonable a lot of the time. So the WINE people took ownership of the problem, and developed a solution themselves.

I have to agree, Byond as it stands support Linux where it matters, as a server. A front-end would be nice but it will bring little benefit right now. A MAC front-end would be better, but again little benefit. In the short term Wine libs should be used for porting to other OS such as Linux and MAC.

Heck if programs like pidgin for example, that have been around and are stable, can't be bothered to create a native windows client, why should byond make a native Linux client right away? Just use wine like they use GTK+ and everyone is happy (kind of).

In the current haul byond does need to document its API for internal development, relay on more cross platform code, and make money.

In the bigger picture I see byond more like JAVA, and I think that should be the direction that it should be headed. DS should be the runtime and standalone (with pager support) with native clients, the Pager, IDE, and dream demon, should become independent programs as well, with a package download.

If they chose to make a dump through Doxygen or other doc program that is great, it will allow us to reverse engineer and help with the documentation. However we should expect zero-support with the effort, The staff have other things that need to be focused on.
In response to Hulio-G
While I'm not going to rule out the cash-flow benefits of donation, I'd sooner make a technical contribution than hand over money, not least because I feel a technical contribution would bring benefits to myself and the community beyond that which I could provide out of my disposable income.

The idea seems suitably technically challenging and interesting, the process would be a reward to me in itself, as well as the end product of a *nix OS-portable client. The linux way, ownership of the technical challenges and doing something because it is fun (as well as the classic Microsoft competition), strikes me as the key to success in a linux/mac client.
Page: 1 2 3 4