Re: [B2-devel] Thoughts on SheepShaver and Basilisk II

[Frank T. <fra...@gm...>]

On Fri, Jun 15, 2012 at 11:13 AM, Diskutant <dis...@go...>wrote:

> I'm 100% with Alexander!
>
> It's so much easier to use GitHub, I fork projects with a simple click, do
> changes, those are public for everyone and if I think I finished something
> good I ask the main repo to just pull my changes. I love it!
> Just because I know how to use CVS doesn't mean I want to. Besides, one
> would need write access.
> I created a repo on GitHub already, I'm just not happy with the way I did,
> so I might delete it, create a repo for SS and Basilisk and then work my
> way on moving everything needed from the Basilisk repo into the SS one.
> The problem then would be to stay up to date with the few changes that are
> still happening to CVS, I might just do that manually...
> Anyway, I'm highly interested in the project, I just don't want to use
> some stupid stuff like CVS anymore.
>
> And SS is everything but mature. There is so much stuff that need fixed.
> It crashed a lot, it needs updates to be more user friendly, more
> compatible, more everything.
>

These problems tend to result from large structural problems or design
decisions (the memory management system and the choice to intercept
specific Mac O.S. functionality rather than emulating the hardware) rather
than from small bugs. The problems have never been sufficient, at least for
me, to justify rewriting everything as would be necessary to correct those
problems.


> The GUI of SS sucks hard, well, that little that is there, it needs more
> GUI, and yes it's easier to just change the config file, that's because the
> GUI sucks!
>

I made an automatic configuration tool for Mac O.S. that creates a user
profile and makes a copy of the system disk image. I can upload it
somewhere if you like.

If you want to make a new configuration editor, I would suggest starting
from the beginning with a tool that reads and writes configuration files.
GLIDE might be nice for this.


> I understand that some ppl just like to do configs in a file with vi but a
> normal user doesn't. There would be more users if it were much easier to
> use, and much more compatible. Many users just want to play some old games.
> Check Boxer, it did something really great out of just a DOS Box. No one
> really wants the pain which comes with DOS Box, but Boxer hides all that
> and has a good fanbase because it's easy to use and it looks great. It's a
> Mac thing afterall.
>
> DOSBox is a consumer tool. I think that most people use it for playing
games. (I tried to get AutoCAD R13 working once, but that did not go well.)
I am satisfied with its configuration options, but I understand that a
large portion of its target user base would benefit from additional
support. If you want something like DOSBox, use Mini vMacs.

SheepShaver is not a consumer tool for several reasons.

One is that there are already good products for most of what it does. Most
people can find Windows or 68K versions of the games or applications that
they need, so SheepShaver is not necessary for them. Other applications run
nicely in the classic environment for O.S. X, so one can put 10.4 in a
PearPC wrapper and run the stuff there.

SheepShaver is written as a wrapper for classic versions of Mac O.S. rather
than as a machine emulator. This has performance benefits, but it also
means that the unstable operating system can and does crash SheepShaver
quite often. In my experience, SheepShaver is about as stable as a System 7
Macintosh. One could add checks so as to keep the operating system from
crashing the emulator, but that doesn't stop the operating system from
crashing itself.

SheepShaver is also at a disadvantage in terms of bundling. Due to the
legal issues involving the ROMs and the operating system, it is impossible
to offer SheepShaver as a ready-to-go tool like DOSBox. Likewise, its
complexity creates a bit of a library mess, so distributing even just the
executable is much more complicated than for something like Mini vMacs.
Likewise, the complicated in-line assembly code breaks compilation on
clang-llvm, which is a problem since that is what Apple ships as of Lion.

