The Wine developers recently debated whether to change the licence to LGPL from an X11 style license. They decided against it. One of the original reasons to go with the X11 license is worth keeping in mind: There's already a proprietary implementation of Win32. Microsoft sells it.
The same is true for.NET and Mono. The danger in a company making a proprietary version of Mono is in the proprietary version becoming more popular than the free version, and eventually incompatible with it. If this doesn't happen, users always have the choice between paying for a proprietary product, or getting the open source version. Microsoft's proprietary version of Mono pretty much makes this a non-issue.
I'm not speaking in favor of Windows. I'm just pointing out an instance where a specific Windows application performed better than a specific Linux application.
Also, I don't have to like Windows to point out how ugly a piece of source code is. There's no excuse for writing bad code.
Having said that, Linux would be a pretty bad choice for a home OS at this point, for users who don't want to understand the subtle differences between, say, gcc and syslogd, and still want to use their PC's to send e-mail, write letters, and do video captures. Yep, I threw in video capture because that's something that's genuinly hard to set up under Linux. It's not there yet.
Oh, as for who did the wine stuff? lets say it's not transgaming, you know who;)
Not hard to guess, especially considering that Codeweavers just submitted a huge patch to WineHQ, described as "Patch to improve Microsoft Office 2000 functionality".
Re:I agree with you wholeheartedly
on
Lindows Reviewed
·
· Score: 1
MPlayer may be the fastest MPEG-2 decoder for Linux (at least the fastest I've tried), but the Windows software I got with my DVD drive kicks its butt on the same hardware (a 300MHz Pentium II).MPlayer simply can't play a DVD on that CPU, while PowerDVD doesn't seem to have any problems doing it (other than the decoding artifacts at macroblock boundaries on black screens, that is.)
I got the impression that Mplayer's MPEG-2 codec is rather cache unfriendly. MPlayer is also one of the most impressively unreadable pieces of code I've ever seen, and its design is about as modular as a watermellon.
I seem to remember that you can shut down the originating machine, and the shutdown scripts will force everything that can be migrated (i.e. isn't tied down to the hardware, or (unfortunately) a TCP/IP socket) to go find somewhere else to play.
To solve this guy's problem, he would have had to run Mosix over a VPN with a redundant machine off-site. Not easy to set up or maintain.
The VPN is necessary because Mosix sends internal kernel information over the network.
The point with the telephone is that the wire is actually invisible in each of the photoreceptors.
Not really. That's why I pointed out that photoreceptors don't sample at a single point. Instead, they average a small area, which makes a big difference.
Let's look at some hypothetical telephone wires. Think of a very thin, very distant, and very bright phone wire. Photons emitted by the wire hit your eye, and get focused on your retina. The photons hit a very thin line on your retina - much thinner than a single photoreceptor. The number of photons hitting the photoreceptors will still be large enough to make each one of them fire, making your brain believe that what it's seeing is a telephone wire, as thick as the line of photoreceptors on the retina, projected back through the lens and cornea, all the way back to where the telephone wire really is. You won't know how thin the wire is, but you'll know it's there.
The less extreme case, with an ordinary telephone wire, works just the same, except that the number of photons hitting your retina is much smaller, making them fire less frequently. If lighting conditions are bad enough, you will no longer see the wire, simply because the difference between the firing rate of photoreceptors that have the wire's image on them, and the firing rate of those that don't, is so close that it disappears into the noise.
The exact sequence and timing are affected by inaudible frequency components.
How are the affected? Can you point to a paper discussing this? It sounds interesting.
You can see a telephone line, which is smaller than the eye can resolve. With "perfect reproduction", the telephone line would vanish.
I'm not sure you can draw any conclusions on the auditory system from our vision system.
Besides, the retina doesn't sample at idealized points, since photoreceptors have a surface area. That, and the wiring of phtoreceptors to ganglion cells, are different enough from the assumptions made by the sampling theorem to make me suspicious of attempts to draw conclusions from sampling theory to the vision system.
...which is exactly what I was doing in my previous post, only with the auditory system. Your point is well taken.
What you are describing is windows, not a true RT system.
What I'm describing is based my experience writing some real time applications on QNX, in the last few years. The QNX documentation is available on the web, and the system is free for non commercial use. Download it, compile an application that sets its scheduling algorithm to SCHED_FIFO and its priority to the shell's priority+1,and goes into an infinite loop, run it, and see how responsive the system becomes. You don't have to take my word for it.
The only way out was to set the inner loop to yield to other processes when its calculation was done. This, effectively, amounts to rewriting the kernel low-level scheduler.
Huh? This amounts to not hogging the CPU when you don't have to. This is good practice under any OS, and doesn't even resemble rewriting the scheduler. Not even from a distance, on a dark foggy night.
The problem with "real time" priority under NT is not that bad code will lock up your machine if you tell the OS not to interrupt it. The problem is that the system can't guarantee that a real time task will get the CPU in a bounded time when it needs it (in response to an interrupt, for example). That's the difference between a RTOS and a non real time OS.
In a true real-time system, I would be able to set the mouse and keyboard processes to run at given intervals, while still having my data-handling routine able to digest what came in.
That is simply incorrect. For your keyboard and mouse "processes" (drivers, most likely) to be useful to anybody, the OS has to wake up a user process to handle mouse and keyboard events when they're available. If you tell the OS to give a higher priority to another process, NOTHING is going to interrupt that process until it yields. The assumption is that you know what you're doing, and that you really reallly need the CPU, or bad things will happen (bad, as in people will die, in some cases).You can't afford to have heuristics like "if a process had the CPU for too long in the last second, switch to another task. Let's all be nice and share!".(Actuallly, QNX does have such heuristics, but by running SCHED_FIFO you effectively disable them for the SCHED_FIFO task).
And that's only half of the picture. The other important element of real-time performance is that if your low priority task (your window manager, for example) is busy doing something, like drawing a bitmap on the display, and the system gets an interrupt that's served by a real time task, the OS will immediately switch to the real time task, leaving your pretty picture half drawn for as long as it takes to handle the high priority task. If you get 1000 such interrupts per second, it'll take some time for your window manager to finish drawing that bitmap, and, yes, the system will feel sluggish, but that's by design.
I won't even get into discussing throughput vs. latency issues.
Fortunately, my story has a happy ending I found out that Linux has a good enough scheduler to run my program without data loss, even if it's not a true real-time OS.
Good - I'm happy for you. I bet you can't compile a kernel while your code is running, though - not without causing it to miss deadlines, and not on a stock kernel, in any case. Linux really isn't a RTOS.
An RTOS can't make any design tradeoffs that will make its behavior unpredictable. That rules out swap and memory overcommit right off the bat. How is that good for everyone?
You do realize that if your DVD player is running at a high priority on a RTOS, then nothing is going to get CPU time when it's busy working its IDCT magic. This is a good thing in an embedded system, because people don't like it when their movies pause occasionally because the OS wants to do some housekeeping, sync the disk, update the clock on the front panel...
But what if you're running your DVD player on a 200MHz Pentium? Most likely, you'll freeze your system, because the high priority process won't be able to keep up, and will use 100% of the available CPU time. Embedded systems have a known hardware profile - desktops don't.
If it wasn't in the original signal you sampled, you can't hear it. It's that simple. If your low frequency note was in fact shaped by some ultrasound signals that only your dog can hear, then filtering and sampling just the audible range will give you a perfect reproduction - as good as permitted by your sampling rate and the number of bits you can throw at a sample. Filtering, of course, is necessary to eliminate aliasing of high frequency components into low frequency noise.
This is more obvious if you look at the human ear, and realize that it actually performs a transform to the frequency domain, and doesn't sample the actual wave form.
Now, it seems from your wording that you already know that. I'm just pointing this out to people who might get confused.
I dug up the second story. While the first one appeared to be a submission, the second states that the posting came straight from X-10. I believe that was the last time this was mentioned, though.
...and with X10, no less. There was a "news" story about the X10 $6 firecracker kit a few years ago, that kept getting suspiciously reposted for a few days.
Actually, cable technology is skewed this way. To get high bandwidth, you have to transmit at high enough RF levels to get over the noise (and cable plants are noisy). If your cable modem had enough juice to transmit this loudly, it'd be a toaster.So, upstream has less bandwidth than downstream.
You still fail to point out what you object to in the Quake 2 code you posted. Is it the O(n) time complexity of the search loop? (the same thing can be done in O(1)) It is rather simple, and appears to be optimized for development time, rather than run time. Whether this is a valid tradeoff or not depends on the context.I'll argue that this is a perfectly acceptable implementation when the function isn't called very often.
I think I'd understand your point of view better if you pointed out code you think is good.
Having worked for a couple of game companies myself, I'm at least somewhat aware of the pressures under which such code is written. While Mr. Carmack is at least partially immune from some of these pressures, being part owner of his company, and being considered indispensible by his partners (I'm extrapolating from rumors here), but he's not immune from the need to develop a working engine, in sync with the content developers, while trying to provide enough bells and whistles to feed the hype machine, and keeping the product entertaining to play with (for people who like this kind of games, at least).Considering that, I think he's doing OK, and improving (look at the Wolfenstein 3D source, if you don't believe me, and bring a barf bag).
So, he's no Knuth. I don't know many people who are, but I certainly know that producing compact, elegant, well designed code, but taking 15 years to do it is not an option for most companies. Perfection has its cost.
Your third example seems to be mangled. As it originally appears in the code, it will actually compile.
Compared with most game code I've seen, though, this is golden. Take your third example, and follow through: I got suspicious seeing that the for loop doesn't test for iMAX_GLTEXTURES. It turns out that the test is done when trying to increment numgltextures, which is fine. I have certainly seen worse.
Funny that you missed that numgltextures doesn't appear to have been initialized anywhere, which is a genuine bug, though.
Oh, come on - few people are as vocal as he is, on techincal matters. From his.plan files, detailing every bug fix during development, to his public attempts at blowing himself up, he's always very open about what he does, how he does it, and why he does it.
If people flock to his words, it's mostly because he tends to make sense, and back his words with hours upon hours of coding. Much of that code ends up being released under the GPL, so you can actually see for yourself whether it's any good.
See be-fan's response for some good points on kernel vs. process memory mapping.
Another thing to keep in mind is that when you put more and more kernel-like power in the hands of server processes, you quickly lose one of the only remaining advantages to having a microkernel, which is its theoretical stability. If a user process can perform I/O, mess with memroy mappings, install interrupt handlers and disable interrupts, then what's the difference between that and a kernel module? If it crashes, you can't restart it. You can probably unload it cleanly, but you can do the same with a kernel module.
As for speed, QNX4 has its roots in real mode 8086, and it shows. Its design is probably the best thing you can come up with when you don't have to worry about memory protection, and you can pass pointers in messages like cookies.
Also, microkernels make it easier to tune latency issues in a real time environment, because each server can be given its own priority level. For example, you can run a user app at a higher priority than the file system driver. That's really nice, but fast it ain't.
As a rule, low latency and high throughput are conflicting design goals. You can't have both.
Won't work as well as you might think. Atmel's SNMP agent makes gratuitous use of binary values for OCTET-STRING nodes, making it very difficult to set or read these nodes with standard SNMP tools.
Slashdot Mirror
*BANG!*
Duh... Where's my foot?
I think it's "free as those free peanuts you get on transatlantic flights in shiny little plastic bags".
You can't stand 'em, but they're free, so you eat 'em anyway.
The Wine developers recently debated whether to change the licence to LGPL from an X11 style license. They decided against it. One of the original reasons to go with the X11 license is worth keeping in mind: There's already a proprietary implementation of Win32. Microsoft sells it.
.NET and Mono. The danger in a company making a proprietary version of Mono is in the proprietary version becoming more popular than the free version, and eventually incompatible with it. If this doesn't happen, users always have the choice between paying for a proprietary product, or getting the open source version. Microsoft's proprietary version of Mono pretty much makes this a non-issue.
The same is true for
Oh, don't get me started on Windows...
I'm not speaking in favor of Windows. I'm just pointing out an instance where a specific Windows application performed better than a specific Linux application.
Also, I don't have to like Windows to point out how ugly a piece of source code is. There's no excuse for writing bad code.
Having said that, Linux would be a pretty bad choice for a home OS at this point, for users who don't want to understand the subtle differences between, say, gcc and syslogd, and still want to use their PC's to send e-mail, write letters, and do video captures. Yep, I threw in video capture because that's something that's genuinly hard to set up under Linux. It's not there yet.
What kind of beer?
Oh, as for who did the wine stuff? lets say it's not transgaming, you know who ;)
Not hard to guess, especially considering that Codeweavers just submitted a huge patch to WineHQ, described as "Patch to improve Microsoft Office 2000 functionality".
Speak Freely
MPlayer may be the fastest MPEG-2 decoder for Linux (at least the fastest I've tried), but the Windows software I got with my DVD drive kicks its butt on the same hardware (a 300MHz Pentium II).MPlayer simply can't play a DVD on that CPU, while PowerDVD doesn't seem to have any problems doing it (other than the decoding artifacts at macroblock boundaries on black screens, that is.)
I got the impression that Mplayer's MPEG-2 codec is rather cache unfriendly. MPlayer is also one of the most impressively unreadable pieces of code I've ever seen, and its design is about as modular as a watermellon.
I seem to remember that you can shut down the originating machine, and the shutdown scripts will force everything that can be migrated (i.e. isn't tied down to the hardware, or (unfortunately) a TCP/IP socket) to go find somewhere else to play.
To solve this guy's problem, he would have had to run Mosix over a VPN with a redundant machine off-site. Not easy to set up or maintain.
The VPN is necessary because Mosix sends internal kernel information over the network.
The point with the telephone is that the wire is actually invisible in each of the photoreceptors.
Not really. That's why I pointed out that photoreceptors don't sample at a single point. Instead, they average a small area, which makes a big difference.
Let's look at some hypothetical telephone wires. Think of a very thin, very distant, and very bright phone wire. Photons emitted by the wire hit your eye, and get focused on your retina. The photons hit a very thin line on your retina - much thinner than a single photoreceptor. The number of photons hitting the photoreceptors will still be large enough to make each one of them fire, making your brain believe that what it's seeing is a telephone wire, as thick as the line of photoreceptors on the retina, projected back through the lens and cornea, all the way back to where the telephone wire really is. You won't know how thin the wire is, but you'll know it's there.
The less extreme case, with an ordinary telephone wire, works just the same, except that the number of photons hitting your retina is much smaller, making them fire less frequently. If lighting conditions are bad enough, you will no longer see the wire, simply because the difference between the firing rate of photoreceptors that have the wire's image on them, and the firing rate of those that don't, is so close that it disappears into the noise.
The exact sequence and timing are affected by inaudible frequency components.
How are the affected? Can you point to a paper discussing this? It sounds interesting.
You can see a telephone line, which is smaller than the eye can resolve. With "perfect reproduction", the telephone line would vanish.
I'm not sure you can draw any conclusions on the auditory system from our vision system.
Besides, the retina doesn't sample at idealized points, since photoreceptors have a surface area. That, and the wiring of phtoreceptors to ganglion cells, are different enough from the assumptions made by the sampling theorem to make me suspicious of attempts to draw conclusions from sampling theory to the vision system.
...which is exactly what I was doing in my previous post, only with the auditory system. Your point is well taken.
What you are describing is windows, not a true RT system.
What I'm describing is based my experience writing some real time applications on QNX, in the last few years. The QNX documentation is available on the web, and the system is free for non commercial use. Download it, compile an application that sets its scheduling algorithm to SCHED_FIFO and its priority to the shell's priority+1,and goes into an infinite loop, run it, and see how responsive the system becomes. You don't have to take my word for it.
The only way out was to set the inner loop to yield to other processes when its calculation was done. This, effectively, amounts to rewriting the kernel low-level scheduler.
Huh? This amounts to not hogging the CPU when you don't have to. This is good practice under any OS, and doesn't even resemble rewriting the scheduler. Not even from a distance, on a dark foggy night.
The problem with "real time" priority under NT is not that bad code will lock up your machine if you tell the OS not to interrupt it. The problem is that the system can't guarantee that a real time task will get the CPU in a bounded time when it needs it (in response to an interrupt, for example). That's the difference between a RTOS and a non real time OS.
In a true real-time system, I would be able to set the mouse and keyboard processes to run at given intervals, while still having my data-handling routine able to digest what came in.
That is simply incorrect. For your keyboard and mouse "processes" (drivers, most likely) to be useful to anybody, the OS has to wake up a user process to handle mouse and keyboard events when they're available. If you tell the OS to give a higher priority to another process, NOTHING is going to interrupt that process until it yields. The assumption is that you know what you're doing, and that you really reallly need the CPU, or bad things will happen (bad, as in people will die, in some cases).You can't afford to have heuristics like "if a process had the CPU for too long in the last second, switch to another task. Let's all be nice and share!".(Actuallly, QNX does have such heuristics, but by running SCHED_FIFO you effectively disable them for the SCHED_FIFO task).
And that's only half of the picture. The other important element of real-time performance is that if your low priority task (your window manager, for example) is busy doing something, like drawing a bitmap on the display, and the system gets an interrupt that's served by a real time task, the OS will immediately switch to the real time task, leaving your pretty picture half drawn for as long as it takes to handle the high priority task. If you get 1000 such interrupts per second, it'll take some time for your window manager to finish drawing that bitmap, and, yes, the system will feel sluggish, but that's by design.
I won't even get into discussing throughput vs. latency issues.
Fortunately, my story has a happy ending I found out that Linux has a good enough scheduler to run my program without data loss, even if it's not a true real-time OS.
Good - I'm happy for you. I bet you can't compile a kernel while your code is running, though - not without causing it to miss deadlines, and not on a stock kernel, in any case. Linux really isn't a RTOS.
An RTOS can't make any design tradeoffs that will make its behavior unpredictable. That rules out swap and memory overcommit right off the bat. How is that good for everyone?
You do realize that if your DVD player is running at a high priority on a RTOS, then nothing is going to get CPU time when it's busy working its IDCT magic. This is a good thing in an embedded system, because people don't like it when their movies pause occasionally because the OS wants to do some housekeeping, sync the disk, update the clock on the front panel...
But what if you're running your DVD player on a 200MHz Pentium? Most likely, you'll freeze your system, because the high priority process won't be able to keep up, and will use 100% of the available CPU time. Embedded systems have a known hardware profile - desktops don't.
Oh boy...
If it wasn't in the original signal you sampled, you can't hear it. It's that simple. If your low frequency note was in fact shaped by some ultrasound signals that only your dog can hear, then filtering and sampling just the audible range will give you a perfect reproduction - as good as permitted by your sampling rate and the number of bits you can throw at a sample. Filtering, of course, is necessary to eliminate aliasing of high frequency components into low frequency noise.
This is more obvious if you look at the human ear, and realize that it actually performs a transform to the frequency domain, and doesn't sample the actual wave form.
Now, it seems from your wording that you already know that. I'm just pointing this out to people who might get confused.
The Duck, actually.
The second story
...and with X10, no less. There was a "news" story about the X10 $6 firecracker kit a few years ago, that kept getting suspiciously reposted for a few days.
Are you sure we want to launch Britney Spears into space?
One other thing to keep in mind is that that QPSK channel is shared, so you have to worry about collisions. That reduces your bandwidth even more.
No wonder - upstream on cable plants was designed to suppor pay per view purchases, not web servers.
Actually, cable technology is skewed this way. To get high bandwidth, you have to transmit at high enough RF levels to get over the noise (and cable plants are noisy). If your cable modem had enough juice to transmit this loudly, it'd be a toaster.So, upstream has less bandwidth than downstream.
It all comes down to SNR.
You still fail to point out what you object to in the Quake 2 code you posted. Is it the O(n) time complexity of the search loop? (the same thing can be done in O(1)) It is rather simple, and appears to be optimized for development time, rather than run time. Whether this is a valid tradeoff or not depends on the context.I'll argue that this is a perfectly acceptable implementation when the function isn't called very often.
I think I'd understand your point of view better if you pointed out code you think is good.
Having worked for a couple of game companies myself, I'm at least somewhat aware of the pressures under which such code is written. While Mr. Carmack is at least partially immune from some of these pressures, being part owner of his company, and being considered indispensible by his partners (I'm extrapolating from rumors here), but he's not immune from the need to develop a working engine, in sync with the content developers, while trying to provide enough bells and whistles to feed the hype machine, and keeping the product entertaining to play with (for people who like this kind of games, at least).Considering that, I think he's doing OK, and improving (look at the Wolfenstein 3D source, if you don't believe me, and bring a barf bag).
So, he's no Knuth. I don't know many people who are, but I certainly know that producing compact, elegant, well designed code, but taking 15 years to do it is not an option for most companies. Perfection has its cost.
Your third example seems to be mangled. As it originally appears in the code, it will actually compile.
Compared with most game code I've seen, though, this is golden. Take your third example, and follow through: I got suspicious seeing that the for loop doesn't test for iMAX_GLTEXTURES. It turns out that the test is done when trying to increment numgltextures, which is fine. I have certainly seen worse.
Funny that you missed that numgltextures doesn't appear to have been initialized anywhere, which is a genuine bug, though.
Actually, I did look at it. It's pretty good, for a piece of production code.
Can you point to a good piece of code, so I can understand what your standards are?
If people flock to his words, it's mostly because he tends to make sense, and back his words with hours upon hours of coding. Much of that code ends up being released under the GPL, so you can actually see for yourself whether it's any good.
See be-fan's response for some good points on kernel vs. process memory mapping.
Another thing to keep in mind is that when you put more and more kernel-like power in the hands of server processes, you quickly lose one of the only remaining advantages to having a microkernel, which is its theoretical stability. If a user process can perform I/O, mess with memroy mappings, install interrupt handlers and disable interrupts, then what's the difference between that and a kernel module? If it crashes, you can't restart it. You can probably unload it cleanly, but you can do the same with a kernel module.
As for speed, QNX4 has its roots in real mode 8086, and it shows. Its design is probably the best thing you can come up with when you don't have to worry about memory protection, and you can pass pointers in messages like cookies.
Also, microkernels make it easier to tune latency issues in a real time environment, because each server can be given its own priority level. For example, you can run a user app at a higher priority than the file system driver. That's really nice, but fast it ain't.
As a rule, low latency and high throughput are conflicting design goals. You can't have both.
Won't work as well as you might think. Atmel's SNMP agent makes gratuitous use of binary values for OCTET-STRING nodes, making it very difficult to set or read these nodes with standard SNMP tools.