All these posts along the lines of, "You released it free, now take your lumps!" are completely missing the point. (Well, at least of the article. The point of the timothy, who linked to the article, is another matter)
The point is, if a company uses free software, it should open its pocketbook instead of whining. Instead of going, "Waaa, it doesn't have feature X!" or "Waaa, there's a bug!" it should pay someone to fix the problem. It could pay someone in-house, in which case it should release the patches back to the community, or it can pay someone externally to do it.
One point that's often missed about releasing patches done in-house: the GPL doesn't require it for most backend software, but it's still a good plan for reasons other than being ethical and nice. If you release the patches, they can be integrated into the product as a whole, meaning you don't have to handle the expensive task of being their sole maintainer in the future.
It seems to me that the article is exactly right. Companies already do this to an extent by paying companies like Redhat for support, but if a piece of software is important to your business, it only makes sense to take a direct hand in its development. The whole mentality of purely being a consumer of whatever is offered from the development community is neither productive nor cost-effective. If something is important to you, make it happen. Don't just wait for other people to do it for you. That sort of thinking gives you situations like Microsoft, where someone might get around to helping you eventually, but oh man will your pocketbook be sorry.
As with politics, money talks. If you want the best software for your business, you should help fund the developers who can make it happen. Otherwise, since it's free software, you'll be able to use whatever the community thinks is important, but what you think is important may not be considered as relevant or get done as quickly (or at all).
It is unfortunate when people discover college is a bad choice after they've already started it. With or without student loans, you're out a lot of money. In fact, almost the same amount of money.
2. Not eveyone who finishes, gets a "swanky ass-job" the minute they graduate.
That's why there's a button on their web site that says, "Reduce my payments." You can select various options, including "income contingent" meaning you only pay what you can afford (and if you're really poor, they'll probably forgive the loan eventually).
3. Not everyone gets a 2% flat-rate loan.
Everyone who gets a federally guaranteed loan gets an insanely low rate, actually.
The 2% is the finance charge for taking the loan.
Typical student loans are 5-6% interest rate (or lower these days!), and the repayment period starts six months after you graduate or otherwise leave school.
It's still a loan, but it's about the friendliest loan imaginable. Going to a school you can't (and will never) be able to afford is a bad idea regardless of loans, but if it's a question of starving now or having a light burden later, loans are a very good idea.
Just go to a state school. Ivy league schools and the like don't make very good financial sense, and the education is hardly better. If your degree isn't vocational, it's probably a good idea to go to a school that's not too expensive, too. (For example, Harvard may be a good idea if you're getting a law degree, regardless of how poor you are. If you're majoring in comparative literature, you should make sure your daddy's rich first)
4. Not everyone's student loan actually pays them so well that they still aren't living on ramen.
The loans are calculated based on the cost of living and your current finances, so you should at least be able to upgrade to Mac'n'cheese. And considering that water is more expensive than gas, beer is probably a cost-saving measure.
Lest you think my swank-ass job involves working for the student loan people, I make computers go "beep."
I took out some student loans, and used them to protect my bank account (and my parents'). Result: I graduated, got a swanky ass job, and paid them off about three months after the grace period ended. I could have paid them off sooner.
Total interest paid: <$100
So, for less than a hundred bucks, I got to live the good life in college and not be completely broke all the time.
Consider:
Option A) You could pay now, when you're dirt poor, and later when you're rich you can puke at the sight of ramen.
Option B) You could pay $100 later when you're rich, and now you can kick back, have a couple beers, eat decent food, and not worry about money too much.
Yeah, B sounds pretty good.
(Ok, that's not entirely correct, the loans came with a finance charge, so it was probably $100 + 2%, but whatever.)
How's that for a positive experience?
And the student loan people are about the friendliest creditors you can possibly imagine. I mean, you can actually just go to their web site and click a button basically marked, "lower my payments now."
Try THAT with your bank.
Plus, they periodically sent me notices saying, "Hey, we're feeling nice today, we lowered your interest rate permanently. Again."
Not to mention the time or two when I got a notice in the mail while I was in school saying they'd just decided to turn my loan into a grant that quarter 'cause they found some money lying around in the back room and I had decent grades.
It's often better financially to not pay them off.
Creditors don't really count them against you like other debt, and the interest rates are microscopic. So if you're going to do something like buy a house, you're better off putting your money in the bank and making a minimum payment on the student loans so you can increase your down payment.
Wow, next thing you know, they'll be inventing the command line!
I mean, just imagine... You could control a computer just by typing in text, almost like language! None of those bizarre manhandling a carpal tunnel creating mouse all day to point at primitive representations on the screen!
Er, oh wait. They are.
Why is it that whenever Microsoft "invents" something that everyone else has had for decades, it's "big news" and "innovation" ?
On the off chance you'll still see this, even though the response is quite late...
The basic problem here is that the graphics API just has a command, "flip buffers." You could have more than two buffers - but you can't flip it asynchronously. What you need is a "Please flip the buffer on the next sync and send me a signal when you do it" command, or more generally, a "please send me an interrupt on sync" along with an interrupt-safe buffer flip command.
Even if you have more buffers, if you have to wait for the vsync before flipping them, then there will be a period of time (in the worst case, an entire vsync!) during which the card does nothing but sit there waiting for the electron gun to scan.
To describe programattically:
"Modern" brain-damaged API: loop: ....render back buffer ....flip front to back buffer and stall until vsync
Correct, working API used for decades on console machines, C64's, amigas, and basically anything not a PC:
loop ....wait for back buffer available ....render back buffer
on vsync interrupt ....if back buffer ready ........flip buffers and set available
It should be fairly clear that the first one will have "dead time" while the second one won't, so it will have lower throughput.
Now, triple buffers are typically a feature of the second model, since they allow higher throughput if the video may take more than a frame to render.
The historic reason for this problem is really that PC's had a broken peripheral bus, and hence couldn't spare an IRQ for the video card. Seriously. So they just ignored the problem and hoped it would go away.
Now, oddly enough, people argue that it never existed in the first place. So perhaps it did go away! People trained themselves to want video to be rendered incorrectly.
In any case, the artifact the original poster alluded to - if video is overloaded, it will only be rendered at an even fraction of the vsync rate, eg. 70fps->35fps->etc., could only happen if the vsync scheduler was stalling. In this case, the video card would run over one frame length rendering video, and then would have to wait almost an entire vsync period doing nothing, every time. With the correct API, if the card can only render at 64fps instead of 75, then it'll display at 64fps, not 37.
This description is really just describing a bug in the 3D rendering libraries.
The problem is that the APIs aren't designed properly, and don't expose a proper vsync interrupt to the application. This means that vsync lock in the API actually means, "Wait for vsync when given a flip command" which is completely wrong. It means that the game gets stalled waiting for a page flip, when in fact it should be calculating the next frame while the current one is queued, and flush the current frame on the interrupt.
With a proper game engine and graphics API, there is no reason any sane person would ever turn off VSYNC.
The simple answer is that they they're not developed very well. Thus, Windows crashes. A lot.
Microsoft gets blamed for this, and well they should, since they're the ones who created this whole situation. But the truth is, the instability tends to be caused more by third party device drivers than anything else.
The more complicated answer is that a vast number of the device drivers for Windows are written by Microsoft themselves. The core hardware drivers are all done in-house, and as new hardware is introduced, Microsoft tends to co-opt driver development for it in new versions of Windows. They do this because letting device manufacturers provide the drivers is a recipe for disaster that's been burning them for about a decade now. Thus, the latest versions of Windows crash less than the earlier ones did.
So, basically, while Microsoft may be edgy about releasing source code, they're a huge gorilla and can easily go smack the hardware manufacturers around and demand the specs and/or driver source for the hardware. Then they can go stabilize it themselves if need be.
Plus, it is possible for hardware manufacturers to get access to Windows code if they need it, and further, Microsoft provides a whole lot of support to hardware manufacturers to help them get their drivers functioning.
All of this is very inefficient and full of loathesome scutwork, but that's what Microsoft pays people for. And they reap huge benefits from all this secrecy - the latest hardware only works on Windows, and their competitors have a horrible time trying to reverse engineer all these hardware devices just to get them partially functional.
Device drivers are essentially completely integrated with the OS kernel. Even in "microkernel" operating systems that purport to create a separation at a performance cost, this is true.
There are a few basic reasons for this. The first is simplicity and performance. An OS which moves data around device drivers by sharing memory and providing direct access will be faster and easier to understand and debug than one which attempts to use a message passing scheme for all IO data internally.
The second is really just reality. A device driver is something that talks to a bare hardware device. This is the very thing that the idea of "protection" and "decoupling" and such is trying to avoid. Hence, by definition, it has horribly powerful low level control over the computer. All sorts of catastrophic actions by a device driver are trivial and also impossible to block. Want to crash the entire system bus? Read and write over any random section of kernel memory? Crash other hardware devices? Cause other hardware devices to walk over memory? Deadlock core subsystems by taking locks in the wrong order? Etc.
All of these things are trivial to do with low level hardware access. Even making a "microkernel" with different protection levels for device drivers doesn't really help at all. Even if there's some redumentary memory protection through the CPU, the driver can certainly hang the computer, or read/corrupt any memory it pleases through the DMAC or some other hardware access primitive.
The only correct way to consider a device driver is that it's a core component of the OS kernel itself. There may be some interfaces the kernel makes available to particular sorts of devices so they can work in a generic way, but certainly in any sense of stability, security, or correct operation the device driver is just as critical as anything else in the OS.
This is the problem with closed source ones, of course. They can't be supported by anyone except the company that made them, so they'll break whenever the kernel changes in a way that's incompatible or simply exposes a bug in the driver. Since nobody can fix it, this simply means that any poor person stuck with such a badly supported piece of hardware will be left out in the cold when new kernel releases come out, having to wait for the company they bought the hardware from to update the drivers.
And of course, when the OS crashes, no matter what the problem is, only that company can fix it since nobody else has the requisite information. So, unless that company feels comfortable fixing all kernel bugs, not just their own drivers', for their customers, anyone with such a piece of hardware is effectively eliminated as part of the general debugging community for Linux. Meaning, Linux as a whole suffers since any problems these people have in the rest of the kernel are not going to be fixable.
Proprietary software may be ok for applications in some situations, but it's really horrible when the core system software isn't available. You have problems that are simply unfixable - and break all applications too!
Computers should work properly (ie., they shouldn't crash and should perform well), and keeping IO device specifications and drivers a big secret is one of the most significant things keeping them from doing that. I really think hardware manufacturers should take far more of the blame than they do for this issue - operating systems and software in general gets a bad rap in terms of stability, but how can something be stable when the way it talks to the hardware it runs on is this big secret kludge and any problem will cause it all to fall apart?
It's nice to see that hyperbole is alive and well in the modern world.
First, unauthorized copying was "theft." Now, looking at web sites without staring at the ads is "theft."
What next, failing to buy a banana in the store is "theft"? After all, if someone doesn't buy it, they'll have to throw it away! And that means, they're losing money!
This is ridiculous. If you don't want people to download information off your server, put it behind a password. Otherwise, stop yer bitching and moaning. If you put information up for the public to see, guess what? OH NO! They might actually see it!
Be glad people who don't want to look at your ads have ad-blockers. It saves the bandwidth for the internet, and maybe even you if they not only don't look at the ads, but don't download them either.
This is correct, only the actual situation is even more so.
It's possible to produce oil from other sources, such as coal or some kinds of shale (or in the ultimate extreme, pure synthetic). It's simply more expensive to do this than it is to pump it out of the ground.
Hence, once the price of oil reaches a certain point, it'll simply be cheaper to make it some other way. And the conversion costs based on, say, coal aren't really very prohibitive at all, so the people who can afford a 7mpg SUV probably won't stop driving it in the least.
Of course, it should be rather clear that this isn't exactly a good thing, since this means that the environmental damage from fossil fuel emissions has no end in sight. But it is clear that the world isn't going to grind to a halt any time soon.
Of course, at some point, it won't be a net energy win to use fossil fuels (purely synthetic production clearly will require more power than you get out, for example), so we'll have to transition over to other more sustainable and cleaner sources of power such as nuclear fission, solar, and geothermal.
404 is one of the standard response codes of the telnet protocol on which the web's HTTP is based.
The first 4 indicates a client error such as a mistyped URL.
The middle 0 refers to a general syntax error. The last 4
just indicates the specific error in the group of 40x, which
also includes 400: Bad Request, 401: Unauthorized, etc.
By their own definition, it would appear the reference.com site is itself a 404 error.:-)
This feature is properly known as a SAK - Secure Attention Key. It's an old security feature used to prevent hijacking of trusted consoles, as you said, and is implemented on many systems. The perennial place where it's needed is university computer labs, where logging in and then leaving a fake login prompt running to capture passwords is has always been considered good clean fun. (To implement it properly, one should print a "wrong password!" message, and then exit the user session completely giving the user the real login prompt)
The basic idea is that the OS traps the SAK and does something obvious (like give you a login prompt) to keep a user from running a program pretending to be the OS. Since the OS doesn't let the user handle the SAK, security is maintained.
Linux supports SAK, however it's never really been properly deployed by distributions. Part of the reason is that nobody's ever really standardized on what the SAK key should be. If SysRQ is enabled, than Alt-SysRQ-k will cause a SAK event in the kernel. Otherwise, the keyboard driver can be configured by root to use any key sequence. One key sequence I've seen used is Alt-SysRQ-PageDown, but there's really no particular standard.
When SAK is raised in linux, all programs running on the current terminal are force-killed. It's then expected that init will provide a new login prompt there.
This leads to the second problem with SAK on Linux, namely that most users run X on workstation machines. If you SAK while X is running, the kernel kill -9's X... Which trashes your video card, leaving the system in an unusable state. Which is probably not what you wanted. Some video drivers and cards in X may be stable enough that, if you're running xdm/gdm/kdm etc., it may be able to restart X and give you an X11 login prompt - but the console will still be trashed, so you won't be able to exit out of X afterwards (or eg. with ctrl-alt-f1). It used to be the case that you could store the video settings for your console and run a program (eg. restoretext etc.) to fix them, but that hasn't worked on any modern video card in years. In addition, if you just escape out of X and then fix the console, X will re-trash your console as soon as you return to it, since it only stores the console settings from when X was started, not the current settings. Hence, X and your console program get in a fight and you probably end up crashing the video card and having to pull the power plug out or something if you do this a lot.
Confusing things even more, XFree generally defines its own internal "SAK"-like key sequence, Ctrl-Alt-Backspace. This isn't actually an OS-level SAK though, it just instructs X to quit. And not surprisingly, it often doesn't work due to XFree bugs (and may be trappable by user apps).
E.g. it will automatically add to every buffer access the neccessary boundary checks. When fed with C-Sources, there are not enough meta informations to add these kinds of checks.
There's nothing in the C language spec that requires your compiler to permit buffer overflows or heap attacks, and indeed it's possible to disallow them at runtime.
Nobody does it, of course, because it adds a lot of overhead and, in the case of GC, less control. Well, that and, since nobody does it, the tools to do it aren't very mature.
Oh come on. 99% of the time, this "failure" is due to the admin having the number of concurrent mysql sessions set lower than the number of apache sessions. Since they'll never hit that situation in their half-assed testing with one browser...
And how exactly do you intend to compare the situation where MySQL saturates to the situation where apache saturates remotely, exactly? If apache falls over, you're getting no connection at all. Perhaps the database is working great, you'll never know.:p
I have, in my hand, a copy of a Harry Potter book.
In my other hand, I have a digital camera. Watch, as I take a photo of page 52.
Oh my, it appears the text is readable. Here, let me just share this out on Kazaa... (As a matter of fact, most popular books are shared right now)
What was the difference again?
Reality check here. Copyright applies to patterns of information. ALL patterns of information can be digitized and copied at (practically) zero cost.
The real difference here is that the book publishers' war to outlaw libraries, used bookstores, and reselling was lost centuries ago. Nobody will even take them seriously if they try to put that genie back in the bottle.
Meanwhile, the RIAA/MPAA/BSA etc. still think they can win and create a world where they control all sales and uses of their products, and thus can have absolute control over pricing. If they beat the "new, digital era" drum loudly enough, they think they can get new laws rammed through guaranteeing their profit margins forever.
Sadly, it looks like the governments of the world may actually be so stupid as to let them.
Well, except for games.
And anything that uses 3D.
Games and 3D make heavy use of FPU, but it's interesting to note that as time goes on, more and more of the heavy lifting FP work is being offloaded to the graphics processor.
Given a few more generations, most of the FPU work in todays games may actually be executed in the GPU.
Of course, this doesn't actually change anything, since tomorrow's games will just put that much more load on the CPU for physics processing and such!
And audio/video playback and work.
Video codecs are essentially all integer based. Audio codecs often use the FPU, but they really don't need to - fixed point implementations tend to be just as fast.
And image editing.
The vast bulk of image editing work tends to be integer-based, or easily convertible to integer-based.
And some spreadsheets.
Spreadsheet math calculations aren't really performance-related in any sense. 99.9% (remember, your statistics may be made up on the spot, but mine are based on sound scientific handwaving!) of the time a spreadsheet spends is in fiddling with the GUI, which is primarily an integer operation activity.
That said, the parent poster's point sort of goes both ways. It's true that the FPU unit is heavily underutilized by most things outside of games, so it's not an unreasonable idea to strip it out and let the FPU be emulated in software or microcode or whatnot.
However, that won't necessarily really help. Modern CPU cores are better able to manage their power routing than previous ones, so having an FPU on there doesn't necessarily cause any trouble. The CPU may be able to disconnect power to the FPU when it's not in use, thus making the whole thermal issue something of a moot point in this respect. If it doesn't generate heat, it's just a matter of wasted silicon - and silicon's becoming quite cheap!
In fact, the FPU is an example of good design in CPU's, really. It's not too hard to fit a lot of computation units on one CPU core these days, hence having multiple ALU and FPU computation units being driven by complicated pipelining and SIMD engines. The difficulty is making efficient use of them - note the trouble getting SMP to work efficiently, and the whole idea of hyperthreading. While the FPU may get fairly low utilization, it is fantastically faster at floating point computation than the integer cores are, and putting a couple on a chip is thus generally a pretty good idea.
I fully don't agree with what you are saying... mainly because you are accusing NT of being things I know it is not (I've worked extensively with the kernel), and also because of the symptoms I get: *if* my mp3 playback ever skips, the skip is typcial of a buffer underrun in the sound card (the same 500ms sound gets looped over and over - this same thing will happen if you get a BSOD). What this is is this: the kernel didn't have time to respond to an IRQ coming from the card saying "Feed me more data"... this, however, isn't an indication that some thread in the kernel was being late... this only means that the kernel was busy servicing another interrupt. That is the thing with non real time OSs... once servicing one interrupt, the kernel masks out (some) other interrupts.
I thought that was your last post on the subject? Anyway... Let me get this straight. Your sound fails because the OS chooses to ignore an interrupt raised by the hardware for hundreds of milliseconds, and you blame... the hardware? Or what? "The kernel didn't have time to respond..." vs. "this [...] isn't an indication that [the kernel] was [...] late." Huh?
The interrupt was raised. The kernel was late! What are you talking about?! By definition, it's the kernel's fault! Unless you're trying to claim that the bridge didn't deliver the interrupt when the kernel had it enabled. In the case of some hardware problems like a card squatting in bus-mastering mode, the kernel can do nothing. This is not one of them. We're talking about it failing to service an interrupt for probably a few hundred milliseconds! Clearly, the kernel's top-half interrupt handlers are running much too slow if that's the case. Much more likely, the kernel received the interrupt, put it in a list, and then simply did something else for half a second. Which is exactly what I stated above: it went and watered the flowers for a long time instead of responding.
And one last thing, do you seriously expect me to buy the argument that somehow NT doens't have a proper scheduler implementation? that it doesn't know how to schedule with priorities? That's just a foolish statement man. And I know it's false.
This is just silly. I never claimed NT lacked a functioning scheduler (though how good it is is certainly open to question - the OS does not, for instance, handle priority inversion properly - but then few do). I claimed that setting a thread as realtime priority in no way means it will actually work properly at servicing a realtime task. And that's true, it won't. NT is not an RTOS, and the fact that you're hearing it fall over driving your sound card sometimes proves that. Why are we arguing here?
If you download the div-x Player, or the Playa (don't have links for either, not in mood to karma whore either), you will see they play perfectly fine, even if stretched to full screen (since overlays actually don't consume CPU).
But they don't play perfectly fine. They play marginally fine - they still jitter and jump a lot, especially if your computer has anything else going on.
My point is this: no, NT isn't a real-time kernel... so yes, if your PCI bus is busy, it will skip. But then again, any system which isn't realtime will skip under the same circumstances too...
You're misunderstanding the concept of real-time software here. The OS cannot make realtime guarantees beyond what the hardware is capable of, so if you, say, have some brain-damaged hardware that goes into bus-mastering mode for long periods of time, your system is simply not going to work. You have a problem which cannot be solved in software. That's not what an RTOS is about.
The idea of an RTOS is that, within the domain of software, the RTOS provides facilities for software to make latency guarantees. So, if I have an OS which behaves as an RTOS of some sort (either "soft" meaning "very good" or "hard" meaning "without fail ever") and I have hardware which is compatible with the RT idea, I should be able to write software that works properly. Even under load, it should work properly. I should be able to do multiple kernel compiles at once and have perfect jitter-free non-skipping movie playback on an RTOS. Of course, I might need a dedicated disk to provide the movie I/O, but...
What this means is that the kernel is never going to just go off into the weeds for a while doing its own thing when I need the CPU, and it's never going to give the CPU to some undeserving process when I need it, basically.
NT is not an RTOS. Even if you do everything right, the kernel can, and will, just go off into the weeds sometimes. You might do a system call, and it decides to go balance its checkbook or something before getting back to you. It might take an interrupt and decide to go water the flowers before it bothers to mention that you have something to worry about.
Don't get me wrong, that's not really unexpected. Media playback is fairly new in desktop computers, so everyone's been lagging a bit in terms of making systems that are capable of doing it properly. Linux has the same problem out of the box.
Just don't kid yourself thinking that the OS is something it's not, or that all your problems are due to hardware. More likely than not, your problems are due to software. Certainly for bulk audio playback tasks like mp3, there's just no reason it shuld be skipping and dropping out other than a software problem. (If there was a bus-mastering sort of PCI problem, you'd probably hear it as some sort of high-frequency stuttering when you pressure the video card or whatnot, not skips and dropouts).
This is definitely not a design or implementation flaw - if that's somehow what you would want to infer. Windows NT has a very good multimedia architecture...
Yes, it is a design or implementation flaw when your OS fails to play mp3's properly. It's arguable that it may rather be user error because you went and tried to do a realtime media task on an OS that wasn't really designed for that, but the reason it's not working it almost certainly because the software isn't doing what you need it to. NT simply was not designed to be an RTOS.
Well, in reality, it'll probably drop something once in a while. If you don't mind that, then no, it doesn't matter at all.
RT performance is a lot more important for playing video, since it involves events that need servicing at a much higher frequency. Since people are starting to want to use their computers to drive their TV's a lot more these days, this is a serious issue (unless they don't mind the video being slightly nauseating every time it stutters through a pan, etc.)
You said it was designed for media. That implies it can make at least soft realtime guarantees, or it'll never be able to play audio/video properly.
It doesn't. Look at video players under Windows. They demonstrably don't play audio/video properly - the video players jitter all over the place. MP3 players most certainly do skip as well.
RT is about responding to an event within a certain deadline. Your sound card generates events (specifically, it generates interrupts signalling that the buffer needs filling). Your OS+application must respond to that event before the buffer runs dry, or your audio will skip. It's as simple as that.
RT priority simply means the application is at a strictly higher priority than other applications. It can relinquish its time slice implicitly by doing any number of things, particularly any form of disk I/O (including touching a page that was swapped out, etc.) The application will also be interrupted by the kernel, which as it's not an RTOS, may take any amount of time to do whatever it feels like.
The sound card has a fairly small buffer. The application is required to refill that buffer before it goes dry. So, say when the sound card raises an interrupt, "Give me more data", the OS and ultimately the application has a certain number of milliseconds during which it must provide the data, or the sound card will run dry and an audible skip will occur.
So, yes, it is a realtime issue.
For an mp3 player, the time during which the app must respond is relatively long in computer terms - maybe a few hundred milliseconds. That's on the order of a couple time slices, so the scheduler can (and will, eg. if your X server is running at high priority) definitely cause you to break. More likely, your app will be blocked on something else like disk IO, which can be much longer than that, and thus be unable to service the sound card in time.
Hence the reason the app must be written to make use of RT facilities if you want it to not skip. Along with the IO problem to read the file, the app also has to deal with the possibility that it might be paged out, and thus experience IO latency when it does anything at all. To really work right, it thus needs to disable paging for itself, run at realtime priority, and have some sort of shared memory ring buffer with another thread/process doing disk IO to buffer the IO latency. And that's just for something really simple like an mp3 player!
Slashdot Mirror
Oh wait, this is /.
All these posts along the lines of, "You released it free, now take your lumps!" are completely missing the point. (Well, at least of the article. The point of the timothy, who linked to the article, is another matter)
The point is, if a company uses free software, it should open its pocketbook instead of whining. Instead of going, "Waaa, it doesn't have feature X!" or "Waaa, there's a bug!" it should pay someone to fix the problem. It could pay someone in-house, in which case it should release the patches back to the community, or it can pay someone externally to do it.
One point that's often missed about releasing patches done in-house: the GPL doesn't require it for most backend software, but it's still a good plan for reasons other than being ethical and nice. If you release the patches, they can be integrated into the product as a whole, meaning you don't have to handle the expensive task of being their sole maintainer in the future.
It seems to me that the article is exactly right. Companies already do this to an extent by paying companies like Redhat for support, but if a piece of software is important to your business, it only makes sense to take a direct hand in its development. The whole mentality of purely being a consumer of whatever is offered from the development community is neither productive nor cost-effective. If something is important to you, make it happen. Don't just wait for other people to do it for you. That sort of thinking gives you situations like Microsoft, where someone might get around to helping you eventually, but oh man will your pocketbook be sorry.
As with politics, money talks. If you want the best software for your business, you should help fund the developers who can make it happen. Otherwise, since it's free software, you'll be able to use whatever the community thinks is important, but what you think is important may not be considered as relevant or get done as quickly (or at all).
1. Not everyone who goes to college finishes.
It is unfortunate when people discover college is a bad choice after they've already started it. With or without student loans, you're out a lot of money. In fact, almost the same amount of money.
2. Not eveyone who finishes, gets a "swanky ass-job" the minute they graduate.
That's why there's a button on their web site that says, "Reduce my payments." You can select various options, including "income contingent" meaning you only pay what you can afford (and if you're really poor, they'll probably forgive the loan eventually).
3. Not everyone gets a 2% flat-rate loan.
Everyone who gets a federally guaranteed loan gets an insanely low rate, actually.
The 2% is the finance charge for taking the loan.
Typical student loans are 5-6% interest rate (or lower these days!), and the repayment period starts six months after you graduate or otherwise leave school.
It's still a loan, but it's about the friendliest loan imaginable. Going to a school you can't (and will never) be able to afford is a bad idea regardless of loans, but if it's a question of starving now or having a light burden later, loans are a very good idea.
Just go to a state school. Ivy league schools and the like don't make very good financial sense, and the education is hardly better. If your degree isn't vocational, it's probably a good idea to go to a school that's not too expensive, too. (For example, Harvard may be a good idea if you're getting a law degree, regardless of how poor you are. If you're majoring in comparative literature, you should make sure your daddy's rich first)
4. Not everyone's student loan actually pays them so well that they still aren't living on ramen.
The loans are calculated based on the cost of living and your current finances, so you should at least be able to upgrade to Mac'n'cheese. And considering that water is more expensive than gas, beer is probably a cost-saving measure.
Lest you think my swank-ass job involves working for the student loan people, I make computers go "beep."
I took out some student loans, and used them to protect my bank account (and my parents'). Result: I graduated, got a swanky ass job, and paid them off about three months after the grace period ended. I could have paid them off sooner.
Total interest paid: <$100
So, for less than a hundred bucks, I got to live the good life in college and not be completely broke all the time.
Consider:
Option A) You could pay now, when you're dirt poor, and later when you're rich you can puke at the sight of ramen.
Option B) You could pay $100 later when you're rich, and now you can kick back, have a couple beers, eat decent food, and not worry about money too much.
Yeah, B sounds pretty good.
(Ok, that's not entirely correct, the loans came with a finance charge, so it was probably $100 + 2%, but whatever.)
How's that for a positive experience?
And the student loan people are about the friendliest creditors you can possibly imagine. I mean, you can actually just go to their web site and click a button basically marked, "lower my payments now."
Try THAT with your bank.
Plus, they periodically sent me notices saying, "Hey, we're feeling nice today, we lowered your interest rate permanently. Again."
Not to mention the time or two when I got a notice in the mail while I was in school saying they'd just decided to turn my loan into a grant that quarter 'cause they found some money lying around in the back room and I had decent grades.
It's often better financially to not pay them off.
Creditors don't really count them against you like other debt, and the interest rates are microscopic. So if you're going to do something like buy a house, you're better off putting your money in the bank and making a minimum payment on the student loans so you can increase your down payment.
Wow, next thing you know, they'll be inventing the command line!
I mean, just imagine... You could control a computer just by typing in text, almost like language! None of those bizarre manhandling a carpal tunnel creating mouse all day to point at primitive representations on the screen!
Er, oh wait. They are.
Why is it that whenever Microsoft "invents" something that everyone else has had for decades, it's "big news" and "innovation" ?
On the off chance you'll still see this, even though the response is quite late...
....render back buffer
....flip front to back buffer and stall until vsync
....wait for back buffer available
....render back buffer
....if back buffer ready
........flip buffers and set available
The basic problem here is that the graphics API just has a command, "flip buffers." You could have more than two buffers - but you can't flip it asynchronously. What you need is a "Please flip the buffer on the next sync and send me a signal when you do it" command, or more generally, a "please send me an interrupt on sync" along with an interrupt-safe buffer flip command.
Even if you have more buffers, if you have to wait for the vsync before flipping them, then there will be a period of time (in the worst case, an entire vsync!) during which the card does nothing but sit there waiting for the electron gun to scan.
To describe programattically:
"Modern" brain-damaged API:
loop:
Correct, working API used for decades on console machines, C64's, amigas, and basically anything not a PC:
loop
on vsync interrupt
It should be fairly clear that the first one will have "dead time" while the second one won't, so it will have lower throughput.
Now, triple buffers are typically a feature of the second model, since they allow higher throughput if the video may take more than a frame to render.
The historic reason for this problem is really that PC's had a broken peripheral bus, and hence couldn't spare an IRQ for the video card. Seriously. So they just ignored the problem and hoped it would go away.
Now, oddly enough, people argue that it never existed in the first place. So perhaps it did go away! People trained themselves to want video to be rendered incorrectly.
In any case, the artifact the original poster alluded to - if video is overloaded, it will only be rendered at an even fraction of the vsync rate, eg. 70fps->35fps->etc., could only happen if the vsync scheduler was stalling. In this case, the video card would run over one frame length rendering video, and then would have to wait almost an entire vsync period doing nothing, every time. With the correct API, if the card can only render at 64fps instead of 75, then it'll display at 64fps, not 37.
This description is really just describing a bug in the 3D rendering libraries.
The problem is that the APIs aren't designed properly, and don't expose a proper vsync interrupt to the application. This means that vsync lock in the API actually means, "Wait for vsync when given a flip command" which is completely wrong. It means that the game gets stalled waiting for a page flip, when in fact it should be calculating the next frame while the current one is queued, and flush the current frame on the interrupt.
With a proper game engine and graphics API, there is no reason any sane person would ever turn off VSYNC.
The simple answer is that they they're not developed very well. Thus, Windows crashes. A lot.
Microsoft gets blamed for this, and well they should, since they're the ones who created this whole situation. But the truth is, the instability tends to be caused more by third party device drivers than anything else.
The more complicated answer is that a vast number of the device drivers for Windows are written by Microsoft themselves. The core hardware drivers are all done in-house, and as new hardware is introduced, Microsoft tends to co-opt driver development for it in new versions of Windows. They do this because letting device manufacturers provide the drivers is a recipe for disaster that's been burning them for about a decade now. Thus, the latest versions of Windows crash less than the earlier ones did.
So, basically, while Microsoft may be edgy about releasing source code, they're a huge gorilla and can easily go smack the hardware manufacturers around and demand the specs and/or driver source for the hardware. Then they can go stabilize it themselves if need be.
Plus, it is possible for hardware manufacturers to get access to Windows code if they need it, and further, Microsoft provides a whole lot of support to hardware manufacturers to help them get their drivers functioning.
All of this is very inefficient and full of loathesome scutwork, but that's what Microsoft pays people for. And they reap huge benefits from all this secrecy - the latest hardware only works on Windows, and their competitors have a horrible time trying to reverse engineer all these hardware devices just to get them partially functional.
Device drivers are essentially completely integrated with the OS kernel. Even in "microkernel" operating systems that purport to create a separation at a performance cost, this is true.
There are a few basic reasons for this. The first is simplicity and performance. An OS which moves data around device drivers by sharing memory and providing direct access will be faster and easier to understand and debug than one which attempts to use a message passing scheme for all IO data internally.
The second is really just reality. A device driver is something that talks to a bare hardware device. This is the very thing that the idea of "protection" and "decoupling" and such is trying to avoid. Hence, by definition, it has horribly powerful low level control over the computer. All sorts of catastrophic actions by a device driver are trivial and also impossible to block. Want to crash the entire system bus? Read and write over any random section of kernel memory? Crash other hardware devices? Cause other hardware devices to walk over memory? Deadlock core subsystems by taking locks in the wrong order? Etc.
All of these things are trivial to do with low level hardware access. Even making a "microkernel" with different protection levels for device drivers doesn't really help at all. Even if there's some redumentary memory protection through the CPU, the driver can certainly hang the computer, or read/corrupt any memory it pleases through the DMAC or some other hardware access primitive.
The only correct way to consider a device driver is that it's a core component of the OS kernel itself. There may be some interfaces the kernel makes available to particular sorts of devices so they can work in a generic way, but certainly in any sense of stability, security, or correct operation the device driver is just as critical as anything else in the OS.
This is the problem with closed source ones, of course. They can't be supported by anyone except the company that made them, so they'll break whenever the kernel changes in a way that's incompatible or simply exposes a bug in the driver. Since nobody can fix it, this simply means that any poor person stuck with such a badly supported piece of hardware will be left out in the cold when new kernel releases come out, having to wait for the company they bought the hardware from to update the drivers.
And of course, when the OS crashes, no matter what the problem is, only that company can fix it since nobody else has the requisite information. So, unless that company feels comfortable fixing all kernel bugs, not just their own drivers', for their customers, anyone with such a piece of hardware is effectively eliminated as part of the general debugging community for Linux. Meaning, Linux as a whole suffers since any problems these people have in the rest of the kernel are not going to be fixable.
Proprietary software may be ok for applications in some situations, but it's really horrible when the core system software isn't available. You have problems that are simply unfixable - and break all applications too!
Computers should work properly (ie., they shouldn't crash and should perform well), and keeping IO device specifications and drivers a big secret is one of the most significant things keeping them from doing that. I really think hardware manufacturers should take far more of the blame than they do for this issue - operating systems and software in general gets a bad rap in terms of stability, but how can something be stable when the way it talks to the hardware it runs on is this big secret kludge and any problem will cause it all to fall apart?
It's nice to see that hyperbole is alive and well in the modern world.
First, unauthorized copying was "theft." Now, looking at web sites without staring at the ads is "theft."
What next, failing to buy a banana in the store is "theft"? After all, if someone doesn't buy it, they'll have to throw it away! And that means, they're losing money!
This is ridiculous. If you don't want people to download information off your server, put it behind a password. Otherwise, stop yer bitching and moaning. If you put information up for the public to see, guess what? OH NO! They might actually see it!
Be glad people who don't want to look at your ads have ad-blockers. It saves the bandwidth for the internet, and maybe even you if they not only don't look at the ads, but don't download them either.
It's possible to produce oil from other sources, such as coal or some kinds of shale (or in the ultimate extreme, pure synthetic). It's simply more expensive to do this than it is to pump it out of the ground.
Hence, once the price of oil reaches a certain point, it'll simply be cheaper to make it some other way. And the conversion costs based on, say, coal aren't really very prohibitive at all, so the people who can afford a 7mpg SUV probably won't stop driving it in the least.
Of course, it should be rather clear that this isn't exactly a good thing, since this means that the environmental damage from fossil fuel emissions has no end in sight. But it is clear that the world isn't going to grind to a halt any time soon.
Of course, at some point, it won't be a net energy win to use fossil fuels (purely synthetic production clearly will require more power than you get out, for example), so we'll have to transition over to other more sustainable and cleaner sources of power such as nuclear fission, solar, and geothermal.
One of the country's problems is lack of exploration.
How does not spending money on exploration help this?
The percentage of Windows apps with broken cut and paste is probably about in line with the number of Linux apps with broken cut and paste.
This feature is properly known as a SAK - Secure Attention Key. It's an old security feature used to prevent hijacking of trusted consoles, as you said, and is implemented on many systems. The perennial place where it's needed is university computer labs, where logging in and then leaving a fake login prompt running to capture passwords is has always been considered good clean fun. (To implement it properly, one should print a "wrong password!" message, and then exit the user session completely giving the user the real login prompt)
The basic idea is that the OS traps the SAK and does something obvious (like give you a login prompt) to keep a user from running a program pretending to be the OS. Since the OS doesn't let the user handle the SAK, security is maintained.
Linux supports SAK, however it's never really been properly deployed by distributions. Part of the reason is that nobody's ever really standardized on what the SAK key should be. If SysRQ is enabled, than Alt-SysRQ-k will cause a SAK event in the kernel. Otherwise, the keyboard driver can be configured by root to use any key sequence. One key sequence I've seen used is Alt-SysRQ-PageDown, but there's really no particular standard.
When SAK is raised in linux, all programs running on the current terminal are force-killed. It's then expected that init will provide a new login prompt there.
This leads to the second problem with SAK on Linux, namely that most users run X on workstation machines. If you SAK while X is running, the kernel kill -9's X... Which trashes your video card, leaving the system in an unusable state. Which is probably not what you wanted. Some video drivers and cards in X may be stable enough that, if you're running xdm/gdm/kdm etc., it may be able to restart X and give you an X11 login prompt - but the console will still be trashed, so you won't be able to exit out of X afterwards (or eg. with ctrl-alt-f1). It used to be the case that you could store the video settings for your console and run a program (eg. restoretext etc.) to fix them, but that hasn't worked on any modern video card in years. In addition, if you just escape out of X and then fix the console, X will re-trash your console as soon as you return to it, since it only stores the console settings from when X was started, not the current settings. Hence, X and your console program get in a fight and you probably end up crashing the video card and having to pull the power plug out or something if you do this a lot.
Confusing things even more, XFree generally defines its own internal "SAK"-like key sequence, Ctrl-Alt-Backspace. This isn't actually an OS-level SAK though, it just instructs X to quit. And not surprisingly, it often doesn't work due to XFree bugs (and may be trappable by user apps).
Yes there are.
There's nothing in the C language spec that requires your compiler to permit buffer overflows or heap attacks, and indeed it's possible to disallow them at runtime.
Nobody does it, of course, because it adds a lot of overhead and, in the case of GC, less control. Well, that and, since nobody does it, the tools to do it aren't very mature.
Oh come on. 99% of the time, this "failure" is due to the admin having the number of concurrent mysql sessions set lower than the number of apache sessions. Since they'll never hit that situation in their half-assed testing with one browser...
:p
And how exactly do you intend to compare the situation where MySQL saturates to the situation where apache saturates remotely, exactly? If apache falls over, you're getting no connection at all. Perhaps the database is working great, you'll never know.
Hmm. Let's see here.
I have, in my hand, a copy of a Harry Potter book.
In my other hand, I have a digital camera. Watch, as I take a photo of page 52.
Oh my, it appears the text is readable. Here, let me just share this out on Kazaa... (As a matter of fact, most popular books are shared right now)
What was the difference again?
Reality check here. Copyright applies to patterns of information. ALL patterns of information can be digitized and copied at (practically) zero cost.
The real difference here is that the book publishers' war to outlaw libraries, used bookstores, and reselling was lost centuries ago. Nobody will even take them seriously if they try to put that genie back in the bottle.
Meanwhile, the RIAA/MPAA/BSA etc. still think they can win and create a world where they control all sales and uses of their products, and thus can have absolute control over pricing. If they beat the "new, digital era" drum loudly enough, they think they can get new laws rammed through guaranteeing their profit margins forever.
Sadly, it looks like the governments of the world may actually be so stupid as to let them.
Games and 3D make heavy use of FPU, but it's interesting to note that as time goes on, more and more of the heavy lifting FP work is being offloaded to the graphics processor.
Given a few more generations, most of the FPU work in todays games may actually be executed in the GPU.
Of course, this doesn't actually change anything, since tomorrow's games will just put that much more load on the CPU for physics processing and such!
Video codecs are essentially all integer based. Audio codecs often use the FPU, but they really don't need to - fixed point implementations tend to be just as fast.
The vast bulk of image editing work tends to be integer-based, or easily convertible to integer-based.
Spreadsheet math calculations aren't really performance-related in any sense. 99.9% (remember, your statistics may be made up on the spot, but mine are based on sound scientific handwaving!) of the time a spreadsheet spends is in fiddling with the GUI, which is primarily an integer operation activity.
That said, the parent poster's point sort of goes both ways. It's true that the FPU unit is heavily underutilized by most things outside of games, so it's not an unreasonable idea to strip it out and let the FPU be emulated in software or microcode or whatnot.
However, that won't necessarily really help. Modern CPU cores are better able to manage their power routing than previous ones, so having an FPU on there doesn't necessarily cause any trouble. The CPU may be able to disconnect power to the FPU when it's not in use, thus making the whole thermal issue something of a moot point in this respect. If it doesn't generate heat, it's just a matter of wasted silicon - and silicon's becoming quite cheap!
In fact, the FPU is an example of good design in CPU's, really. It's not too hard to fit a lot of computation units on one CPU core these days, hence having multiple ALU and FPU computation units being driven by complicated pipelining and SIMD engines. The difficulty is making efficient use of them - note the trouble getting SMP to work efficiently, and the whole idea of hyperthreading. While the FPU may get fairly low utilization, it is fantastically faster at floating point computation than the integer cores are, and putting a couple on a chip is thus generally a pretty good idea.
The main thing that's hard to grasp with the GPL is total control of the software. Big companies don't like that. :-)
I thought that was your last post on the subject? Anyway... Let me get this straight. Your sound fails because the OS chooses to ignore an interrupt raised by the hardware for hundreds of milliseconds, and you blame... the hardware? Or what? "The kernel didn't have time to respond..." vs. "this [...] isn't an indication that [the kernel] was [...] late." Huh?
The interrupt was raised. The kernel was late! What are you talking about?! By definition, it's the kernel's fault! Unless you're trying to claim that the bridge didn't deliver the interrupt when the kernel had it enabled. In the case of some hardware problems like a card squatting in bus-mastering mode, the kernel can do nothing. This is not one of them. We're talking about it failing to service an interrupt for probably a few hundred milliseconds! Clearly, the kernel's top-half interrupt handlers are running much too slow if that's the case. Much more likely, the kernel received the interrupt, put it in a list, and then simply did something else for half a second. Which is exactly what I stated above: it went and watered the flowers for a long time instead of responding.
This is just silly. I never claimed NT lacked a functioning scheduler (though how good it is is certainly open to question - the OS does not, for instance, handle priority inversion properly - but then few do). I claimed that setting a thread as realtime priority in no way means it will actually work properly at servicing a realtime task. And that's true, it won't. NT is not an RTOS, and the fact that you're hearing it fall over driving your sound card sometimes proves that. Why are we arguing here?
But they don't play perfectly fine. They play marginally fine - they still jitter and jump a lot, especially if your computer has anything else going on.
You're misunderstanding the concept of real-time software here. The OS cannot make realtime guarantees beyond what the hardware is capable of, so if you, say, have some brain-damaged hardware that goes into bus-mastering mode for long periods of time, your system is simply not going to work. You have a problem which cannot be solved in software. That's not what an RTOS is about.
The idea of an RTOS is that, within the domain of software, the RTOS provides facilities for software to make latency guarantees. So, if I have an OS which behaves as an RTOS of some sort (either "soft" meaning "very good" or "hard" meaning "without fail ever") and I have hardware which is compatible with the RT idea, I should be able to write software that works properly. Even under load, it should work properly. I should be able to do multiple kernel compiles at once and have perfect jitter-free non-skipping movie playback on an RTOS. Of course, I might need a dedicated disk to provide the movie I/O, but...
What this means is that the kernel is never going to just go off into the weeds for a while doing its own thing when I need the CPU, and it's never going to give the CPU to some undeserving process when I need it, basically.
NT is not an RTOS. Even if you do everything right, the kernel can, and will, just go off into the weeds sometimes. You might do a system call, and it decides to go balance its checkbook or something before getting back to you. It might take an interrupt and decide to go water the flowers before it bothers to mention that you have something to worry about.
Don't get me wrong, that's not really unexpected. Media playback is fairly new in desktop computers, so everyone's been lagging a bit in terms of making systems that are capable of doing it properly. Linux has the same problem out of the box.
Just don't kid yourself thinking that the OS is something it's not, or that all your problems are due to hardware. More likely than not, your problems are due to software. Certainly for bulk audio playback tasks like mp3, there's just no reason it shuld be skipping and dropping out other than a software problem. (If there was a bus-mastering sort of PCI problem, you'd probably hear it as some sort of high-frequency stuttering when you pressure the video card or whatnot, not skips and dropouts).
Yes, it is a design or implementation flaw when your OS fails to play mp3's properly. It's arguable that it may rather be user error because you went and tried to do a realtime media task on an OS that wasn't really designed for that, but the reason it's not working it almost certainly because the software isn't doing what you need it to. NT simply was not designed to be an RTOS.
So long.
Well, in reality, it'll probably drop something once in a while. If you don't mind that, then no, it doesn't matter at all.
RT performance is a lot more important for playing video, since it involves events that need servicing at a much higher frequency. Since people are starting to want to use their computers to drive their TV's a lot more these days, this is a serious issue (unless they don't mind the video being slightly nauseating every time it stutters through a pan, etc.)
You said it was designed for media. That implies it can make at least soft realtime guarantees, or it'll never be able to play audio/video properly.
It doesn't. Look at video players under Windows. They demonstrably don't play audio/video properly - the video players jitter all over the place. MP3 players most certainly do skip as well.
RT is about responding to an event within a certain deadline. Your sound card generates events (specifically, it generates interrupts signalling that the buffer needs filling). Your OS+application must respond to that event before the buffer runs dry, or your audio will skip. It's as simple as that.
RT priority simply means the application is at a strictly higher priority than other applications. It can relinquish its time slice implicitly by doing any number of things, particularly any form of disk I/O (including touching a page that was swapped out, etc.) The application will also be interrupted by the kernel, which as it's not an RTOS, may take any amount of time to do whatever it feels like.
The sound card has a fairly small buffer. The application is required to refill that buffer before it goes dry. So, say when the sound card raises an interrupt, "Give me more data", the OS and ultimately the application has a certain number of milliseconds during which it must provide the data, or the sound card will run dry and an audible skip will occur.
So, yes, it is a realtime issue.
For an mp3 player, the time during which the app must respond is relatively long in computer terms - maybe a few hundred milliseconds. That's on the order of a couple time slices, so the scheduler can (and will, eg. if your X server is running at high priority) definitely cause you to break. More likely, your app will be blocked on something else like disk IO, which can be much longer than that, and thus be unable to service the sound card in time.
Hence the reason the app must be written to make use of RT facilities if you want it to not skip. Along with the IO problem to read the file, the app also has to deal with the possibility that it might be paged out, and thus experience IO latency when it does anything at all. To really work right, it thus needs to disable paging for itself, run at realtime priority, and have some sort of shared memory ring buffer with another thread/process doing disk IO to buffer the IO latency. And that's just for something really simple like an mp3 player!