Linux version - who needs/wants it ...
David Guest
would still entice me and many others and perhaps be a fair return ...
and I agree you should have to have FF for Delphi as a starter
Hannes Danzl [TPX]
ps: no promises!
--
Hannes
-> Han...@danzl.lznad.at (remove .lznad) / http://www.danzl.at
FF Foundry at http://community.turbopower.com/
Newsgroup search at http://www.tamaracka.com/search.htm
Fixes and updates at ftp://ftp.turbopower.com/pub/flash/updates/
Mark Rohde
like to see a bundled price for the two or an upgrade price to move to
Linux. At this stage it would be for hobby only as our client base is
entrenched in M$.
Mark Rohde
"Hannes Danzl [TPX]" <Han...@danzl.lznad.at> wrote in message
news:gJWR6kfh...@tpsmail01.turbopower.net...
Richard Wilson
here]
For full server and client that can work in Kylix I would say $250 US
In both cases for existing users of FlashFiler.
Certainly I have very considerable interest. I seem to be having to go down
the PHP road and it would wonderful if I could connect to FF on a Linux box
in PHP.
Richard Wilson
"Hannes Danzl [TPX]" <Han...@danzl.lznad.at> wrote in message
news:BtfJtlfh...@tpsmail01.turbopower.net...
> btw. I'm talking about the server for a starter!
Hannes Danzl [TPX]
--
Eric Schreiber
>... and what would you think to be a fair price tag ...
That's the sort of thing that would very likely give me that final
push to start developing with Kylix.
Server-only isn't hugely attractive to me, but I'd probably be willing
to pay around $150 for it.
For both client and server, I think a 'new' price in the neighborhood
of $400 would be reasonable. Hardcore Linux people may be used to
getting things for free, but most of us here (I hazard to guess)
wouldn't balk at paying reasonable prices for decent tools for Linux.
Some sort of bundled pricing (Kylix/Delphi FF) or deep upgrade
discount would be spiffy. Especially since I'd want to save some money
to buy a new machine for Linux!
Umberto Di Gioia
since I asked for FF4Linux from the beginning, I couldn't miss this
opportunity...
I see two distinct paths to follow:
1) FF4Linux Server only (no source code) at $100/150
2) FF4Linux Server+Client (with source in Kylix) at $250
I would use option 1 when I'd like to "upgrade" an existing Windows network
to a Linux-based server and a moltitude of Windows PCs (which already have
their MS OS license).
In this case what I end up is a very stable (I hope) sever (both OS and
database) and several PCs connecting to it as usual (TCP/IP); the advantage
being that I could still develop in Delphi 5.
Option 2 would be reserved for an all-Linux solution: server and clients
using Linux and me developing with Kylix on an Linux PC.
In other words, just wiping out any MS stuff :-)
Hope to see any FF Linux soon. Thank you for your eventual effort.
Umberto
Ed Jones
under RedHat 7 as Kylix3 supports this but if there was to be a Linux ver of
something I am familiar with which I know I can rely on, that would be very
interesting indeed...As for price around $200-$250.
Ed Jones
Development
NVS Ltd
"Hannes Danzl [TPX]" <Han...@danzl.lznad.at> wrote in message
news:BtfJtlfh...@tpsmail01.turbopower.net...
Srinivasan Iyer
tuned Linux OS with FF Server and a web interface. As for clients are
concerned, I am ok with MS for time being. I don't expect any thing else to
be run from this box and once installed, chances are web would be the only
way to control this box. I would pay $250.
Srini.
"Umberto Di Gioia" <xdig...@xdigifarx.com> wrote in message
news:rWn8ULmh...@tpsmail01.turbopower.net...
Rodrigo Gómez
I'm certanly interested.
I think that, as others have say, a price around $200-300 would be fair for
the client and server version of FF.
The server only is attractive, but only if your customer have a linux box as
server, or want to. The real interesting one is the client and server
approach. For the server I would pay, as the others, $100-150. Off course
this is for a redistributable version, isn't?
As now we are starting to write our Christmas wishes... it should be
compatible with Kylix 3, as some of us are used and like to, most of all, to
program in C++. I don't know if with Kylix the things are more or less the
same as with Delphi/C++Builder, but I guess this shouldn't be a big problem.
Also, it would be nice, if it was possible to do it... mhm... how to say...
with a kind of CLX.net, this way you could kill 3 birds from one shot:
Windows-Delphi pre .net compatible, Delphi .net compatible, and Kylix
compatible. I guess this IS A BIG deal, but it would be very interesting.
Maybe I'm just getting off the road, but...
Regards,
Rodrigo Gómez
"Hannes Danzl [TPX]" <Han...@danzl.lznad.at> escribió en el mensaje
news:gJWR6kfh...@tpsmail01.turbopower.net...
Tor Tveitane
news:rWn8ULmh...@tpsmail01.turbopower.net...
> I see two distinct paths to follow:
> 1) FF4Linux Server only (no source code) at $100/150
Would it then be possible to have a solution for 'custom' fftbcryp
solutions?
Tor
William E. Mahaffey
Linux. I have just purchased Kylix and will not be able to do much with it
until there is FF for Linux. I will buy just FF Server for Linux when it is
available but will be anxiously awaiting the FF Client for Kylix.
Pricing should be along the same lines as for Windows. Hopefully a bundle
for those of us who wish to work in both the Windows and Linux world. Also
maybe a credit for those who purchase just server then want the Client.
Hope this helps and there is enough interest for TurboPower to get us a
Linux version.
Thanks for the opportunity to offer my 2 cents worth.
William
"Mark Rohde" <mro...@agdata.com.au> wrote in message
news:293Mowih...@tpsmail01.turbopower.net...
Kristinn Siguržórsson
if ffserver was located on a dedicated server, with MS licensing cost being
so high it hasn't been a realistic option for us, neither has adapting our
software to run with mySQL either.
However with a Linux version of ff on the market you can be sure that you
will need to ship a box to cold Iceland!
Pricing should be similar to current ff prices with update discounts.
Regards,
Kristinn Sigurthorsson
Snerta inc.
Anthony Eischens
approaching thanks to Microsoft's efforts at alienating the little user.
Now if SBS included XP Pro licenses as well maybe they would stand a
chance...
I would pay the same price for FF Linux as FF Windows but would expect a
discount for having both Win and Lin versions.
Anthony
"Kristinn Sigurţórsson" <kris...@snerta.is> wrote in message
news:Xns92C018430E1D0...@65.166.141.191...
chuck
something like that would be great. CLient is not that important for the
moment, because getting the complete app to linux would need some other libs
and the clients won't change easily to linux.
Chuck
"Srinivasan Iyer" <iy...@optonline.net> schrieb im Newsbeitrag
news:dpfYMfmh...@tpsmail01.turbopower.net...
Hannes Danzl [TPX]
it gave me enough info for giving it a try.
i'll update you in 1-2 weeks on the progress. please note that these 1-2
weeks is the time for me to estimate the total time needed to convert and
test.
I'll make a final decision on if (i give it a go) and when (end of year, q1
2003, ...) afterwards.
-------------------------------------------------------------------
Also note: this is MY development, NO official Turbopower version.
-------------------------------------------------------------------
To wrap the responses (and add some of my own) to one list:
* server for a start is ok
* client is wanted too
* (full) server price (w/o source) up to 200$
* (full) server price up to 250$ (w. source)
[note: not easily possible, cause i can't publish tp source!]
* (full) complete version up to 400$ (w. source)
[note: not easily possible, cause i can't publish tp source!]
* (upgrade win32) server price up to 150$ (w/o source)
* (upgrade win32) server price up to 250$ (w. source)
* (upgrade win32) complete version up to 250$ (w. source)
[will come as a source patch to the original win32 sources]
* executable only server needs external callback for encryption
* server user interface will be web only(!) -
i don't see a disadvantage and it's much easier to implement ...
* a (software) blackbox installation would be interesting
(for both win and/or linux) with remote support (of course not done
by me, but by an interested thirdparty??)
Object now or stay silent forever <g>
--
Hannes
-> Han...@danzl.lznad.at (remove .lznad) / http://www.danzl.at
FF Foundry at http://community.turbopower.com/
Newsgroup search at http://www.tamaracka.com/search.htm
Fixes and updates at ftp://ftp.turbopower.com/pub/flash/updates/
"Hannes Danzl [TPX]" <Han...@danzl.lznad.at> wrote in message
news:gJWR6kfh...@tpsmail01.turbopower.net...
Ed Jones
asked for version of FlashFiler. My only reservation is your second from
last point:
> * server user interface will be web only(!) -
This fills me with dread as the web interfaces I have comes across for Win
packages have been less than easy to use and slow despite the initial good
idea (Norton Antivirus for Microsoft Exchange springs immediately to mind).
If you are going to go this route, would it be possible to also do a normal
Linux app along side the web based version so we can have a choice about
which interface we use to configure the server?
Many thanks, and good luck!
Edward Jones
Development
NVS Ltd
"Hannes Danzl [TPX]" <Han...@danzl.lznad.at> wrote in message
news:WHzrhwb...@tpsmail01.turbopower.net...
Clara
Curt
Curt
Hannes Danzl [TPX]
--
Hannes
-> Han...@danzl.lznad.at (remove .lznad) / http://www.danzl.at
FF Foundry at http://community.turbopower.com/
Newsgroup search at http://www.tamaracka.com/search.htm
Fixes and updates at ftp://ftp.turbopower.com/pub/flash/updates/
"Curt" <no...@nowhere.com> wrote in message
news:OPz2ISqi...@tpsmail01.turbopower.net...
Hannes Danzl [TPX]
it's not a big loss anyways ...
--
Hannes
-> Han...@danzl.lznad.at (remove .lznad) / http://www.danzl.at
FF Foundry at http://community.turbopower.com/
Newsgroup search at http://www.tamaracka.com/search.htm
Fixes and updates at ftp://ftp.turbopower.com/pub/flash/updates/
"Clara" <he...@there.com> wrote in message
news:qp$#44liCH...@tpsmail01.turbopower.net...
Paul Motyer [TPX]
>Doing some TCP/IP tests myself, I agree with your findings
> of 2-6x speedup using blocking winsock.
Hi Keith!
It's not clear to me whether blocking (vs non blocking) or thread
context switching is the cause of the speedup
> using Block size's of 1024 Bytes appears to have
> a much better effect on performance, when handshaking
> is required.
what handshaking are you referring to here?
> So having the option to pad
> to 1K block size may give more performance.
Do you mean setting the socket send/receive buffer sizes?
ie: setsockopt(s, SOL_SOCKET, SO_RCVBUF ...
& setsockopt(s, SOL_SOCKET, SO_SNDBUF ...
--
,-._|\ Paul Motyer [TPX]
/ Oz \ SoftStuff P/L
\_,--._/ [paul.motyer at tpx.turbopower dot com]
v
Keith Johnson
> YEEEEESSSSS! internal tests show a 2-6x speedup of tcp prot :-) so i
> think it's not a big loss anyways ...
Hi Hannes,
Doing some TCP/IP tests myself, I agree with your findings of 2-6x
speedup using blocking winsock. This is something I've mentioned
before, and would make FF2 realy fly. As well as 2-6x speed increase
I've also found the CPU usage is less, this of course would mean that FF
Server could handle even more connections.
Here is some more finding I've found using TCP/IP..
Using 127.0.0.1, with Naggle On or Off, has no effect, but using Block
size's of 1024 Bytes appears to have a much better effect on
performance, when handshaking is required. So having the option to pad
to 1K block size may give more performance.
Don't use Overllaped IO, it's not needed for blocking sockets, and on
some 95 machines can in fact give a BSOD (especially if pushed).
There's my 0.00001c worth of info..(for now) <g>
Keith..
Keith Johnson
@tpsmail01.turbopower.net:
Hi Paul,
> "Keith Johnson" wrote
>
>>Doing some TCP/IP tests myself, I agree with your findings
>> of 2-6x speedup using blocking winsock.
>
> Hi Keith!
>
> It's not clear to me whether blocking (vs non blocking) or thread
> context switching is the cause of the speedup
This I found out, from personal experience, I wrote my own C/S based
database that interfaced to Sovreign Line 100 files, at first I used Aysnc
calls, when I converted to Thread blocking the speed increase & CPU usage
reduction were amazing, this speed increase might also be due to the fact
that you don't need to maintain state information for connected user etc,
this would be part of the connection thread. Also using blocking sockets
makes the code so much easer/neater to read.
Internally I also wonder what the OS is doing when you use Aysnc calls..
>> using Block size's of 1024 Bytes appears to have
>> a much better effect on performance, when handshaking
>> is required.
>
> what handshaking are you referring to here?
What I'm refering to, is that when you send a block of information, in a
lot of circumstances your going to need some sort of aknowledgment etc. I
class this as handshaking, not just a simple ACK/NAK neither. This is were
a lot of speed is lost in TCP/IP when flipping between Send & Rcv.
>> So having the option to pad
>> to 1K block size may give more performance.
>
> Do you mean setting the socket send/receive buffer sizes?
> ie: setsockopt(s, SOL_SOCKET, SO_RCVBUF ...
> & setsockopt(s, SOL_SOCKET, SO_SNDBUF ...
No, I found this never had much effect on performance, well not over
LocalHost anyway. Some experiments over a real network would be required
here.
What I mean is padding the send Block to 1024 bytes, it appears to make the
next Rcv call return faster. It's as if there is still some sort of low
level Naggle going on.
Another option that's nice, is the SOL_SOCKET, SO_KEEPALIVE. I've not
tested it, but this may even take into account when a Thread has gone to
sleep doing some long blocking task, currently FF would lose it's
connection in these circumstances. But because SO_KEEPALIVE is OS
controlled this might not happen..
Regards
Keith..
Paul Motyer [TPX]
> at first I used Aysnc calls, when I converted to Thread blocking
> the speed increase & CPU usage reduction were amazing
I'm working on new Transports at the moment
I have 2 new ones basically done - a SharedMem one and a Blocking TCP
one. The speed increase is impressive and the relativities are
variable - depending on the average message size (the bigger the
message size the better SharedMem performs).
Here's a sample using a table with 47,000 records and a Record length
of 1,549 bytes
SharedMem: 22.2 times faster than Legacy TCP
Blocking TCP: 5.4 times faster than Legacy TCP
Legacy SUP: 3.0 times faster than Legacy TCP
Here's what it is for a record length of 28 and a table of 34,000
items:
SharedMem: 20.8 times faster than Legacy TCP
Blocking TCP: 6.3 times faster than Legacy TCP
Legacy SUP: 3.4 times faster than Legacy TCP
So, the new Transports are both roughly 6 times faster than their
Legacy counterparts
These are all on one machine - I haven't tested across a LAN yet
> Another option that's nice, is the SOL_SOCKET, SO_KEEPALIVE.
The new transports can use or ignore the old Keep Alive stuff - and
turning on SO_KEEPALIVE seems to slightly reduce performance
I ignore it and let the socket work it out (when it sends or recv's)
(in SharedMem I use a different method) - thus, hopefully, no more
spurious disconnections. However, this means unexpected disconnections
can block for 30 secs (OS/Stack dependent timeout). Clients will
notice that but the server doesn't care.
Keith Johnson
@tpsmail01.turbopower.net:
Hi Paul,
> "Keith Johnson" wrote
> SharedMem: 22.2 times faster than Legacy TCP
Interesting, IPC, I've used IPC in one of my application's, and it would
certainly be better than SUP. I assume you must create a seperate
FileMapping for each connection otherwise Mutex Locks would slow it
down. Also I assume you created your own Streaming system as
SharedMemory does'nt have one.
When I used IPC, I created a FIFO buffer where the the First 2 bytes
were the start and the next 2 were the end. I then used this to create
a Stream with. I also found that increasing the size of the FileMapping
greater than 4096 bytes did'nt make performance any higher. But this
might differ with FF when it comes to using large Blobs.
Your doing exactly what I would do, if I had the time. And I hope you
can get it all working like a dream. Will you be sharing your
findings?, and can I be of any help?
Also what component are you using for Winsock?..
Here are some timings I've found using my custom winsock class, on
localhost(127.0.0.1), with a Pentium 800 laptop.
1.100Meg without ACK using 1K blocks = 5.5 secs.
2.100Meg with ACK using 1K blocks = 13 secs.
3.100Meg without ACK using 512bytes = 5.5 secs
4.100Meg with ACK usign 512bytes = 21 secs
Option 1 & 3, of course would'nt be of any use, as most messages are
going to have some form of Response.
Regards,
Keith..
David Guest
Keith Johnson
Hi Hannes,
>> Also what component are you using for Winsock?..
>
> i've tested here with indy, ics, synapse, the basic delphi ones and
> direct api calls. well, all the components add quite an overhead.
Yes, I've found that Component based Winsock's are a bit too much. I
used Indy when it was Winshoes's and even then it was a bit bloated.
Delphi's built in winsock implementation was also slow, but worse still
was the fact it used Overlapped IO, that just BSOD 95 machines when
pushed.
Idealy any Winsock implementation for FF also want's to be Class based
rather than component based. I'm willing to contribute my class based
winsock to FF, it's tested to the extreme so I know it's going to be
reliable. But what I realy need to do is re-partition my Hard drive to
get Linux installed so that I can make a duel implemention for this
class, as this was the original reason for this thread.. :)
Keith..
Hannes Danzl [TPX]
i've tested here with indy, ics, synapse, the basic delphi ones and direct
api calls. well, all the components add quite an overhead. especially indy
behaved very badly (basic implementation of blocking calls with indy was
actually ~30% SLOWER than the current legacy - as said without optimizing;
is suspect it was the proposed string access instead of the direct buffer
access and the antifreeze stuff), ics was about double the speed of indy,
synapse another 40-60% faster. my current solution uses indy for connection
and thread handling (because it's very convenient, easy to read and follow)
and pure api calls (send and recv) for established connections and it's
about 1.5 times the speed of the fastest component usage ...
the current trials with io completion ports seem to bring another speedup,
but it's currently not stable enough to run through a prper testcase. sleuth
stopwatch and lineprofiler results look promising though ...
Keith Johnson
@tpsmail01.turbopower.net:
> "Keith Johnson"
>
>> Also what component are you using for Winsock?..
>
> I wrote my own - took a few days because I wanted it to go as fast as
> I could get it
Yes, that's why I wrote my own too, I also wanted the ability to handle
timeout's in a blocking enviroment without effecting performance. Also
rather than been Component based, there class based using Override's
rather than Events.
>> as most messages are going to have some form of Response.
>
> Is the ACK a socket thing - or the sending back of a small Ack
> packet? - Because, basically, every Client Request gets a Server
> response which makes any other ACK superfluous
When I talk about ACK, it's any form of ACK this in FF would indicate
Success/Failure of the previous request etc. Also it should be possible
for a request not to have response, examples of these could be non
urgent request like those used in Chat Apps, but most would of course
require one. Also a performance increase may be made by using Out-Of-
Band data packets, this may come in handy for functions like First/Next
that dont have a result but could generate an Exception. (I've not done
any test's on OOB as yet, I will have a look tommorow)..
Regards
Keith..
Hannes Danzl [TPX]
linux in a vmware session :-)
--
Hannes
-> Han...@danzl.lznad.at (remove .lznad) / http://www.danzl.at
FF Foundry at http://community.turbopower.com/
Newsgroup search at http://www.tamaracka.com/search.htm
Fixes and updates at ftp://ftp.turbopower.com/pub/flash/updates/
"Keith Johnson" <Ke...@saxon.co.uk> wrote in message
news:Y6lgNG3...@tpsmail01.turbopower.net...
Paul Motyer [TPX]
> Also what component are you using for Winsock?..
I wrote my own - took a few days because I wanted it to go as fast as
I could get it
> as most messages are going to have some form of Response.
Is the ACK a socket thing - or the sending back of a small Ack
packet? - Because, basically, every Client Request gets a Server
response which makes any other ACK superfluous
--
Keith Johnson
@tpsmail01.turbopower.net:
> if your machine has a +>800 mhz cpu and =>256 mb ram you can happily run
> linux in a vmware session :-)
Hi Hannes,
I was wondering about that, but have heard they can be minor compatiblity
issues,. If Delphi7 works inside VmWare then that would be great, is that
how your using it?
Also what version of Linux are you using?. We had Delphi6 on Mandrake8 and
it was a pain.
Regards,
Keith..
Keith Johnson
news:j2t6tu4pst4flbbum...@4ax.com:
> I assume you mean Kylix.
Yes I mean Kylix. (But I prefare the phrase Delphi for Linux)
> According to some articles on the Borland
> site, the Borland R&D used Vmware for development. Having several
> flavors of Linux available otherwise would be a nightmare.
Sorted, if it's good enough for Borland it should be good enough for me..
:-)
I think it's time for me to get the latest version of VmWare..
Regards,
Keith..
Franz-Leo Chomse [TPX]
>"Hannes Danzl [TPX]" <Han...@danzl.lznad.at> wrote in news:q7jAZc3iCHA.4080
>@tpsmail01.turbopower.net:
>
>> if your machine has a +>800 mhz cpu and =>256 mb ram you can happily run
>> linux in a vmware session :-)
>
>Hi Hannes,
>
>I was wondering about that, but have heard they can be minor compatiblity
>issues,. If Delphi7 works inside VmWare then that would be great, is that
>how your using it?
I assume you mean Kylix. According to some articles on the Borland site, the
Borland R&D used Vmware for development. Having several flavors of Linux
available otherwise would be a nightmare.
Regards from Germany
Franz-Leo
Franz-Leo Chomse(mailto:Franz-Le...@tpx.turbopower.com)
FF Foundry at http://community.turbopower.com
Newsgroup search at http://www.tamaracka.com
Hannes Danzl [TPX]
> issues,. If Delphi7 works inside VmWare then that would be great, is that
> how your using it?
haven't seen any problems with vmware since a long time. we are using it for
all our testing for different platforms and even for developing (e.g. apps
that use serial connections). if you have enough memory and run vmware in
fullscreen, you can't see a real big difference between the host and the
client. all are using bridged network and connect or mount all shares into
disks/directories on the client
> Also what version of Linux are you using?. We had Delphi6 on Mandrake8
and
> it was a pain.
we are using mandrake 7, 8 (now 9), redhat 6.x, 7.x and now 8, suse 7.x and
now 8.1.
i've not done the installations, i just use the virtual machines from our
network/dvd.
we have also win95 (orig+patched), win98, win98se, winnt4, win2k
(pro+server), winxp and several Win.net beta versions running on it. these
are in different flavours: from clean install to full feature visual studio
everett development installations :-)
Paul Motyer [TPX]
> Are you thinking of releasing ShareMem Transport?
Yes - when it's in a fit state. It's a local machine only transport -
sorta like SUP but faster
--
Paul Motyer
Keith Johnson
>
> I think it's time for me to get the latest version of VmWare..
>
Grrrrr,,
not having much fun trying to get Mandrake 8.0 working with VmWare.
After installing it just say LILO 21.7 on reboot
Now I remember why I gave up trying to use Kylix..
Keith..
Mark Rohde
Are you thinking of releasing ShareMem Transport? I'd be interested in
giving it a go (even in beta as I am now in the development cycle of our
product and wont be releasing for some time)
Mark Rohde
"Paul Motyer [TPX]" <nos...@no.spam.com> wrote in message
news:EbJFUXz...@tpsmail01.turbopower.net...
Keith Johnson
@tpsmail01.turbopower.net:
> Grrrrr,,
> not having much fun trying to get Mandrake 8.0 working with VmWare.
> After installing it just say LILO 21.7 on reboot
> Now I remember why I gave up trying to use Kylix..
>
> Keith..
I've managed it, I used RedHat7 and it works a treat, I don't know what
Mandrake have done, But getting RedHat7 working with VMWARE full color was
easy. And Kylix works a treat too.. I think I'll start playing with
Sockets on Kylix now, and make a compact winsock class that will work with
Kylix & Delphi..
Keith..
George Spears
Just a thought here.... Since you do not have the legal authority to publish
TP source code, and obviously people want source around here <grin> why not
see if TP will contract you to port FF to Linux, but then they own the end
result. That way you would be paid for your effort, Linux FF source would
be available, and either you or TP could continue efforts for future
releases...
GS
"Hannes Danzl [TPX]" <Han...@danzl.lznad.at> wrote in message
news:gJWR6kfh...@tpsmail01.turbopower.net...
> ... and what would you think to be a fair price tag ...
>
> ps: no promises!
>
> --
> Hannes
>
>
> -> Han...@danzl.lznad.at (remove .lznad) / http://www.danzl.at
> FF Foundry at http://community.turbopower.com/
> Newsgroup search at http://www.tamaracka.com/search.htm
Sean Winstead [TurboPower]
>Just a thought here.... Since you do not have the legal authority to publish
>TP source code, and obviously people want source around here <grin> why not
>see if TP will contract you to port FF to Linux, but then they own the end
>result. That way you would be paid for your effort, Linux FF source would
>be available, and either you or TP could continue efforts for future
>releases...
He may not need to publish any TP source code.
Hannes Danzl [TPX]
publish
> TP source code, and obviously people want source around here <grin> why
not
> see if TP will contract you to port FF to Linux, but then they own the end
> result. That way you would be paid for your effort, Linux FF source would
> be available, and either you or TP could continue efforts for future
> releases...
if i would be tp, i would let me first finish an alpha or beta version and
then consider such a schema, after all it could be complete vapor ware i'm
talking about here <g>
Sean Winstead [TurboPower]
>well i hope you have a tool for this ...HAVE you ???
Yes, I do.
Sean Winstead [TurboPower]
>although no official
>agreement was made, it seems i have full support on needed changes to the
>source base from TP :-))
Yes, even though it means changing the case of certain words in every
stinking unit of source code <g>.
Hannes Danzl [TPX]
<g> let's see, but everyone who is interested: although no official
agreement was made, it seems i have full support on needed changes to the
source base from TP :-))
--
Hannes Danzl [TPX]
--
Hannes
-> Han...@danzl.lznad.at (remove .lznad) / http://www.danzl.at
FF Foundry at http://community.turbopower.com/
Newsgroup search at http://www.tamaracka.com/search.htm
Fixes and updates at ftp://ftp.turbopower.com/pub/flash/updates/
"Sean Winstead [TurboPower]" <se...@turbopower.com> wrote in message
news:1nkvuu83lctn302l2...@4ax.com...
Curt
I need it.
I want it.
Curt
"George Spears" <not given> wrote in message
news:jPCsDnK...@tpsmail01.turbopower.net...