Glitch-free iTunes?
Hi; Here is a rant about iTunes: http://www.pcworld.com/businesscenter/article/229398-2/day_3_dude_wheres_my_... You guys are doing great, but I think it would be better if you were to work more in priority order. There are 200M devices, last I checked. I don't think iTunes has ever properly worked in WINE. It seems like Apple keep revising it and so the current WINE never works with the current iTunes. Can you make a goal of supporting iTunes with no glitches? I know many of you are volunteers, but it is globally efficient if the installation number plays into the priority of the bugs. Just this one app could be huge for Linux on the desktop. Warm regards, -Keith
On 07/02/2011 03:46 PM, Keith Curtis wrote:
Hi;
Here is a rant about iTunes: http://www.pcworld.com/businesscenter/article/229398-2/day_3_dude_wheres_my_...
You guys are doing great, but I think it would be better if you were to work more in priority order. There are 200M devices, last I checked. I don't think iTunes has ever properly worked in WINE. It seems like Apple keep revising it and so the current WINE never works with the current iTunes.
Can you make a goal of supporting iTunes with no glitches? I know many of you are volunteers, but it is globally efficient if the installation number plays into the priority of the bugs. Just this one app could be huge for Linux on the desktop.
Warm regards,
-Keith Everyone (with very few if any exceptions) who works on Wine does so because they want to. Priorities are set by each person for themselves. That is simply a fact of life when it comes to community developed software. You are, of course, entitled to your opinion of what is important but you need to persuade rather than trying to command compliance with your wishes.
One of the most effective ways to assure progress on a particular piece of Wine is to put your own effort into improving that particular piece. In the case of iTunes, one of the early steps would be to examine the log Wine produces when you try to install it or run it. This is likely to show that some particular function is not implemented or is not implemented properly. Next, write a test that demonstrates what should happen. Make sure it works on recent native Windows versions. Submit the new test as a patch. Then fix Wine so that it passes that test and does not fail any existing tests due to your changes. Once the test patch has been accepted, check that you changes to Wine pass the new test. Finally, submit your change to Wine. At that point there will be one less thing that keeps iTunes from running on Wine. Other things you need to keep in mind: 1. Does it run on Windows? iTunes is an Apple product and it could be that it has been intentionally implemented so that it does not run on Microsoft's OS. 2. Are there legal issues that would keep it from being run under Wine? 3. Assure that your code meets the Wine style.
On 07/04/2011 02:15 PM, André Hentschel wrote:
Am 04.07.2011 20:08, schrieb max:
1. Does it run on Windows? iTunes is an Apple product and it could be that it has been intentionally implemented so that it does not run on Microsoft's OS. Why then providing a Windowsversion??? :) So you are saying it runs on MS Windows. That answers the question. Thanks.
None of the Linux kernel developers are paid by Linus nor can be fired by him. Linus never forces people to respond to his mails or to work on anything. What has happened is that the team has realized that having goals and leadership has led to good results, and Linus is a good leader, and so they follow along. If Linus says something needs to be worked on, it happens. The rest of the people keep doing their own work. I'm not suggesting to force people to work on iTunes. However, it shouldn't take too much prodding for people to want Linux to work with one of the most important hardware product lines. It is sad that Linux in 2011 cannot run iTunes. This is the fault of WINE and Apple. Maybe the work has been slow. I can't speak to how quickly you are moving, only the results. I have read through your code some years ago. The software that existed was high quality. You keep getting bigger and better. I understand you have a lot of work to do. That is why I suggest priorities or goals. They help manage large workloads. From the outside, you appear to be working on things randomly, and you can do better. Regards, -Keith http://keithcu.com/
On 7/4/11 7:50 PM, Keith Curtis wrote: > None of the Linux kernel developers are paid by Linus nor can be fired > by him. Linus never forces people to respond to his mails or to work > on anything. What has happened is that the team has realized that > having goals and leadership has led to good results, and Linus is a > good leader, and so they follow along. If Linus says something needs > to be worked on, it happens. The rest of the people keep doing their > own work. I think you missed my point. There is a 'leader' for Linux and that person just happens to be Linus. Whether or not he wants that position is pointless. He has it. Linux is and will remain his 'baby'. There is NO such person, that I'm aware of for Wine. Thus if I happen to 'need' to have a few functions in Wine I have two options: 1. File a bug report, categorize it, define it and then hope that someone has the skills and desire to fix the problem I've identified. 2. File a bug report, categorize it, define it and then fix it myself. I have two bug reports that I have worked on and now I'm working on code to bring those functions into Wine, with assistance from other Wine developers to insure that my code is high enough quality and is implemented properly. You have the same options as does everyone else. And yes, if you look through Wine's bugzilla you will see very old bugs (that is why I mentioned the DIB Engine, it is bug 421 and is almost ten years old) to bugs filed yesterday. All need love and attention. Some bug reports were opened only to be closed when this did not happen. Also, remember what is important to you may not be so for the entire project. That is why I'm working on code. Those functions are important to me, but to the overall project no so. There is one other difference between the LKM project and Wine. The Linux Kernel is essential to the functioning of Linux. Wine is only essential to getting well-behaved Windows programs to run on Linux/UNIX. There are some programs that started the project, many years ago, that are no longer available or now have Linux/UNIX equivalents. James
I bring up Linus because he can focus efforts. You don't need Linus. You just need the same result -- focused efforts. There is another name for this concept -- teams. Maybe WINE needs sub-teams? I assure you that the problem isn't for lack of resources. I know you feel busy and perhaps that I'm just wasting your time. However, you have accomplished so much already. Year after year, you accomplish more, and yet you just think that it is hopeless or something. Are you masochists? If you are going to do the work, make goals worthy. And one worthy goal is iTunes runs better than on Windows. If you had that as a goal 5 years ago, you would have succeeded by now. I can think of more goals around Ableton, Office 2010, etc. but for now let's get the hardware working! I understand that WINE has many apps that you want to work. You are doing well. It is just missing some features that are not being caught by your random work. I know you'll get there, in the next 10 years. Perhaps by the time Apple no longer matters you'll have it working. I have my own projects, but I appreciate your interest in my patches. However, I find that my way to contribute is to report social bugs and suggested patches. It can be though about in terms of: planning, priorities, goals, leaders, teams, etc. There are multiple ways to fix this. Regards, -Keith http://keithcu.com/
Perhaps such response is due to my language barrier, but... * On Mon, 4 Jul 2011, Keith Curtis wrote:
I bring up Linus because he can focus efforts. You don't need Linus. You just need the same result -- focused efforts. There is another name for this concept -- teams. Maybe WINE needs sub-teams?
Keith, maybe you should contact Codeweavers to persuade the right persons? :)
However, you have accomplished so much already. Year after year, you accomplish more, and yet you just think that it is hopeless or something.
What makes you say the last part (mentioning hopelessness)?
And one worthy goal is iTunes runs better than on Windows. If you had that as a goal 5 years ago, you would have succeeded by now.
Then 64-bit Wine port, DIB engine/rewrite wouldn't be started; XI2, XRender, Xcursor support, IO completion ports wouldn't have been born; Winsock, OpenGL in child windows, Systray would work in much buggier way; and APC would fail in addition to 16-32 bit thunking issues. I've forgot to mention countless fixes for window handling subsystem (in managend and unmanaged mode), COM mechanisms such as proxy delegations, marshaling, stubless proxies, RPC, Widl, X11 CopyPaste support, Inetcomm, Winhttp, implementations. Plus ton of Unicode fixes. All that would stay broken / unfixed / unimplemented. But iTunes would probably work (in possibly wrongly architectured way). Would such tradeoff be OK for the community? No offense, but I doubt it.
I understand that WINE has many apps that you want to work. You are doing well. It is just missing some features that are not being caught by your random work. I know you'll get there, in the next 10 years. Perhaps by the time Apple no longer matters you'll have it working.
BTW, Keith, could you please estimate how much people / work hrs were used to make XP a final product + produce security fixes? (And that's counting 25 years!) I guess a lot more people / hrs than it is used for Wine. My rough guess is 10 times. In the case of Linux kernel, it is very different game, IMHO. (less restrictions and INSANE compatibility issues:) But you could always contact our "dictator-in-chief" Alexandre to hear the last decision on project managament:) My two cents, S.
On Tue, Jul 5, 2011 at 4:50 AM, Keith Curtis <keithcu(a)gmail.com> wrote:
None of the Linux kernel developers are paid by Linus nor can be fired by him. Linus never forces people to respond to his mails or to work on anything. What has happened is that the team has realized that having goals and leadership has led to good results, and Linus is a good leader, and so they follow along. If Linus says something needs to be worked on, it happens. The rest of the people keep doing their own work.
I'm not suggesting to force people to work on iTunes. However, it shouldn't take too much prodding for people to want Linux to work with one of the most important hardware product lines.
It is sad that Linux in 2011 cannot run iTunes. This is the fault of WINE and Apple. Maybe the work has been slow. I can't speak to how quickly you are moving, only the results. I have read through your code some years ago. The software that existed was high quality. You keep getting bigger and better.
It's easy for Linus to ask people to fix regressions, and they get it done in a few hours, under threat of their patches getting thrown out. Unlike the kernel (and to its detriment), we have regression tests which work even better for that, because they stop bad code from getting committed in the first place, and during a release freeze extra efforts are made to reduce regressions. But adding a new feature is something completely different, because it's not a matter of fixing existing code, but producing new code.
I understand you have a lot of work to do. That is why I suggest priorities or goals. They help manage large workloads. From the outside, you appear to be working on things randomly, and you can do better.
If: I = importance of a bug W = work needed then I/W is the probability the bug gets fixed eg. Wine doesn't compile -> I is huge -> fix is rapid a small typo -> W is tiny -> fix is rapid iTunes has native alternatives, few people have iXxx devices, Apple fans generally use MacOS anyway -> I is small fix requires device drivers, changes to multiple systems, knowledge of Windows and Wine internals -> W is large So the I/W for iTunes is tiny. In fact the only reason it might get fixed by me is because iXxx devices are part of the larger group of USB devices, thus making I larger without increasing W. It's worth noting W is always large for hardware problems. Serial port support in Wine has also dragged on for years, had many bugs and regressions, needed kernel changes for some USB to serial converters, and still doesn't always work because the kernel API is too limited. Relative mouse events needed X changes and have also dragged on. Sound support in Wine has also taken forever. From what I see this isn't unique to Wine, hardware support is the bane of every open source project - even the kernel doesn't always boot. We could really use some kind of public hardware test farm. You're convinced me to prioritize my work on USB support, but it will still be +/- end of 2011, with luck.
Regards,
-Keith http://keithcu.com/
Damjan
On Tuesday 05 July 2011 06:13:32 Damjan Jovanovic wrote:
fix requires device drivers, changes to multiple systems, knowledge of Windows and Wine internals -> W is large Do we need full-fledged support for USB drivers for iTunes? I've been told in the past that all we need to do is properly report the new USB drive to iTunes when an iPod is attached, and can leave the USB mass storage handling to the Linuy OS. Of course "properly reporting" isn't as simple as creating a drive letter and setting its type to USB drive.
I'm sorry to interrupt this nice project management discussion by throwing in a technical question :-)
On Tue, Jul 5, 2011 at 10:13 AM, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote:
On Tuesday 05 July 2011 06:13:32 Damjan Jovanovic wrote:
fix requires device drivers, changes to multiple systems, knowledge of Windows and Wine internals -> W is large Do we need full-fledged support for USB drivers for iTunes? I've been told in the past that all we need to do is properly report the new USB drive to iTunes when an iPod is attached, and can leave the USB mass storage handling to the Linuy OS. Of course "properly reporting" isn't as simple as creating a drive letter and setting its type to USB drive.
I'm sorry to interrupt this nice project management discussion by throwing in a technical question :-)
It used to work that way, but Dan Kegel's analysis of a recent version of iTunes seems to indicate it now pulls in USBD.SYS. Maybe they changed it or maybe they now do direct USB I/O in addition to going through the mass storage interface?
On 7/5/11 2:23 AM, Damjan Jovanovic wrote:
On Tue, Jul 5, 2011 at 10:13 AM, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote:
Do we need full-fledged support for USB drivers for iTunes? I've been told in the past that all we need to do is properly report the new USB drive to iTunes when an iPod is attached, and can leave the USB mass storage handling to the Linuy OS. Of course "properly reporting" isn't as simple as creating a drive letter and setting its type to USB drive.
I'm sorry to interrupt this nice project management discussion by throwing in a technical question :-)
It used to work that way, but Dan Kegel's analysis of a recent version of iTunes seems to indicate it now pulls in USBD.SYS. Maybe they changed it or maybe they now do direct USB I/O in addition to going through the mass storage interface? I have a Mac, and an iPod Touch. When I plug the iPod in, it doesn't show up as an external disk in the Finder. So on Mac, iTunes definitely does direct USB I/O. It's probably safe to assume it does on Windows, too.
Chip
Hey, On 07/05/2011 10:49 AM, Charles Davis wrote:
On 7/5/11 2:23 AM, Damjan Jovanovic wrote:
On Tue, Jul 5, 2011 at 10:13 AM, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote:
Do we need full-fledged support for USB drivers for iTunes? I've been told in the past that all we need to do is properly report the new USB drive to iTunes when an iPod is attached, and can leave the USB mass storage handling to the Linuy OS. Of course "properly reporting" isn't as simple as creating a drive letter and setting its type to USB drive.
I'm sorry to interrupt this nice project management discussion by throwing in a technical question :-)
It used to work that way, but Dan Kegel's analysis of a recent version of iTunes seems to indicate it now pulls in USBD.SYS. Maybe they changed it or maybe they now do direct USB I/O in addition to going through the mass storage interface? I have a Mac, and an iPod Touch. When I plug the iPod in, it doesn't show up as an external disk in the Finder. So on Mac, iTunes definitely does direct USB I/O. It's probably safe to assume it does on Windows, too. There are 2 ways really. Old ipods used usb mass storage which I had working at 1 point, but in a hacky way. ipod touch and iphone need direct usb, which never worked.
~Maarten
participants (9)
-
André Hentschel -
Charles Davis -
Damjan Jovanovic -
James McKenzie -
Keith Curtis -
Maarten Lankhorst -
max -
Saulius Krasuckas -
Stefan Dösinger