I don't know much about avionics, but lottery scheduling sounds a bit too probabilistic to simulate or make any guarantees about deadlines. Lottery scheduling solves the problem of starvation, but priority in that system means more CPU time.
In most control systems, you can pretty much determine how long it will take to run a job. They rarely feature complicated maths or recursions that might make prediction difficult, so giving a job more CPU than it needs won't do much but waste time and power. Instead they go for rate-montonic or least slack time first, since the execution times are known and priorities between jobs can be established i.e., brake actuation is more important than say failure logging).
sound like a cheap wad (which maybe I am), but the demo of the game is for me as the consumer to determine if I want to buy a game .
There's certainly a cheapwad in the room and I don't think it's you. A demo is advertising for a product. By charging your customers to sell them something else, they've earned the title cheapwad.
And at 2.50, plenty of people are making a profit off of the demo itself. This is essentially an attempt by publishers to cash in on AAA status titles before they've truly hit the shelves, and isn't the first time. The trouble with AAA games is that they take a damn long time to make, meaning they take a long time to go from spending money to making money. Metal Gear Solid 2 had a demo released around six months before the game actually shipped. In an attempt to shorten the time from spending to making money, they packaged the demo with an otherwise weak game, "Zone of Enders". Sold like gangbusters simply on the market demand for that demo. I shouldn't have to mention how upset people were at how different the demo was from the game released six months later. (gameplay-wise, it was fine, but the setting and characters radically changed, which upset many longstanding fans of the series).
I believe, if you want to sell demos, make shorter games and sell them instead. 50 dollars or 2.50, it's the principle that matters here -- everyone knows its not about finding new customers.
I'm not sure that applications are a valid measurement of demand, at least as an absolute measure. For example, major students in the US already have 3-10 applications in available schools. Your implicit assumption that there should be a 1 to 1 correspondence between admissions and applications seems invalid.
Probably because you don't read about the other 97 percent of LKML traffic that isn't highly contested. Even I don't, and most people use filters to limit exposure to things they perceive as relevant.
[SPOILER]The good game costs more.[/SPOILER] I wonder. A Link to the Past was a great game, and can be had incredibly cheaply, because a shit ton were made. Price has two components, after all, named "supply" and "demand."
No offense, but I saw the Wii coming. I underestimated the speed at which it caught on, but I knew that it would be the best console to own this generation.
Would you like a cookie? Everyone seems to think that picking the right console means they win. Seriously, what's with people's efforts to vindicate their choices after the fact? Shouldn't what matters now be whether you're satisfied with the kinds of experiences you get via the console?
I think the thing to learn here is that you shouldn't care about what other people think about your choices -- it's the only true geek way.
What about Seirei no Moribito or Bokurano or Darker than BLACK? Or Claymore? Or Death Note (which just ended). Baccano! looks neat, and starts next week. Maybe your taste in shows just sucks?
This is a question I ask undergraduate students in Operating Systems: how does replacing disk for a RAM disk affect disk scheduling algorithms? The short answer is: FIFO is fastest. It's fast to calculate, and seek times don't matter anymore. As a bonus, it's also fair. The same applies for CF disks.
To the extent that filesystems themselves organize in favor of shorter seek times, it's inconsequential. Calculating where to place 16 kilobytes is a drop in the bucked compared to the time to actually write those bytes. In Windows, FAT32 is commonly used. Unlike NTFS, it doesn't seem to reorganize on the fly, making it suitable for media that a user might pull out. In the past, there's been concerns about wear leveling. Unlike traditional RAM, flash seems to expire after so many write cycles. I know of one file system called jffs2 that addresses this, by attempting to keep writes level. Some people claim it's not nessecary with certain devices anymore, but I don't know how much I trust their simple analysis. I've been told that devices like CF or SD have built in wear leveling translation techniques, but I haven't read about or worked with these devices personally.
It's KU, not Ivy league we're talking about. You don't need to be a weathly donor to get your kid into KU. In fact, if your kid can't get into KU you should probably be worried about whether they'll live to the age of 25.
50 percent tax on earnings? It's pretty obvious you're not claiming some "kickbacks." Mortgage interest is tax deductible, you know. If you filed with an accountant, you should think about a second opinion;)
Or possibly, you live in California / other high income tax percentage while he lives in Nevada (no income tax).
I'd read this as "talented techies hate dealing with nontechnical problems, and find contracting a great way to maximize the amount of work spent in this area." (It's not hard to interpret the PS this way) Essentially, companies need to suck it up and figure out how to use contractors, rather than continue pointing at protecting company IP. Open source projects already survive while giving away lots of technical work / IP, and plenty of those who've wanted to found a way to profit.
Companies aren't out of qualified people; they're out of qualified people willing to put up with their idiocy on a long term basis.
This is why our stock market driven economy is so messed up. Gee, they didn't make super numbers this quarter because they were building for the future....
If you really think that Wall Street is punishing companies that "invest in the future", then why not buy up these stocks when they get hit after reporting earnings, and collect as their investments pay off and the company goes up in value? If you're right, you could retire early!
Has free trade discourse in America become so infrequent that nobody remembers the door swings two ways? I don't recall it being terribly easy to obtain a job in India as an American. Why should trade barriers be removed without quid-pro-quo?
In other words, if you take a random number generator and subtract 0x10000000 from every result, the new results are still random. Or flip the bits entirely. Essentially, I think as long as you have a mechanism with a 50 50 chance of producing a 1 or 0, you can create whatever range you like. I'm not entirely sure if exponentiating two random numbers is random, as the resulting distribution doesn't pass a "4am in the morning gut check".
There's several Linux distributions, but relatively few offer themselves as legitimate "alternatives to Windows". Certainly, I wouldn't describe Gentoo as "like Windows, but Free". Many distributions are solving fundamentally different problems than what Windows is sold for. KNOPPIX doesn't strike me as a replacement for Windows, although it is highly popular. Some are better considered OSX alternatives, as they're intended for PPC platforms.
Not that there aren't several distributions pining for Windows converts, but many are little more than venues to demonstrate some piece of software, or built to satisfy some narrow need, be it wireless router or multimedia studio. They serve their purpose adequately and there's no reason to believe that that they distract from the much smaller set of world class desktop Linux offerings. The number of distributions is a function of the flexibility of their design (ie dpkg isn't perfect for embedded systems with the cross compiling and all), and their willingness to integrate diverse communities. Personally, I'm beginning to think that Ubuntu may put an end to this discussion over the next few years. dpkg's limitations are not insurmountable, and they've done a much better job of attracting and integrating projects, unlike Debian's explicit efforts to distance itself from KNOPPIX etc. But don't mistake this for a prediction that they'll somehow put an end to hobbyist distros ("I want to do this because I can") or the motivation to fork-for-profit (Ulteo?).
And this is what happens when you miss a / in HTML at 2 in the morning. It's too bad/. doesn't have some better form of markup editing or live preview.
BTW, I have doubts about the.net/c# guy you know. Most people who could maintain Mosix would not tolerate such work. They'd look down on it like a typical C++ developer looks down on HTML or Visual Basic development.
Most people who could maintain this have chosen not to, but unqualified "I could do this and I know several people who could" claims should be disregarded. I know a guy who rewrote the TCP/IP stack to openMosix for his Master's thesis, and while I think he's a bright person, I don't think he's qualified to maintain openMosix. The big thing is kernel developers what truly look down on is maintaining a 2.4 branch of the kernel as an official stable release. What you're getting into when you maintain openMosix isn't just complicated cluster software, it's a set of inelegant patches with the additional complexity of cluster computing atomicity, that aren't even SMP safe! These aren't reasons for not caring, but rather reasons for actively disliking.
openMosix was doomed to fail like this at some point. Countless academic projects attempt to improve Linux for their specific needs in the wrong way. They release their work as patches never intended to merge with the kernel, or fork the kernel and never merge again. Over time you can guess what happens -- it becomes impossible to cope with the rate of change that others force on you, and the grant budget never considered ongoing maintenance costs, so the the patches become worthless, or the kernel fork unmaintained. So now Moshe is in deep, and nobody else wants to touch it.
What if Linus, or any other lead developer of an open source project, simply stopped supporting it. This person wont let anyone else take the job, and owns the project and the name. Under these circumstances it is clearly OK to fork. I dont believe you can draw some arbitrary line and say, past here, its not OK (ethically, not leagally) to fork a project. Again, read ESR's Cathedral papers. The right to fork is like the 2nd amendment. Important to protect, but should be exercised with great caution and determination. If leadership deviates from the community standards and ethical behaviors, and refuses to oblige, the right to fork ensures that new leaders can take the place, ones who do understand the need for community participation. X.org for example, forked when it became clear the leadership was not interested in the pace of development and patch acceptance others were in.
Besides, if the licenses are the same between the forks they can still share code and if the new fork gathers more momentum than the original and the original dies off, well, thats just survival of the fittest and the community has made their choice. This doesn't always happen. And the longer such a situation is held out, the worse it gets. In fact, I'd dare say more often neither side dies off. As time progresses, "momentum" favors neither side. Patches between networks of people cannot be shared and slowly the code becomes unmergable.
What I really personally hate, is when forking is done because you don't want to keep up with upstream. I've seen it done with the Linux kernel in various systems, and with TinyOS. They decide "we're going to stick with this stable code base". In these cases, you have little clue which security patches matter, and which bug fixes have been backported. This is the essential crime as percieved by open source developers. Look at Debian and Ubuntu. There's still an amount of friction between them and notice two things. A) some amount of ire is directed at them for taking their work and successfully marginalizing them B) another amount is justified by their habits about pushing patches upstream. There's also some amount of people simply upset that they weren't chosen to be hired by Canonical. At any rate, refusing to share code between to similar and historically related projects is silly. We wind up in situations where it seems that large important vendors were not consulted during a major 2.0 revision, because in part, they're not interested. This is somewhat silly because the vendors are the only ones making hardware TinyOS runs on.
Anyone can fork a GPL2 project, there is nothing morally wrong with me taking linux (which I have never contributed to) and starting my own fork of that project that does something different. Ethics is a tricky thing; while not on the level of eating babies, forking is cosidered ethically wrong in many cases. It leads to a duplication of effort, confuses users and discourages cooperation and open communication between developers. ESR, in one of his saner moments, wrote about this, and if I remember correctly, also about the difference between branching and forking. At best, you can say that there's nothing illegal with forking the linux kernel, or maybe that you personally don't see it as morally wrong. If at all possible, you should seek to have your changes integrated.
As I alluded to earlier, branching is a subtle subject. The linux kernel development method has slowly evolved into effectively a set of branches that trade patches back and forth, supported by a custom tool called git. There is not a single development branch, but several concurrent ones. Effectively, people already do maintain a collaborative branch. Linus may make decisions people don't like, such as refusing a patch because he'd rather see a patch removing the whole brain-dead driver. But that won't stop Dave Jones from picking up the patch, or from future contributions from the same guy from making inroads (did Con Kolivas quit or not?).
This is not common in Open Source methods. Partly because very few projects are wide enough in scope, and partly because few projects are mature enough in design that you could easily trade patches like that.
Slashdot Mirror
An old joke, but truth is duplicating the bug just might help solve the problem.
I don't know much about avionics, but lottery scheduling sounds a bit too probabilistic to simulate or make any guarantees about deadlines. Lottery scheduling solves the problem of starvation, but priority in that system means more CPU time.
In most control systems, you can pretty much determine how long it will take to run a job. They rarely feature complicated maths or recursions that might make prediction difficult, so giving a job more CPU than it needs won't do much but waste time and power. Instead they go for rate-montonic or least slack time first, since the execution times are known and priorities between jobs can be established i.e., brake actuation is more important than say failure logging).
There's certainly a cheapwad in the room and I don't think it's you. A demo is advertising for a product. By charging your customers to sell them something else, they've earned the title cheapwad.
And at 2.50, plenty of people are making a profit off of the demo itself. This is essentially an attempt by publishers to cash in on AAA status titles before they've truly hit the shelves, and isn't the first time. The trouble with AAA games is that they take a damn long time to make, meaning they take a long time to go from spending money to making money. Metal Gear Solid 2 had a demo released around six months before the game actually shipped. In an attempt to shorten the time from spending to making money, they packaged the demo with an otherwise weak game, "Zone of Enders". Sold like gangbusters simply on the market demand for that demo. I shouldn't have to mention how upset people were at how different the demo was from the game released six months later. (gameplay-wise, it was fine, but the setting and characters radically changed, which upset many longstanding fans of the series).
I believe, if you want to sell demos, make shorter games and sell them instead. 50 dollars or 2.50, it's the principle that matters here -- everyone knows its not about finding new customers.
I'm not sure that applications are a valid measurement of demand, at least as an absolute measure. For example, major students in the US already have 3-10 applications in available schools. Your implicit assumption that there should be a 1 to 1 correspondence between admissions and applications seems invalid.
Probably because you don't read about the other 97 percent of LKML traffic that isn't highly contested. Even I don't, and most people use filters to limit exposure to things they perceive as relevant.
Plus, whenever my advisor asks when my thesis draft will be ready, I'll have a nice standard to fall back to for guidance!
No offense, but I saw the Wii coming. I underestimated the speed at which it caught on, but I knew that it would be the best console to own this generation.
Would you like a cookie? Everyone seems to think that picking the right console means they win. Seriously, what's with people's efforts to vindicate their choices after the fact? Shouldn't what matters now be whether you're satisfied with the kinds of experiences you get via the console?
I think the thing to learn here is that you shouldn't care about what other people think about your choices -- it's the only true geek way.
What about Seirei no Moribito or Bokurano or Darker than BLACK? Or Claymore? Or Death Note (which just ended).
Baccano! looks neat, and starts next week. Maybe your taste in shows just sucks?
This is a question I ask undergraduate students in Operating Systems: how does replacing disk for a RAM disk affect disk scheduling algorithms? The short answer is: FIFO is fastest. It's fast to calculate, and seek times don't matter anymore. As a bonus, it's also fair. The same applies for CF disks.
To the extent that filesystems themselves organize in favor of shorter seek times, it's inconsequential. Calculating where to place 16 kilobytes is a drop in the bucked compared to the time to actually write those bytes. In Windows, FAT32 is commonly used. Unlike NTFS, it doesn't seem to reorganize on the fly, making it suitable for media that a user might pull out. In the past, there's been concerns about wear leveling. Unlike traditional RAM, flash seems to expire after so many write cycles. I know of one file system called jffs2 that addresses this, by attempting to keep writes level. Some people claim it's not nessecary with certain devices anymore, but I don't know how much I trust their simple analysis. I've been told that devices like CF or SD have built in wear leveling translation techniques, but I haven't read about or worked with these devices personally.
It's KU, not Ivy league we're talking about. You don't need to be a weathly donor to get your kid into KU. In fact, if your kid can't get into KU you should probably be worried about whether they'll live to the age of 25.
50 percent tax on earnings? It's pretty obvious you're not claiming some "kickbacks." Mortgage interest is tax deductible, you know. If you filed with an accountant, you should think about a second opinion ;)
Or possibly, you live in California / other high income tax percentage while he lives in Nevada (no income tax).
I'd read this as "talented techies hate dealing with nontechnical problems, and find contracting a great way to maximize the amount of work spent in this area." (It's not hard to interpret the PS this way) Essentially, companies need to suck it up and figure out how to use contractors, rather than continue pointing at protecting company IP. Open source projects already survive while giving away lots of technical work / IP, and plenty of those who've wanted to found a way to profit.
Companies aren't out of qualified people; they're out of qualified people willing to put up with their idiocy on a long term basis.
They also have a significant amount of software behind pricing adwords, you know...
This is why our stock market driven economy is so messed up. Gee, they didn't make super numbers this quarter because they were building for the future....
If you really think that Wall Street is punishing companies that "invest in the future", then why not buy up these stocks when they get hit after reporting earnings, and collect as their investments pay off and the company goes up in value? If you're right, you could retire early!
Has free trade discourse in America become so infrequent that nobody remembers the door swings two ways? I don't recall it being terribly easy to obtain a job in India as an American. Why should trade barriers be removed without quid-pro-quo?
Which violates the princple put forth earlier in the conversation. I thought it sounded a bit bogus, but who am I to argue with definitions?
In other words, if you take a random number generator and subtract 0x10000000 from every result, the new results are still random. Or flip the bits entirely. Essentially, I think as long as you have a mechanism with a 50 50 chance of producing a 1 or 0, you can create whatever range you like. I'm not entirely sure if exponentiating two random numbers is random, as the resulting distribution doesn't pass a "4am in the morning gut check".
There's several Linux distributions, but relatively few offer themselves as legitimate "alternatives to Windows". Certainly, I wouldn't describe Gentoo as "like Windows, but Free". Many distributions are solving fundamentally different problems than what Windows is sold for. KNOPPIX doesn't strike me as a replacement for Windows, although it is highly popular. Some are better considered OSX alternatives, as they're intended for PPC platforms.
Not that there aren't several distributions pining for Windows converts, but many are little more than venues to demonstrate some piece of software, or built to satisfy some narrow need, be it wireless router or multimedia studio. They serve their purpose adequately and there's no reason to believe that that they distract from the much smaller set of world class desktop Linux offerings. The number of distributions is a function of the flexibility of their design (ie dpkg isn't perfect for embedded systems with the cross compiling and all), and their willingness to integrate diverse communities. Personally, I'm beginning to think that Ubuntu may put an end to this discussion over the next few years. dpkg's limitations are not insurmountable, and they've done a much better job of attracting and integrating projects, unlike Debian's explicit efforts to distance itself from KNOPPIX etc. But don't mistake this for a prediction that they'll somehow put an end to hobbyist distros ("I want to do this because I can") or the motivation to fork-for-profit (Ulteo?).
And this is what happens when you miss a / in HTML at 2 in the morning. It's too bad /. doesn't have some better form of markup editing or live preview.
openMosix was doomed to fail like this at some point. Countless academic projects attempt to improve Linux for their specific needs in the wrong way. They release their work as patches never intended to merge with the kernel, or fork the kernel and never merge again. Over time you can guess what happens -- it becomes impossible to cope with the rate of change that others force on you, and the grant budget never considered ongoing maintenance costs, so the the patches become worthless, or the kernel fork unmaintained. So now Moshe is in deep, and nobody else wants to touch it.
Out of curiousity, what makes you decide that the submitter is British, and not Candian, Indian, or some other nationality of European?
What if Linus, or any other lead developer of an open source project, simply stopped supporting it. This person wont let anyone else take the job, and owns the project and the name. Under these circumstances it is clearly OK to fork. I dont believe you can draw some arbitrary line and say, past here, its not OK (ethically, not leagally) to fork a project.
Again, read ESR's Cathedral papers. The right to fork is like the 2nd amendment. Important to protect, but should be exercised with great caution and determination. If leadership deviates from the community standards and ethical behaviors, and refuses to oblige, the right to fork ensures that new leaders can take the place, ones who do understand the need for community participation. X.org for example, forked when it became clear the leadership was not interested in the pace of development and patch acceptance others were in.
Besides, if the licenses are the same between the forks they can still share code and if the new fork gathers more momentum than the original and the original dies off, well, thats just survival of the fittest and the community has made their choice.
This doesn't always happen. And the longer such a situation is held out, the worse it gets. In fact, I'd dare say more often neither side dies off. As time progresses, "momentum" favors neither side. Patches between networks of people cannot be shared and slowly the code becomes unmergable.
What I really personally hate, is when forking is done because you don't want to keep up with upstream. I've seen it done with the Linux kernel in various systems, and with TinyOS. They decide "we're going to stick with this stable code base". In these cases, you have little clue which security patches matter, and which bug fixes have been backported. This is the essential crime as percieved by open source developers. Look at Debian and Ubuntu. There's still an amount of friction between them and notice two things. A) some amount of ire is directed at them for taking their work and successfully marginalizing them B) another amount is justified by their habits about pushing patches upstream. There's also some amount of people simply upset that they weren't chosen to be hired by Canonical. At any rate, refusing to share code between to similar and historically related projects is silly. We wind up in situations where it seems that large important vendors were not consulted during a major 2.0 revision, because in part, they're not interested. This is somewhat silly because the vendors are the only ones making hardware TinyOS runs on.
And reconcilation of their longstanding dispute with The Beatles.
As I alluded to earlier, branching is a subtle subject. The linux kernel development method has slowly evolved into effectively a set of branches that trade patches back and forth, supported by a custom tool called git. There is not a single development branch, but several concurrent ones. Effectively, people already do maintain a collaborative branch. Linus may make decisions people don't like, such as refusing a patch because he'd rather see a patch removing the whole brain-dead driver. But that won't stop Dave Jones from picking up the patch, or from future contributions from the same guy from making inroads (did Con Kolivas quit or not?).
This is not common in Open Source methods. Partly because very few projects are wide enough in scope, and partly because few projects are mature enough in design that you could easily trade patches like that.