You can virtualize Mac OS X but it is not permitted by Apple. The same applies for installing Mac OS X on hardware other then the official one.
Von meinem iPhone gesendet > Am 10.03.2014 um 07:48 schrieb Ben Cooksley <bcooks...@kde.org>: > >> On Mon, Mar 10, 2014 at 7:06 PM, Ian Wadham <iandw...@gmail.com> wrote: >> >>> On 09/03/2014, at 8:23 PM, Kevin Krammer wrote: >>> >>> Hi Ian, >>> >>>> On Sunday, 2014-03-09, 17:33:12, Ian Wadham wrote: >>>> Hi Kevin and Frank, >>>> >>>>> On 08/03/2014, at 11:02 PM, Kevin Krammer wrote: >>>>>> On Saturday, 2014-03-08, 21:47:07, Ian Wadham wrote: >>>>>>> On 08/03/2014, at 6:43 PM, Frank Reininghaus wrote: >>>>>>> 2014-03-08 4:38 GMT+01:00 Ian Wadham: >>>>>>>> While we are on the topic of testing, how much testing is done of >>>>>>>> KDE's cross-platform and cross-desktop implementations? >>>>>>> >>>>>>> Unless the people who prepare the Mac packages test them, the only >>>>>>> testing is done by you and by other users, >>>>>> >>>>>> So what I am hearing, in answer to my question, is "No testing by the KDE >>>>>> development team". >>>>> >>>>> I think this would only be the case if the two groups of people, KDE >>>>> Developers and KDE-on-Mac packagers/users, were non-overlapping sets. >>>> >>>> I think they probably are non-overlapping sets. There *is* a KDE Mac >>>> mailing list, but I receive only a few posts per year from it, as compared >>>> with several a day from Macports. >>> >>> Ah, interesting. >>> This makes it very different from all other platforms (various Linux >>> distributions, BSD, Windows, mobile platforms), where some of the packagers >>> are also KDE developers. >> >> Macports grew out of something Apple did in the early days, mainly directed >> at getting any kind of free open-source software onto Apple Mac. There are >> also Fink and Homebrew doing similar jobs. >> >> A lot of the emphasis is on GNU utilities and languages such as Perl, TCL >> and Python, plus some Science packages and Fortran, used by real scientists, >> free database packages (mysql, mariadb, sqlite, etc.). >> >> The Macports have fantastic Unix/BSD and sysadmin skills, but not much >> knowledge of KDE. The KDE porting team does a good job and are currently >> at KDE 4.12.2, but they make not much attempt to adapt or convert KDE to run >> smoothly in the Apple OS X environment. One guy goes a bit deeper, with >> KMyMoney4, and is in touch with the developers, I think. I help him too, >> when I can. Both of us rely on KMM4 to run our finances ... ;-) >> >>>>> That might of course be true, but also a bit uncommon. Packaging efforts >>>>> for all other platforms is at least to some extend handled by people who >>>>> are either users of the packaged software or KDE developers using the >>>>> respective platform. >>>> >>>> Part of the problem may be that, until recently, it has been difficult for >>>> a KDE developer to just buy a MacBook Pro and set up a dual-boot or >>>> virtualised Linux system on it. But now it is quite easy ... :-) I aim to >>>> have a go, once I have Palapeli for KDE 4.13 put to bed. >>> >>> The main part of the problem, i.e. Apple at least officially requring >>> special >>> hardware, still remains. >>> I am not sure it is feasible to assume anyone would buy a second computer >>> just >>> to satisfy some hardware vendor's lock-in phantasies. >> >> I think your prejudices are showing, Kevin ... :-) Actually Apple Mac >> hardware is bog-standard Intel underneath and OS X is BSD UNIX >> underneath. When I am doing KDE development, I might as well be >> sitting using a Konsole or XTerm window. The problem up till now >> has been EFI booting, but there is now a package called "rEFIt" that >> can set up partitions and the boot area to boot whatever you like. > > Whilst there is nothing particularly special about Mac hardware now, > one is only allowed by the Mac OS X licensing to run it on Apple > hardware. > > It is therefore impossible for KDE to provide Continuous Integration > support without Apple hardware. > For the same reasons, it isn't possible for individual KDE developers > to test their work. > > As far as I know, one cannot virtualise Mac OS X, or if one can, it > must still be done on Apple hardware. > >> >> I am old enough to remember why Apple went the way it did in 1982 >> with the Lisa and Mac. It was to keep control over configuration and >> minimise support problems. IBM with their PC, by contrast, let the >> genie out of the jar and look where Microsoft and even Linux users >> are today ... >> >> At an educational group I belong to there is a monthly PC Users Group, >> all these people my age struggling with MS Windows, security, viruses, >> malware, how to set up a network, etc. There is no real need for an >> Apple Users Group ... >> >>> However, those who own Apple hardware seem to either not use OSX or not use >>> KDE applications on OSX, otherwise there would be an overlap in the >>> users/developers group. >> >> Users yes ... developers no. I think I am the only KDE developer on Apple >> and that is only for applications --- and games at that. I am not a "core" >> developer. I might be able to do that stuff. I used to before I retired >> from >> the workforce, but now I just like to program for fun ... :-) >> >>> Do you know if the Mac packaging group is just building the software or if >>> they also run the automated tests? >> >> I don't know for sure, but I think they just build, sometimes patching to >> overcome incompatibility problems and build failures. >> >>> My assumption until this thread was that OSX as a target platform was >>> handled >>> similar to how all other were handled, i.e. a group of people with deeper >>> understanding of the platform's peculiarities would build the software, fix >>> eventual problems and upstream those fixes. Doing the latter through persons >>> within the group who are KDE developers. >>> >>> My updated understanding is that the group packaging KDE software for OSX >>> does >>> not have any members who are KDE developers, >> >> I am not certain of that, but it is probably so. >> >>> so either fixes are not developed >>> at all or are lost between KDE releases. >> >> Well, they propagate fixes for build, compilation and dependency problems >> and have a rather sophisticated system for doing so, but that is local to >> Apple >> OS X and is not finding and fixing any bugs in KDE or Qt AFAIK. >> >> Of course, as a KDE developer working on an Apple MacBook Pro, I am >> connected to KDE mailing lists, bugzilla and the git repositories, so if >> I find and fix a bug, the fixes propagate just as if I were working on Linux. >> >>>> Another source of problems is the excessive list of dependencies >>>> in KDE (see attached). >>> >>> A lot of that seems to be purely build dependencies, not something an end >>> user >>> would be affected by. >> >> Well I am. You'd better believe how long it takes to go through all >> that Nepomuk stuff on a limited bandwidth broadband connection, >> let alone compile it, if any of it has to be compiled from source. And >> those dependencies have caused lots of problems in Macports in the >> past and they used to cause me endless problems when I worked >> on a Linux system. >> >>> And some of the dependencies look "wrong", e.g. the X11 ones. >> >> They might be, but Apple is rather ambivalent about X11. It's an >> ongoing issue. Some packages require X11 on Apple, such as >> Gimp and Inkscape. It looks as though libsdl does in this case: >> and strigi depends on ffmpeg which depends on libsdl. >> >> But my point is why the hell does KGoldrunner, an arcade game >> of which I am the author, depend on Nepomuk and Strigi? I never >> use them and I never will ... Denny Crane ... :-) >> >> That is what is "wrong" IMHO ... :-) As the Americans said at the >> start of the War of Independence, "No taxation without representation". >> I see those dependencies as a "hidden tax" on every KDE developer >> and user ... :-) >> >>> Based on my previous understanding of the OSX packaging efforts I would have >>> assumed that at least the latter would be taken care of during packaging, >>> but >>> according to the new information it seems that the group's assumption is >>> that >>> upstream will improve the situtation at some point anyway. >>> >>> Since that doesn't sound very reasonable I am sure that I am still missing >>> important pieces of information in there somewhere :) >> >> Yes, probably we do have some missing pieces. I do not have the whole >> picture. >> >>> In the long run it might not be viable to target a platform with a community >>> that is either incapable or unwilling to engage through contributions. >> >> Well, I hope you will consult the Apple FOSS providers (Macports, Fink and >> Homebrew) before you pull the plug ... They are decent, hardworking people >> like you and me ... :-) ... and they are dedicated to keeping FOSS alive in >> the Apple OS X world --- all FOSS, not just KDE. >> >> Cheers, Ian W. >> >> P.S. I see from your signature you are a developer mentor, Kevin. >> >> Would you be able to mentor me while I try to get a handle on some of the >> problems with running KDE apps in an Apple environment? Like my first problem >> will be why plugins sometimes work and sometimes not, in KDE on Apple OS X. >> >> >> >>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe >>>> << > > Thanks, > Ben > >>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe << >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
