Yes that is true. My aim is usually to make it so simple that the manual isn't needed at all but in some cases this simply isn't possible. The state of our manual unfortunatly isn't in the best shape and we are always looking for people that might help us change that. Obviously the less time the developers have to spend with the manual the more time they have to fix bugs or develop new innovative features. I'm happy to help anyone with getting started on working on the manual.
Turbo 2011/11/22 Michael Brandon <mikezulubr...@gmail.com>: > Hi Turbo, > > If it's made a configurable setting, people can take their choice and > everyone's happy 8-) > > The tricky bit is explaining what it all means in the manual... > > Mind you, XCSoar is (I think inevitably) a complex piece of software, and if > you haven't read the manual from cover to cover at least a couple of times, > you're probably not using it properly. > > Cheerio, Michael > On 22 November 2011 22:36, Tobias Bieniek <tobias.bien...@gmx.de> wrote: >> >> Hi Michael, >> >> I do understand your points, and I agree to some extent. However my >> personal use of the application is a little different and I would >> prefer the "Arrival Altitude" over the "Required Altitude". Since this >> is simply a matter of personal perference I would vote for making it >> configurable somehow. I can't confirm this right now, but I think we >> already offer different infoboxes for these two values, but reading >> the posts here I'm having the feeling that maybe those values aren't >> named and described properly. We don't offer the possibility to >> configure the labels on the map and the final glide bar yet, but there >> is a feature request on this and once we have finished all the other >> work we should have a look at this. >> >> Since we all have real jobs too there is only so much time we can >> spend on improving XCSoar. My personal priority right now it getting >> my two loggers (Flarm and DX50) working with XCSoar, so that I can >> fully transition to Android/Dell Streak next season. >> >> Turbo >> >> >> 2011/11/22 Michael Brandon <mikezulubr...@gmail.com>: >> > Hi Turbo, >> > >> > Both your points are valid. >> > >> > 1) As I pointed out, when the conditions are tough, I'm not looking at >> > my >> > PDA (which incidentally is why I've not found the thermal radar very >> > helpful), I'm working hard at climbing. Yes, if I kept looking at the >> > PDA I >> > would know when I hit what XCSoar estimates is final glide, but why >> > can't >> > XCSoar give me a realistic estimate in the first place? Remember, I'm a >> > simple chap - if I'm at 4,0000 ft and XCSoar says I need to climb 3,000 >> > ft, >> > I'm going to make 7,000 ft my mental target and - assuming the thermal >> > doesn't weaken - see what XCSoar says when I get there, or at least, >> > close >> > to there. >> > >> > 2) Again a fair comment. But what's better - me make an estimate of 1 >> > knot >> > by way of the MacCready setting, actually achieve 2 knots, and have >> > XCSoar make a somewhat inaccurate estimate of my actual height below >> > final >> > glide, or have XCSoar assume an *infinite* climb rate and thus give me a >> > quite inaccurate estimate? >> > >> > If XCSoar takes drift into account, the accuracy of its above/below >> > final >> > glide calculations are governed by how accurately the MacCready setting >> > matches the actual climb rate achieved (and by the accuracy of the wind >> > estimates), but to my mind the real issue is not whether to use the >> > MacCready setting in above/below final glide calculations, but how >> > accurately you (or XCSoar) set the MacCready setting in the first place. >> > >> > Cheerio, Michael >> > On 22 November 2011 21:56, Tobias Bieniek <tobias.bien...@gmx.de> wrote: >> >> >> >> Hi Michael, >> >> >> >> these scenarios seem reasonable, but they have at least two flaws. >> >> >> >> 1) While circling you should monitor the final glide value. In your >> >> scenarios it seems like you take the value before circling, then >> >> circle and after circling for the amount of altitude that XCSoar told >> >> you before starting to circle you will stop. This is obviously not >> >> perfect and leads to the second more important problem. >> >> >> >> 2) Your scenarios only work if you would hit a thermal with the exact >> >> lift value that you had set as the MC value. If the MC value isn't >> >> fitting the additional amount of altitude that XCSoar predicted due to >> >> the wind drift is also wrong since the time you need to spend in the >> >> themal won't fit. >> >> >> >> Turbo >> >> >> >> >> >> 2011/11/22 Michael Brandon <mikezulubr...@gmail.com>: >> >> > Hi folks, >> >> > >> >> > Could I present a few scenarios and see where they take us? Bear with >> >> > me... >> >> > >> >> > Scenario 1: >> >> > - I'm at 4,000 ft >> >> > - the day has died and there is no lift >> >> > - the MacCready is set to zero >> >> > - XCSoar reports that I'm 3,000 ft below final glide >> >> > >> >> > It's clear that I'm not going to make it home, so all I can do is see >> >> > what >> >> > landing places XCSoar says are within glide range and head for the >> >> > most >> >> > promising option. If there are none, I'll be looking at my outlanding >> >> > options. >> >> > >> >> > Scenario 2: >> >> > - I'm at 4,000 ft >> >> > - there is still lift about >> >> > - the MacCready is set to a non-zero value >> >> > - XCSoar reports that I'm 3,000 ft below final glide >> >> > - there is no wind >> >> > >> >> > Being the simple fellow that I am, I think to myself "if I can climb >> >> > 3,000 >> >> > ft I have a chance of getting home". If I hit a thermal straight >> >> > away, >> >> > I think to myself "if I can climb to 7,000 ft I have a chance of >> >> > getting >> >> > home". I ride that thermal to 7,000 ft, and XCSoar tells me I'm on >> >> > final >> >> > glide. I'm a happy chappy. >> >> > >> >> > Scenario 3: >> >> > - I'm at 4,000 ft >> >> > - there is still lift about >> >> > - the MacCready is set to a non-zero value >> >> > - XCSoar reports that I'm 3,000 ft below final glide >> >> > - there is a headwind on the final leg >> >> > - XCSoar ignores drift in its calculations >> >> > >> >> > Being the simple fellow that I am, I think to myself "if I can climb >> >> > 3,000 >> >> > ft I have a chance of getting home". If I hit a thermal straight >> >> > away, >> >> > I think to myself "if I can climb to 7,000 ft I have a chance of >> >> > getting >> >> > home". I ride that thermal to 7,000 ft, but I've drifted away from >> >> > home, >> >> > so >> >> > XCSoar tells me I'm still 1,000 ft below final glide. I climb again, >> >> > this >> >> > time to 8,000 ft, but XCSoar is still telling me I'm below final >> >> > glide. >> >> > I >> >> > think to myself "that damned XCSoar is lying to me". I'm a confused >> >> > and >> >> > less >> >> > than happy chappy. If this keeps happening, I'd probably end >> >> > up dubious >> >> > about XCSoar's judgement on whether I was above or below final >> >> > glide, and >> >> > certainly ignoring it's judgement of by how much. That doesn't help >> >> > me. >> >> > >> >> > Scenario 4: >> >> > - I'm at 4,000 ft >> >> > - there is still weak lift about >> >> > - the MacCready is set to a non-zero value >> >> > - XCSoar reports that I'm 3,000 ft below final glide >> >> > - there is a tailwind on the final leg >> >> > - XCSoar ignores drift in its calculations >> >> > >> >> > Being the simple fellow that I am, I think to myself "if I can climb >> >> > 3,000 >> >> > ft I have a chance of getting home". If I hit a thermal straight >> >> > away, >> >> > I think to myself "if I can climb to 7,000 ft I have a chance of >> >> > getting >> >> > home". I ride that thermal to 7,000 ft, but I've drifted closer to >> >> > home, >> >> > so >> >> > XCSoar tells me I'm now 1,000 ft above final glide. I've wasted time >> >> > and >> >> > effort trying to climb higher than I needed in a weak thermal. I >> >> > think >> >> > to >> >> > myself "why did XCSoar say I needed to climb 3,000 ft, but when I did >> >> > I >> >> > ended up so far above final glide?". Bear in mind that when I'm >> >> > climbing >> >> > in >> >> > less than ideal conditions, I'm not looking at my PDA, I'm looking >> >> > outside >> >> > and focusing on thermalling, so I'll probably miss the point at which >> >> > the >> >> > XCSoar above/below indicator switches from red to green. Again I'm a >> >> > less >> >> > than happy chappy, and again I learn to mistrust XCSoar's >> >> > calculations. >> >> > >> >> > I'd be a much happier chappy, and would place much more faith in what >> >> > XCSoar >> >> > tells me, if it takes drift into account in its calculations of >> >> > above/below >> >> > final glide. I want to know that I really need to climb 4,500 ft if >> >> > there's >> >> > a headwind, or just 2,000 ft if there's a tailwind. Then I'd have a >> >> > realistic idea of how far I needed to climb, and while the achieved >> >> > climb >> >> > rate might differ from the MacCready setting, it's going to be a much >> >> > better >> >> > estimate than ignoring drift based on forecast climb rate. >> >> > >> >> > If the XCSoar developers implemented an option to enable or disable >> >> > this >> >> > behaviour, I know which setting I'd be choosing. >> >> > >> >> > Cheerio, Michael >> >> > >> >> > On 22 November 2011 11:17, Morgan Hall <morh...@gmail.com> wrote: >> >> >> >> >> >> Essentially this is like "Club" Mode to me. I rarely enter a task >> >> >> or >> >> >> even >> >> >> select a destination waypoint since my goal is usually to return >> >> >> home. >> >> >> For >> >> >> outlanding options, I'm taking a quick look at the arrival height on >> >> >> the map >> >> >> display. I just want those numbers to be "final glide" values given >> >> >> the >> >> >> current assumptions the system is working off of. (wind, altitude, >> >> >> MC, >> >> >> safety alt) >> >> >> If I'm beating my way back into a headwind at MC 0 I just want to >> >> >> know >> >> >> if >> >> >> I dead glide it, where will I end up (roughly). If I hit lift and >> >> >> try >> >> >> to >> >> >> climb I'd just like to know if I'm gaining or loosing ground at that >> >> >> moment. >> >> >> I'm admittedly a few revs behind the current, so I think this is the >> >> >> behavior the version I'm running is using at the moment, I'd have >> >> >> been >> >> >> shocked if I set to MC .5 and went from 500 below glide to thousands >> >> >> below >> >> >> glide. I can understand the logic and that for competition you >> >> >> might >> >> >> need >> >> >> that logic in place, but it doesn't align with the way I think or >> >> >> expect the >> >> >> system to behave. >> >> >> I should learn the contest capabilities more, but for myself and the >> >> >> people I've turned on to XCSoar the simple mode I usually recommend >> >> >> is >> >> >> the >> >> >> basic club mode from above. Pretty much set it and don't mess with >> >> >> it. >> >> >> I >> >> >> do fiddle with my L-Nav more. MC value changes for what-if >> >> >> scenarios >> >> >> and >> >> >> waypoint changes for alternates. That's only because it doesn't >> >> >> provide as >> >> >> much "at-a-glance" data as XCS. >> >> >> Great work you guys are doing. >> >> >> Morgan >> >> >> >> >> >> >> >> >> On Mon, Nov 21, 2011 at 3:57 PM, Ramy Yanetz <ryan...@yahoo.com> >> >> >> wrote: >> >> >>> >> >> >>> I also want to thank all developers for the hard work they do. All >> >> >>> I >> >> >>> ask, >> >> >>> is please don't assume that everyone fly the same way you do. I >> >> >>> know >> >> >>> many >> >> >>> very successfully XC pilots who use low MC on final glide and do >> >> >>> not >> >> >>> set >> >> >>> tasks. They are not racing to a goal, they just going on a long >> >> >>> shallow >> >> >>> final glide back home at the end of the day after a long flight. >> >> >>> Arrival >> >> >>> altitude, or altitude difference is crucial for decision making. >> >> >>> Adding more >> >> >>> configuration options is fine, but Please don't change basic >> >> >>> functionalities. >> >> >>> >> >> >>> Thanks >> >> >>> >> >> >>> Ramy >> >> >>> >> >> >>> On Nov 22, 2011, at 1:39 AM, Ramy Yanetz <ryan...@yahoo.com> wrote: >> >> >>> >> >> >>> > Turbo, it is not just the final glide bar. If it was just the bar >> >> >>> > than >> >> >>> > we could just ignore it. But as I said, it is all the arrival >> >> >>> > altitude info >> >> >>> > boxes AND all the waypoint details. I guess the labels as well, >> >> >>> > but >> >> >>> > they >> >> >>> > typically not showing when you below glide so I can't confirm >> >> >>> > this. >> >> >>> > So yes, >> >> >>> > the misleading calculation is everywhere. >> >> >>> > >> >> >>> > Ramy >> >> >>> > >> >> >>> > On Nov 22, 2011, at 12:29 AM, Tobias Bieniek >> >> >>> > <tobias.bien...@gmx.de> >> >> >>> > wrote: >> >> >>> > >> >> >>> >> Too be honest, I've haven't entirely understood yet where the >> >> >>> >> issue >> >> >>> >> is >> >> >>> >> actually happening. Is it just the final glide bar or also the >> >> >>> >> arrival >> >> >>> >> height labels for airports on the map?! I'm hoping to get some >> >> >>> >> more >> >> >>> >> input from the other developers before making any fast >> >> >>> >> decisions. >> >> >>> >> >> >> >>> >> Turbo >> >> >>> >> >> >> >>> >> >> >> >>> >> 2011/11/21 Ramy Yanetz <ryan...@yahoo.com>: >> >> >>> >>> Sounds like most of the repliers prefer the conventional way of >> >> >>> >>> calculating >> >> >>> >>> arrival altitude without assuming that the only lift I will >> >> >>> >>> find >> >> >>> >>> along the >> >> >>> >>> way is 0.5 knot since I am using conservative STF and that I >> >> >>> >>> will >> >> >>> >>> be >> >> >>> >>> silly >> >> >>> >>> enough to circle in it while drifting more than climbing. I >> >> >>> >>> can't >> >> >>> >>> imagine >> >> >>> >>> why someone would prefer it this way but I realize that there >> >> >>> >>> will >> >> >>> >>> always be >> >> >>> >>> opposite opinions. >> >> >>> >>> So the conclusion is to make it configurable. I am concerned >> >> >>> >>> that >> >> >>> >>> such a >> >> >>> >>> critical change was made without making it an option. >> >> >>> >>> I would like to request that any enhancement made going forward >> >> >>> >>> will >> >> >>> >>> be >> >> >>> >>> *always* made configurable if it will change any existing >> >> >>> >>> behavior. >> >> >>> >>> This is >> >> >>> >>> crucial to make XCS safe and reliable. >> >> >>> >>> Turbo, please let me know if I still need to open a ticket. I >> >> >>> >>> think >> >> >>> >>> this >> >> >>> >>> should be fixed ASAP, I personally wouldn't want to fly with it >> >> >>> >>> again >> >> >>> >>> this >> >> >>> >>> way, after almost picking up an alternate landing believing XCS >> >> >>> >>> which >> >> >>> >>> was >> >> >>> >>> telling me there is no way I can make it... I may need to >> >> >>> >>> switch >> >> >>> >>> back >> >> >>> >>> to my >> >> >>> >>> old PDA running WinPilot until this bug is fixed.. >> >> >>> >>> Ramy >> >> >>> >>> >> >> >>> >>> On Nov 21, 2011, at 7:05 PM, Sascha Haffner >> >> >>> >>> <s_haff...@yahoo.com> >> >> >>> >>> wrote: >> >> >>> >>> >> >> >>> >>> Hi, >> >> >>> >>> >> >> >>> >>> regarding speeds to fly - I use my LX5000 for speed to fly >> >> >>> >>> indication >> >> >>> >>> (beep >> >> >>> >>> sounds) and therefore I set my best guess for MC at the LX5000 >> >> >>> >>> (Cambridge >> >> >>> >>> etc). XCS I use with a safety MC value (higher, than the MC in >> >> >>> >>> the >> >> >>> >>> LX) >> >> >>> >>> with Vers. 6.0.10 (old solver) to give me conservative values >> >> >>> >>> of >> >> >>> >>> AltRequired >> >> >>> >>> / Arrival Height. While comparing the arrival heights of the >> >> >>> >>> two >> >> >>> >>> instruments it gives me a nice redundancy (using even two GPS >> >> >>> >>> sources, Flarm >> >> >>> >>> and LX) and ease of mind. >> >> >>> >>> But again, I understand not everyone flies that way or has two >> >> >>> >>> instruments - >> >> >>> >>> therefore please please make the solver use configuable. >> >> >>> >>> >> >> >>> >>> Thank you guys. >> >> >>> >>> >> >> >>> >>> Cheers, >> >> >>> >>> Sascha >> >> >>> >>> Von: Evan Ludeman <tangoei...@gmail.com> >> >> >>> >>> An: xcsoar-user@lists.sourceforge.net >> >> >>> >>> Gesendet: 17:52 Montag, 21.November 2011 >> >> >>> >>> Betreff: Re: [Xcsoar-user] About MC and tasks >> >> >>> >>> >> >> >>> >>> No, you're certainly not alone. I've been trading email with >> >> >>> >>> JW >> >> >>> >>> privately >> >> >>> >>> this morning. >> >> >>> >>> >> >> >>> >>> Ramy, I agree with everything you've said here. I fly the same >> >> >>> >>> way. >> >> >>> >>> >> >> >>> >>> FWIW, I never use a PDA for final glide... there's too darned >> >> >>> >>> many >> >> >>> >>> ways to >> >> >>> >>> get it wrong and XCS seems to be exacerbating the trend here. >> >> >>> >>> I >> >> >>> >>> rag >> >> >>> >>> on >> >> >>> >>> other aspects of the 302/303, but one thing it does pretty well >> >> >>> >>> is >> >> >>> >>> calculate >> >> >>> >>> a glide to a turnpoint. It will also do a final glide with >> >> >>> >>> HW/TW >> >> >>> >>> component >> >> >>> >>> wind which is *really* useful. and yet to be picked up by XCS. >> >> >>> >>> >> >> >>> >>> Another thing I pretty much never do is take speed to fly >> >> >>> >>> information >> >> >>> >>> from >> >> >>> >>> any instrument. You understand why! >> >> >>> >>> >> >> >>> >>> There's a critical need in soaring software to separate speed >> >> >>> >>> to >> >> >>> >>> fly >> >> >>> >>> from >> >> >>> >>> glide calculation that so far hasn't been met by anyone. It is >> >> >>> >>> often >> >> >>> >>> the >> >> >>> >>> case that the fast (and safe) way home is Mc 1 or 2 speed to >> >> >>> >>> fly >> >> >>> >>> and >> >> >>> >>> Mc 3 or >> >> >>> >>> better on final glide. Likewise, speed on task need not be >> >> >>> >>> calculated by >> >> >>> >>> your speed to fly Mc setting. >> >> >>> >>> >> >> >>> >>> -Evan Ludeman / T8 >> >> >>> >>> >> >> >>> >>> >> >> >>> >>> >> >> >>> >>> >> >> >>> >>> On Mon, Nov 21, 2011 at 11:24 AM, Ramy Yanetz >> >> >>> >>> <ryan...@yahoo.com> >> >> >>> >>> wrote: >> >> >>> >>> >> >> >>> >>> After using XCSoar for a while I am very impressed with it but >> >> >>> >>> at >> >> >>> >>> the >> >> >>> >>> same >> >> >>> >>> time surprise that it assumes that everybody fly according to >> >> >>> >>> MC >> >> >>> >>> theroy and >> >> >>> >>> with pre defined tasks. Most pilots I know, which are serious >> >> >>> >>> XC >> >> >>> >>> pilots, do >> >> >>> >>> not set tasks and do not fly according to MC theory, which is >> >> >>> >>> way >> >> >>> >>> overrated. >> >> >>> >>> In most place in western US you will want to fly at low MC to >> >> >>> >>> stay >> >> >>> >>> at >> >> >>> >>> the >> >> >>> >>> sweet spot above the mountains and near the clouds. But it >> >> >>> >>> looks >> >> >>> >>> like >> >> >>> >>> XCSoar >> >> >>> >>> insists that if you don't fly according to MC you can't go >> >> >>> >>> anywhere >> >> >>> >>> since >> >> >>> >>> you can't climb, and that if you fly for OLC than you also have >> >> >>> >>> a >> >> >>> >>> task pre >> >> >>> >>> declared. >> >> >>> >>> Flying strictly according to MC is a guarantee way to land out >> >> >>> >>> often. >> >> >>> >>> An >> >> >>> >>> example from my last flight: release at 1500 feet, made 3 >> >> >>> >>> turns >> >> >>> >>> in 3 >> >> >>> >>> knots >> >> >>> >>> and hit the inversion at 2000 feet, next thing you know XCSoar >> >> >>> >>> tells >> >> >>> >>> you to >> >> >>> >>> dive to the ground at 80+ knots at MC 3. Instead of flying at >> >> >>> >>> best >> >> >>> >>> glide to >> >> >>> >>> stay aloft. And if I change to mc zero it assumed I can not go >> >> >>> >>> anywhere >> >> >>> >>> upwind since I can not climb. If so, how did I manage to fly >> >> >>> >>> 200km >> >> >>> >>> tip >> >> >>> >>> toeing from one thermal to next at MC between zero and 0.5? >> >> >>> >>> I think this is a flaw to assume this. Am I alone thinking >> >> >>> >>> this? >> >> >>> >>> >> >> >>> >>> Ramy >> >> >>> >>> >> >> >>> >>> >> >> >>> >>> >> >> >>> >>> ------------------------------------------------------------------------------ >> >> >>> >>> All the data continuously generated in your IT infrastructure >> >> >>> >>> contains a definitive record of customers, application >> >> >>> >>> performance, >> >> >>> >>> security threats, fraudulent activity, and more. Splunk takes >> >> >>> >>> this >> >> >>> >>> data and makes sense of it. IT sense. And common sense. >> >> >>> >>> http://p.sf.net/sfu/splunk-novd2d >> >> >>> >>> _______________________________________________ >> >> >>> >>> Xcsoar-user mailing list >> >> >>> >>> Xcsoar-user@lists.sourceforge.net >> >> >>> >>> https://lists.sourceforge.net/lists/listinfo/xcsoar-user >> >> >>> >>> >> >> >>> >>> >> >> >>> >>> >> >> >>> >>> >> >> >>> >>> >> >> >>> >>> ------------------------------------------------------------------------------ >> >> >>> >>> All the data continuously generated in your IT infrastructure >> >> >>> >>> contains a definitive record of customers, application >> >> >>> >>> performance, >> >> >>> >>> security threats, fraudulent activity, and more. Splunk takes >> >> >>> >>> this >> >> >>> >>> data and makes sense of it. IT sense. And common sense. >> >> >>> >>> http://p.sf.net/sfu/splunk-novd2d >> >> >>> >>> _______________________________________________ >> >> >>> >>> Xcsoar-user mailing list >> >> >>> >>> Xcsoar-user@lists.sourceforge.net >> >> >>> >>> https://lists.sourceforge.net/lists/listinfo/xcsoar-user >> >> >>> >>> >> >> >>> >>> >> >> >>> >>> >> >> >>> >>> >> >> >>> >>> >> >> >>> >>> ------------------------------------------------------------------------------ >> >> >>> >>> All the data continuously generated in your IT infrastructure >> >> >>> >>> contains a definitive record of customers, application >> >> >>> >>> performance, >> >> >>> >>> security threats, fraudulent activity, and more. Splunk takes >> >> >>> >>> this >> >> >>> >>> data and makes sense of it. IT sense. And common sense. >> >> >>> >>> http://p.sf.net/sfu/splunk-novd2d >> >> >>> >>> >> >> >>> >>> _______________________________________________ >> >> >>> >>> Xcsoar-user mailing list >> >> >>> >>> Xcsoar-user@lists.sourceforge.net >> >> >>> >>> https://lists.sourceforge.net/lists/listinfo/xcsoar-user >> >> >>> >>> >> >> >>> >>> >> >> >>> >>> >> >> >>> >>> >> >> >>> >>> ------------------------------------------------------------------------------ >> >> >>> >>> All the data continuously generated in your IT infrastructure >> >> >>> >>> contains a definitive record of customers, application >> >> >>> >>> performance, >> >> >>> >>> security threats, fraudulent activity, and more. Splunk takes >> >> >>> >>> this >> >> >>> >>> data and makes sense of it. IT sense. And common sense. >> >> >>> >>> http://p.sf.net/sfu/splunk-novd2d >> >> >>> >>> _______________________________________________ >> >> >>> >>> Xcsoar-user mailing list >> >> >>> >>> Xcsoar-user@lists.sourceforge.net >> >> >>> >>> https://lists.sourceforge.net/lists/listinfo/xcsoar-user >> >> >>> >>> >> >> >>> >>> >> >> >>> > >> >> >>> > >> >> >>> > >> >> >>> > >> >> >>> > ------------------------------------------------------------------------------ >> >> >>> > All the data continuously generated in your IT infrastructure >> >> >>> > contains a definitive record of customers, application >> >> >>> > performance, >> >> >>> > security threats, fraudulent activity, and more. Splunk takes >> >> >>> > this >> >> >>> > data and makes sense of it. IT sense. And common sense. >> >> >>> > http://p.sf.net/sfu/splunk-novd2d >> >> >>> > _______________________________________________ >> >> >>> > Xcsoar-user mailing list >> >> >>> > Xcsoar-user@lists.sourceforge.net >> >> >>> > https://lists.sourceforge.net/lists/listinfo/xcsoar-user >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> ------------------------------------------------------------------------------ >> >> >>> All the data continuously generated in your IT infrastructure >> >> >>> contains a definitive record of customers, application performance, >> >> >>> security threats, fraudulent activity, and more. Splunk takes this >> >> >>> data and makes sense of it. IT sense. And common sense. >> >> >>> http://p.sf.net/sfu/splunk-novd2d >> >> >>> _______________________________________________ >> >> >>> Xcsoar-user mailing list >> >> >>> Xcsoar-user@lists.sourceforge.net >> >> >>> https://lists.sourceforge.net/lists/listinfo/xcsoar-user >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> >> All the data continuously generated in your IT infrastructure >> >> >> contains a definitive record of customers, application performance, >> >> >> security threats, fraudulent activity, and more. Splunk takes this >> >> >> data and makes sense of it. IT sense. And common sense. >> >> >> http://p.sf.net/sfu/splunk-novd2d >> >> >> _______________________________________________ >> >> >> Xcsoar-user mailing list >> >> >> Xcsoar-user@lists.sourceforge.net >> >> >> https://lists.sourceforge.net/lists/listinfo/xcsoar-user >> >> >> >> >> > >> >> > >> >> > >> >> > >> >> > ------------------------------------------------------------------------------ >> >> > All the data continuously generated in your IT infrastructure >> >> > contains a definitive record of customers, application performance, >> >> > security threats, fraudulent activity, and more. Splunk takes this >> >> > data and makes sense of it. IT sense. And common sense. >> >> > http://p.sf.net/sfu/splunk-novd2d >> >> > _______________________________________________ >> >> > Xcsoar-user mailing list >> >> > Xcsoar-user@lists.sourceforge.net >> >> > https://lists.sourceforge.net/lists/listinfo/xcsoar-user >> >> > >> >> > >> > >> > > > ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ Xcsoar-user mailing list Xcsoar-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcsoar-user
