Hi Otavio, All of this being said, I actually do care about fixing serial, parallel and smartcard. I'm quite happy to see Thinstuff's been putting some resources on smartcard and serial recently, and that Nik who responded earlier in this thread is now on IRC, ready to help. I think the most problematic would remain parallel. The printer I bought which I thought had a parallel port was in fact a serial port requiring a db25 to db9 adapter, so not very helpful. I'm still looking for a good test device that actually uses a true parallel port in 2013 that I can get for testing purposes. Any recommendations? I don't feel like buying another random printer without knowing for sure it's going to be useful. As for smartcard, I would really use some instructions on how to configure smartcard authentication in a terminal server environment. Hopefully we can finally get all of these fixed within the current year. Just writing test procedures for features which are very obscure to many developers would greatly enhance our capabilities of frequently testing and improving them.
What do you think? Best regards, - Marc-Andre On Tue, Oct 22, 2013 at 1:29 PM, Marc-André Moreau < marcandre.mor...@gmail.com> wrote: > Hi Otavio, > > You may not realize it, but the vast majority of the work I'm doing for > customers is upstream from the start, and this include bug fixes, > performance improvements, architectural fixes. The problem I think you have > is the features you care mostly about (serial, parallel, smartcard) are > those I have never got a request for by my customers. I'm not saying they > aren't important, because they are, but none of my customers had those > features on their priority list. I even bought a smartcard reader in hope > of taking the time to fix smartcard redirection, but never got the time to > really go in depth into it. I asked for help on how to simply configure a > terminal server environment with smartcard auth a long time ago, and I > still don't know how to do it. As for serial and parallel, I even bought > old crappy printers on eBay to do some bug fixing. I did a few fixes but > not enough, it's not fully working. Just figuring out how to test these > features is a major blocker for a lot of developers who just aren't > familiar with them. Combine that with being swamped with work from actual > paying clients and it goes down the list of priorities. I'm sorry most of > the customers come to me to improve and fix features which aren't on your > priority list. > > As for justifying myself, well, you're talking like all of this is easy > and the only reason why it's not better is because we're not listening to > your words of wisdom. I actually agree these are all very important points, > but you don't seem to get the part where making it happen requires > resources which we don't have, and the resources we do have are allocated > are mostly put on what people pay me to work on. If people want better > audio that doesn't skip, or better multimedia redirection, or crazy awesome > fast RemoteFX, or RDP8 multitouch, or TS Gateway, or NLA, and these aren't > part of the "serial, parallel, smartcard" list, then what should I do? Tell > them to keep their money, find a day job which doesn't involve FreeRDP, and > spend even less time contributing to this project? It's a general > understanding that when you want something in an open source project that > nobody else is already working on free, you can't expect someone to just > take care of your specific problems in the same way one would get paid > support but without paying for it. Free software doesn't imply free > support. Most of the time free community support is really helpful but it > depends on people's generosity and free time. You cannot *require* that > they support you for free, that's the difference, even if a lot of the > times they will. > > I hope I'm not being misunderstood here: we're happy to help to the best > of our abilities, but it still doesn't mean we're free unpaid employees who > have nothing to do but offer free support 24/7. > > Best regards, > - Marc-Andre > > > On Tue, Oct 22, 2013 at 12:58 PM, Otavio Salvador <ota...@ossystems.com.br > > wrote: > >> On Tue, Oct 22, 2013 at 2:34 PM, Marc-André Moreau >> <marcandre.mor...@gmail.com> wrote: >> > I understand that this is constructive criticism, the issue is mostly >> with >> > the fact that one cannot realistically do what you suggest. Freezing >> master >> > is not an option, which is why we've made a stabilization branch: the >> code >> > there is simply stabilized over time with no breaking changes, while >> master >> > can remain what it's always been. As for listening to my customers, it's >> > pretty much what I've been doing for the last 5 years: people pay for >> > features and nobody wants to pay for tests, bug fixes which aren't >> blockers >> > to them, and general work which helps others but not them. In the end >> of the >> > day, what most people truly want is code that works for them and will >> remain >> > stable over time, they don't have the time to work in areas which >> doesn't >> > directly benefit to them unless they are highly passionate about it and >> can >> > spend some of their free time doing extra work for fun. Let's just say I >> > have done a VERY large amount of unpaid work on this project over the >> years >> > and cannot afford to do as much as I used to be. It's funny how certain >> > features simply don't fix or complete themselves when I'm not working on >> > them. Wishful thinking consistently fails me for some reason. >> >> Well this is how most Free Software projects work. In this case you >> might start pushing your customers to pay for your time to stabilize >> the new code for merging, as part of the project. >> >> > However, what you are getting is mostly an emotional reaction: if we >> *had* >> > the time to do more things right, then of course we would have frequent >> > stable releases, more documentation, more API stability, more support, >> more >> > whatever you want. The problem is that there is only 24 hours in a day >> and >> > all that would be required in unpaid work is enough for a couple full >> time >> > employees. You can definitely ask that we do all of this and then say >> later >> > you've warned us we should have done it, it doesn't change the fact >> that we >> > simply don't have enough resources to do it and still have features to >> > implement because our customers and community members need them for >> their >> > specific projects. We've resisted most of RDP8 doing a lot of >> stabilization >> > work and optimization, and now we've got some catching up to do. With >> the >> > new Microsoft RDP clients released, we have no choice but to move on to >> at >> > least starting portions of RDP8 and even RDP8.1 in master. This is >> pretty >> > much why we could never freeze master, because there are too many >> people who >> > actually need to be working on the bleeding edge of FreeRDP. It's not a >> > matter of choice, it's a matter of keeping up with the competition. If >> they >> > have it, then we've got to have it as well, and do it even better. >> >> We're not keeping up with competition. In competition SmartCard >> redirection work; Serial work, Parallel Work. >> >> > Getting people to understand that open source doesn't mean there's a >> whole >> > team of unpaid employees at your disposal takes time, but as silly as it >> > sounds, it's still true. As an example, a lot of the complaints you're >> > having now, I've had them from developers at HP. Getting the stable-1.1 >> > branch in place worked very well and they're using it and often >> contributing >> > bug fixes. I can say I am quite satisfied now how we operate with them. >> > Maybe you should follow their example and start using the stable-1.1 >> branch >> > as well. If there are specific blocking issues that prevent you from >> > upgrading and nobody is working on fixing them, then please allocate >> some >> > resources on them. At least you have the assurance that the stable-1.1 >> is >> > not a moving target, it's a stabilizing target. >> >> No; I am getting out of RDP business. >> >> I allocated a lot of resources for FreeRDP in past and this didn't pay >> itself so it is a no-go for now at this moment. >> >> > So, to summarize: the stable-1.1 is what you're looking for. For >> blocking >> > issues you might have that nobody is working on, we're not free >> employees, >> > which means you can either wait forever until somebody takes the time >> to fix >> > it for free or you can allocate resources to fix it. We will gladly >> merge >> > your bug fixes, but we just don't have time to do free support 24/7 (and >> > even if we had, there are too many issues to cover). The master branch >> is >> > often used by people who need the bleeding edge of FreeRDP and can >> afford >> > some occasional instability that is often fixed within a few days. I >> guess >> > you could compare master to debian sid and the stable branch to the >> current >> > debian stable release. You need debian stable, a lot of people need >> debian >> > sid, and you can't tell people who need debian sid that they need debian >> > stable just like they can't tell you you need debian sid. >> >> Marc-Andre, seriously ... stop to justify things and claim there're no >> way of doing it better. It always have better ways of doing things, it >> is just a matter of finding it. >> >> I started this discussion to find better ways, not excuses. >> >> -- >> Otavio Salvador O.S. Systems >> http://www.ossystems.com.br http://code.ossystems.com.br >> Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750 >> > > ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk _______________________________________________ Freerdp-devel mailing list Freerdp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freerdp-devel
