Realplayer Windows Xp
Nancie Fazzari
I hope this question isn't too subjective, but why is Windows considered an unsuitable operating system for real time systems and high performance servers? Are there any technical papers or studies that gauge it's performance compared to *nix alternatives?
I've never actually heard any explanation of why developers are against using Windows for these types of systems, aside from the extremely common 'Windows is not a real time operating system' statement, as if it's some kind of well known fact that doesn't need to be justified.
A real-time OS needs a certain amount of deterministic behavior. You want to be able to set up specific task priorities that are always honored and have interrupts that have a specific priority. You can't have an OS that might decide to give priority to a daemon or task that is outside your application. Depending on your system microseconds might matter, an OS that goes off for 50 usecs to handle a daemon outside your application might be deadly.
Now, with that said it doesn't mean you can't use Windows for a real time application. In fact I've done it several times, it's just the real-time aspects were handled by hardware cards and buffering built into the system. If the OS was hundreds of milliseconds late it just meant the display might have a perceptible hiccup in the data. No data was ever lost or not collected. We were also able to avoid problems by customizing what other tasks were running (pretty much the same thing hard core gamers do).
Alternately, I had a recent request to do a real-time system where the real-time hardware would issue a callback that the windows code would see and then send out a USB message. The message had to be sent within microseconds and whatever the delay was it HAD to be deterministic so that the system receiving the USB message could compensate for the delay. This struck me as something that Windows is not suited for and the design was reworked.
Windows has a long-standing reputation about that, based primarily upon isolated bad experiences (everyone has a few, don't they?) which persists through major revisions that obsolete old reasons. Unfortunately, the vast majority of system administrators have never seen any of the performance tuning documents freely available from Microsoft, and even fewer have bothered to tune their systems appropriately.
Real-time critical systems can work on Windows. Look at call center solutions, for example - this is one of my areas of expertise, and I oversee several dozen servers doing exactly this. These machines can have hundreds of lines simultaneously processing voice recognition and speech synthesis at the same time, communicating with databases and programmable call routing systems. Delays in responding to the telephone company's equipment can cause some or all of those calls to be dropped or call quality to degrade severely. We still have to implement antivirus and other security measures, and these systems run.
The most important things you need to do are:* Eliminate periodic automated jobs and processes, like checking for and applying updates, disk maintenance (such as defrag operations and cleanup) and full scans, and move them to regularly scheduled downtime for maintenance.* Have enough memory so the system doesn't get bogged down with swapping* Put your swap on its own partition so fragmentation doesn't interfere with the swapfile (some of my systems don't have this and still work)* Work with the antivirus vendor to fine-tune their product such that it interferes with your server(s) as little as possible while still providing adequate protection - most antivirus software is meant for desktop use, not server use, and will require tuning* Tune your group / local security policies
In the end, UN*X systems can have the same problems if you don't administer them properly: Scheduled jobs, inadequate swap configuration, and intrusive 3rd party security software. They also get overlooked when it comes to security so often that it's no more surprising when they are compromised than when a Windows server is compromised.
You've got to have balance. Both platforms can be equally mismanaged, and both platforms can be well-tuned. If you're talking primarily to UN*X platform people, well, they have reasons they like their platform and have a lot of bias against Windows and you'll get answers that reflect that. If you're talking to Microsoft people, you'll get the same from their angle.
The most important thing when you're choosing the platform should be vendor support for the APPLICATION you're running - which one are they more invested in, and which one have they favored in their development? What has been proven to work the best, and what will continue to be available in the future?
If you want an answer, you should give us some facts to work with. Who says Windows isn't suitable for high performance servers? We have no clue, but you apparently do. So you're better qualified to answer it than we are, aren't you?
As for realtime systems? It's true. Windows isn't suitable because it's not a realtime OS. The same is true for Linux and OSX, btw. Realtime systems need some pretty specialized OS'es. And mainstream OS'es aimed at performance, throughput and responsiveness aren't going to do the trick, whether they're written by Microsoft or anyone else.
The answers you received were correct: Windows simply isn't a RTOS. To be one, it would have to be able to make specific guarantees regarding scheduling. The behavior needed to do that is not particularly compatible with what's appropriate for a regular server or workstation.
Questions seeking product, service, or learning material recommendations are off-topic because they tend to become obsolete quickly. Instead, describe your situation and the specific problem you're trying to solve.
I use Notepad++ as my default text editor on all my systems, and it has the nice bonus of having this built-in - just go Plugins -> Document Monitor -> Start to monitor. You can also use File -> Reload from disk to manually reload it.
I have had good luck with the windows program mtail. It does a very nice job of monitoring an active log. You can configure quite a few options but in general I have found the defaults work very well.
I love the Kiwi Log Viewer. They were just bought out by Solarwinds -- I assume the product is still for sale (or maybe they're giving it away for free now? They're giving away a few other Kiwi products).
I typically do this with TextPad. It has the option to monitor that a file has been modified. It is an option to either automatically update the window or to prompt you whether or not you want to reload the file.
The idea of wake windows also feeds into our unmet desire for control. It is extremely hard to face the fact that your baby is just random in their behavior. Whether through data collection or not, for many of us the first months of parenting are a blur of attempting to make sense of some relationship between inputs and outputs. How many minutes, precisely, did the baby nurse before that one magical night they slept through? If we kept them up for exactly 45 minutes, does that translate to a longer nap?
Moreover, based on what we know about sleep, there is no reason to think that these wake windows would be the same for all babies. Even if there were good information on some average length, it would not be directly applicable to everyone.
The combination of the difficulty defining the outcome, the probable difficulty of getting parents to adhere to the treatment, and the challenge of even defining what, precisely, the treatment is makes this study seem very unlikely.
Where does this leave us? Does it mean the wake window approach makes no sense? No. Where it leaves us is in the same place that we often are with early parenting: there are many good choices, and you have to do what works for you.
The most important thing I learned when I had my babies was that you need to prep them for naps before they show signs of tiredness. If you wait until they are obviously fatigued, they may be overtired and harder to put down.
Hi, Anyone please help me some guidance to run my script from windows pc to iOS real device.
I have no MAC os system, hSo I need in helping setting up appium for iOS real device and windows 10.
Is it possible to run my script from on real iOS device with windows 10 using appium robot framework script.