Roadshow for 68K -Needs your support!

[LoadWB]

Hell, yes.  I would love to patronize current Amiga development rather than continue to over-use my Miami registration since Holger apparently does not want my money.

As stated before, I think it would be beneficial to release CPU-specific binaries, unless there is compelling reason otherwise.

[LoadWB]

Building an '060 version probably doesn't hurt, though. If it's that what convinces the curious to become customers, who am I to doubt the wisdom in it?

Or you could just name a binary "roadshow-060" and pad it with a few bytes to fake some people out

The WHDLoad problem is interesting as well and, as Piru said, I recall the issue is a matter of interrupts.

My primary concern with a new TCP/IP stack is the ability to set up PPTP VPNs with encryption, and fairly easily.  I can do this with MiamiDX, but I cannot encrypt the tunnel and I cannot change target hosts very easily.

[LoadWB]

But surprisingly hard to implement. My original DHCP client code was written according to the relevant RFCs current in 2001/2002, and I tested it with the ISC reference implementation. Further tweaks were made as I upgraded my home network over the years, and following reports from the OS4 beta testers. This was not enough, though

Today's DHCP servers, as found in embedded systems, or as part of dedicated server hardware, are an odd bunch. Some expect you to carry information in the DHCP requests which according to the documentation is not even mandatory, and duplicates the information already provided in the basic BOOTP packet. Some refuse to respond to your DHCP requests unless these requests are at least 300 bytes in size. Some respond with more data than your client code stated it can handle.

These discoveries prompted a slew of changes...

This illustrates a small problem with the notion of "be liberal in what you accept, and conservative in what you send."  I have seen many network services which completely ignore the second part and absolutely demand the first, irrespective of the consequences.

I hear you. The GUI issue is still unresolved. I am not going to put any work into writing one, as I have been there and it contributed to the excessive delay in getting the product published.

I did get an interesting offer in the last two weeks which may help to resolve the GUI issue. But in the mean time, I'd rather get Roadshow "finished" as far as is this may be possible, and prepare it for a GUI-less release. I really cannot tell how long it would take to make a proper GUI for Roadshow, if that would come to pass in the first place. So it's (for now) a decision of shipping Roadshow, or not to ship it at all.

SHIP SHIP!  As for the GUI, I think leaving it without one gives the option of providing our own.  Have an officially-supported one, but not make it mandatory, that way some of us MUI-Rexx hacks or C/C++ jockeys (or E, or whatever your flavor) can make simple ones for ourselves, or even complex ones.  I am a "function over form" kind of person for the most part, so having a fast and workable TCP/IP stack is far more important to me than a pretty interface.

Some assembly will always be required. And the absensence of a GUI would have to affect the price. I don't expect Roadshow to sell in the $30+ range without a GUI.

What about a volume discount?  Seriously, I, for one, like the price notion.

[LoadWB]

But there is no packet exchange which says "I did not understand what you asked for". In place of that missing packet there is only silence. And that silence is interpreted as the complete absence of a server, which may be wrong since the server may have chosen to reject the (subjectively) malformed packet.

A cursory review of RFC 2131 would give me the notion that DHCPNAK should cover a situation of a bad client request, although the RFC only states a couple of scenarios in which the server would respond with a DHCPNAK.  I suppose that could encourage continuous bad behavior from a bad client, however.  I have never spent time delving into DHCP mechanics, and now I have yet more information that I am absolutely compelled to absorb... thanks :lol:

A problem I frequently saw in the past was that of identical IP schemes in use in multiple places.  The problem was DNS.  A laptop coming from home on 192.168.1.x would go to work and request the same IP address it was using at home.  The office DHCP server would happily approve the request, provided the IP was not in use on the network.  The client would then retain all of its network configurations including DNS, which may or may not work on the office network.  Or vice-versa.

[LoadWB]

If your code reads that original message and considers it malformed, prompting it to ignore it altogether, processing will never reach the state where a specific NAK would be sent in response.

What DHCP is lacking is a mechanism to notify the client/server of the rejection of a message prior to analyzing its meaning.

And thus I propose the DHCPSAYWHAT packet.

Sounds like a poorly-configured DHCP server to me

For example, the ISC DHCP server reference implementation allows you to lock down unsuitable address ranges, preventing clients from appropriating them.

Well, it is a pretty common issue between the LinkSys, D-Link, and Microsoft 2003 DNS services, so there you go.  But in this case it was not an issue of unsuitable address ranges, but identical ranges.  192.168.1.x at home AND at the office, so the machine would ask to use 192.168.1.100 and the DHCP server says yes, and the client keeps the same DNS settings because it does not see the need to change.

Now, it could be the client's fault and not the DNS server.  But I never bothered to sniff traffic to make that determination.  I may now just for shits and giggles.

[LoadWB]

Many open source amiga apps have become successful, been ported across multiple amiga platforms, and still get a little tlc even if not actively developed. however if you take the attitude there is no point, and don't do it, then of course, nothing will improve.

it's your project and your choice. but I think you are wrong regarding this. I actively work on multiple open source projects. it was the fact i could pick up and hack the code that got me started on them.

And many do not become successful, are completely abandoned, or relegated to commercial development.

There is an Apache module I need for my web server.  While I have programming in my background, I do not have the time to tinker with the inner workings of Apache to learn how this module works or to recreate it.  The author is uninterested in updating his patch, and only a handful of Linux distros have maintained this module.  And those distros are useless to my Solaris installations.

There are a number of really good FOSS projects which simply become abandoned.  In theory, the nice thing about FOSS is that the motivation for a project is not money, but rather the usability and necessity.  Until the developer or developers no longer find it necessary for themselves.  So, in some ways, I feel the flaw with FOSS is that projects are often necessarily selfish.

In any case, I, too, am very interested in a 68k Roadshow, and stand ready.

[LoadWB]

I dont give a flying **** to be honest.  Its a dead platform, its getting deader by the year.

Then why make your comment in the first place?  Seems like waste of energy to besmirch a dead platform.

[LoadWB]

I'm fairly new to Amiga (and brand new to this board), but I for one would also purchase this if it ever comes out. I just switched from MiamiDX to AmiTCP (thankfully someone found the mirror of the guide that shows you how to edit what needs to be edited). It's a huge perfomance boost for my 2000.  I for one would love a non-gui new stack that could do dhcp, and any resource improvements. I read through most of the thread, and am kind of disappointed in the nay-sayers. I think anyone who has the skills to make something for old hardware is awesome. I mean, they are making Commodore PET storage devices now. I don't think anyone should depress anyone else for being creative, even if it only helps one person.

You can put me on the "will buy" list, you know, as long as it's not too expensive.

whdload was expensive to me since I'm poor, but I am all for supporting people who have the knowledge to support the hardware I love. Besides, shouldn't we let the market decide? If nobody buys it, then he has the answer, if a ton of people buy it, then even better. The price can also be adjusted!

More power to you Olaf!

Well said, and +1 Insightful.  Welcome to Amiga.org.

[LoadWB]

I suffered for my art, now it's your turn

I feel ya. :drink:

There are plenty of times I have to deal with my own customers telling me how "all that has to be done is x."  *sigh*  None the less, with MUI and MUIRexx, just about anyone here who knows all that needs to be done could throw together a simple GUI.

Anyone want to be the hero?  Just sayin'.