In the interest of improving distributability, I made a bundle for Mac O.S.
that includes the required libraries and such as well as the previously
mentioned profile assistant. It ought to run on Macintoshes for the
forseeable future. I uploaded it to 4Shared (
http://www.4shared.com/file/WZkaMsut/SheepShaver-23-Chicago-2012061.html ).
Just untar it, put it in /Applications, replace the blank
Classic_Drive_1.img file with your classic drive, and go. I also fixed some
memory leaks in this version, in part by disabling the configuration
editor. I will try to find the source code in the near future.


> Alex, I would say just import the CVS code into GitHub or where ever you
> like, let us know and we just might move over. :-)
>
> Thanks.
>
>
> Am 15.06.2012 um 17:48 schrieb Frank Trampe:
>
>
>
> On Fri, Jun 15, 2012 at 10:17 AM, Alexander von Gluck <
> kal...@un...> wrote:
>
>> On 15.06.2012 09:45, Frank Trampe wrote:
>> > On Fri, Jun 15, 2012 at 8:43 AM, Alexander von Gluck
>> > <kal...@un... [4]> wrote:
>> >
>> >> Good morning,
>> >>
>> >> I've been a off and on user of SheepShaver and Basilisk II for *years*
>> >> (and
>> >> years, and years). It offers decent
>> >> emulation and is the best emulator out there for classic MacOS.
>> >>
>> >> Over the last 5+ years... not a lot has changed. Here is my take on
>> some
>> >> of
>> >> the current limitations of the project:
>> >>
>> >>  * CVS
>> >>    Most projects left cvs for other version control software years ago.
>> >> Much
>> >> better source revision control software
>> >>    exist. If there aren't many developers out there who know how to use
>> >> the
>> >> revision tracking software for a project...
>> >>    no one will know how to (or want) to contribute.
>> >
>> > The instructions on the download page work quite well. They may have
>> been
>> > updated since you last checked (although at
>> > least five years ago).
>> >
>> > cvs is not any more difficult to use than other revision control
>> systems.
>> > It lacks some of the features of svn and
>> > git, but those are not necessary for a project with so few contributors
>> > and so few commits.
>>
>> This seems like a self-fulfilling prophecy. Why do we have so few commits
>> and interest? why should we move away from
>> a 21-year old overly complex version control software that no one uses
>> anymore?
>>
>> I do not think that the lack of commits to the project results from
> people turning their noses up at the revision control system. Those who are
> interested in the project do not make many commits because the product is
> mature. Those who are not interested in the project lack interest because
> they do not need such a product as SheepShaver. SheepShaver is a bit of a
> niche product since Mini vMacs works so well for those who do not need
> PowerPC emulation.
>
>
>> > The project does not need contributors who cannot figure out how to use
>> > cvs. It does not lack for features. It just
>> > needs some work on the memory access stuff, which is the sort of thing
>> > that is so complicated that only somebody who
>> > has already been a long-time contributor to the project could do it.
>>
>> Open source development is an evolving ecosystem, a healthy project has
>> users come and go improving parts they find
>> interesting.
>>
>> Assuming someone wouldn't know how to write an MMU to perform physical to
>> virtual address translation based on the
>> fact that they don't know how to use a 21 year old version control system
>> which hasn't seen a major update in 6+ years
>> is a pretty strange assumption.
>>
>> I am not expecting somebody to have a prior background with cvs; I would
> rather be concerned about the technical abilities of somebody who can't
> figure out the three or four commands necessary to use it. Is this concern
> unreasonable?
>
>
>> >>  * Complexity
>> >>    I remember being an early user and struggling figuring out how to
>> >> compile
>> >> SheepShaver. Needing to check out
>> >>    two different source trees and have a script smash them together via
>> >> symlinks was pretty hard to figure out.
>> >
>> > This is quite simple now. You check out the two source trees in the same
>> > directory, change to the SheepShaver
>> > directory, run make links, and then build for your platform. I do not
>> need
>> > to make any changes in the Basilisk II
>> > tree
>> > as mentioned in the instructions. A top-level configure script might be
>> in
>> > order, but my configuration needs are
>> > simple enough that I have not been tempted to write one.
>> >
>> > With respect to solving the supposed problem of having separate source
>> > trees for the two products, what is your
>> > proposal? To eliminate SheepShaver's dependency upon the Basilisk II
>> > components? It seems best to me to continue to
>> > share the common code since, otherwise, changes would probably not
>> > propagate correctly to both trees.
>>
>> Right, however the tangled web of symlinks makes development on either
>> project difficult. Who would want to
>> clean up a repo that several other projects depend on static file
>> locations?
>>
>> I just ignore the symlinks and edit the files from the SheepShaver tree.
> There is certainly room for improvement in the directory structure, but I
> have not found this to be a great obstacle to development.
>
>
>> >
>> >> r>
>> >>
>> >> The SheepShaver project is not responsible for the design of Mac O.S.,
>> >> and Apple is not
>> > he classic versions anymore. If you do not like it, consider using a
>> > different operating system. (What do you think
>> > of
>> > Haiku?)
>>
>> The *SheepShaver* interface, not the MacOS classic UI.
>>
>> Are you talking about the configuration editor? It has memory leaks and
> other problems, and nobody seems to need it anyway, so I disable it
> whenever I compile SheepShaver. It is much easier to edit the configuration
> file.
>
>
>>
>> Given the responses above, and the complete lack of activity on the
>> mailing
>> list over the years... it seems like there
>> really isn't any interest in keeping the project alive as an evolving open
>> source application. (which may also explain
>> why there has been little interest over the years)
>>
>> The project is not dead. The issue is more that it does not require much
> evolution in order to suit people's needs. I needed to make some changes to
> an internal version of SheepShaver about a year ago in order to support
> compilation on 64-bit architectures, and Alexei made similar changes at
> about the same time to the active tree, but there simply aren't many things
> left to be done. We had a flurry of commits (all from Alexei) this past
> winter that fixed a number of problems.
>
> There are some big issues that everybody would like to see addressed, but
> they do not stop SheepShaver from working most of the time, and they are so
> difficult to solve that it is hard to justify spending time on them.
>
> The structural changes that you propose to the project would break a lot
> of compatibility with people's custom build and patching systems.  If you
> want to evolve the project as you describe, it might be best to check out
> the sources and then to start a new repository of your choice elsewhere
> after you complete the restructuring that you have in mind.
>
>
>> I'm trying to be helpful here and maybe help nudge things into a more
>> active
>> position. (I wouldn't be making these
>> emails if I wasn't interested in putting some work into the project)
>>
>> What deficiencies in the product caused you to become interested in
> helping with the development? If your complaint is not about the memory
> management, it might be easily fixable. In fact, judging from my
> experience, if you put a few hours into trying to correct the problem,
> Alexei will commit a fix for the problem before you finish yours. This has
> happened for me about four times.
>
> What host operating system are you using, by the way?
>
>
>>  -- Alex
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> basilisk-devel mailing list
>> bas...@li...
>> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>
>