From: Diskutant <dis...@go...> - 2012-06-15 16:13:33
|
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. 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 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. 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 |