Hey, if highly educated people want to stay here, I'm all for it.
Where did the idea start that America is just some vast smorgasbord of cool stuff that anyone can just take for themselves any time they please? Probably around the time the Statue of Liberty came along with the phrase "Give me your huddled masses, yearning to breathe free." Or maybe earlier, with the idea of the Beacon on the Hill, America being an example for other nations and peoples to follow.
For people it is twofold. The first is not knowing even how to go about it. You really think a non-technical user knows how to go about having software or features written? Hardly. This hardly only applies to open source software. How do you go about getting Microsoft or Apple to include your needs or fixes? You don't. You pick among the options they offer, and maybe offer feedback in beta testing (which few nontechnical types do). Closed source software is at the mercy of a single product market -- if you're lucky, the developer recognizes that a particular feature you want is among the highest demand features and works on it. They have limited ability to capture your additional benefit if it's a minority position, like OS scheduler hinting is. They can charge you twice as much for a deluxe version, but if the change represents a hundredfold benefit to a millionth of the userbase, they won't likely be persuaded to spend their time on it. But they certainly won't negotiate a special version for the prices you can afford. With open source software you can seek a contractor to do what you want.
I personally favor the idea of collective bounties. A motivated individual places a bid for some feature or bugfix, interested individuals can chip in as well, and claims can sought after by the scarce talent. We've already seen this in part with the nouveau drive and GNOME bounties. Canonical tried it in Launchpad, but I think severely underfunded the launch and certainly didn't put the kind of effort needed to create a healthy market for this. This collective bargaining approach can help direct developers towards high value targets, and I think you give it too little consideration.
So what about business? Well there the money is available, if it needs to be (at least for large enough businesses) and the knowledge should be as businesses should be able to research things they need. However there you run in to lack of reason. So let's say I need a package like this for my company. I decide to have one made and pay a lot of cash for it. I argue that in a lot of places, open source already has plentiful adoption. Websites adopt open source as a way to push fixes and improvements faster than vendors can do so. Huge regression in IIS performance on your queries? Well you can roll back or wait for the next release -- good luck getting your money back. The question of sharing is more complicated. If you think that the changes are a competitive edge, you have strong incentive not to release them back. However, there is a counter incentive here-- software is more than just your changes. By carrying a delta you're implicitly agreeing to maintain it locally, resolving merge conflicts along the way etc. Or you forswear upstream upgrades altogether. And at some point, you risk the chance someone else decides to publish a patch for this feature. At which point your hand is essentially forced.
I realize not all problems (ie lack of a good video editor) have speedy market responses. Entirely new products simply do have a long release cycle. But if the community can find 10k to put up for Open Source nvidia drivers, Imagine what something like a quality video editor system could drum up! Your argument about $500 ex post facto ignores what you're potentially getting for that investment: a static binary, with perhaps upgrade rights over a period of time, that at some point inevitably expire. In contrast, good open source licenses promote availability in perpetuity.
Yes, but if you have to pay someone to make the modifications you want done, and then pay them to maintain those modifications and to port them whenever something they interface with randomly changes, then you've got cost, probably quite substantial cost Yes. People, on a large scale, don't work for free. Especially talented ones capable of correctly implementing something like per-cpu scheduling hints. What you can do to minimize the cost is pay people to get it into upstream. Moreover, the source code availability in the first place vastly increases competition. It's much easier to patch linux than to design an operating system people want to run software on that also happens to provide scheduler tweaks you like. In the closed source system you're negotiating with a small set of people that have access, while the Linux kernel's open source gives you a much wider set of alternatives, driving down prices in effect. Try negotiating with Microsoft to add a feature you like. If it's possible at all, consider the price they'd likely charge.
Open source isn't necessarily priceless. Education, talent, and time are still scarce resources. Open source just provides hired hands a platform for their interests and spare time, and a shared base to work from. If you're in IT for cheap labor, I still encourage you to look to offshore.
I should point out that SGI has done exactly this: on behalf of their customers they go about fixing scalability problems in Linux. The results are quite interesting -- eight thousand CPU computers and the like. To give credit to the Evanglist, perhaps he was hoping coworkers and superiors at Intel would recognize the need and step up.
Either way is ok, there's nothing wrong with saying "We are all about DIY, if you aren't willing to do it, don't expect other people to), you just have to recognise that is a viewpoint inconsistent with "We believe this is something everyone could and should use." There's nothing necessarily incompatible with those viewpoints. The point isn't necessarily "write it yourself," but to take ownership of the need and get it done, perhaps by paying others. You can then go about writing to others and say "You should use this stuff, and we can help make it better for your needs." Its a silly belief that other people are going to fix your problem for free if you sit there wishing loud enough. Open source projects are truly successful not when you take responsibility for listening to what people want, but allowing the public to take ownership in the software that could address their needs.
Chroot is also used in building Debian packages. pbuilder sets up a seperate install to chroot into and ensure that build dependencies are correct by copying a base install, installing the build deps and attempting to build the package, eliminating some of those "works for me" FTBFS problems.
I doubt the same bug occurs, but does anyone evaluate how OO.org fares in math flaws? I suspect some people hold OO.org to a lower standard than one should otherwise expect.
Granted, the above bug looks like a rounding error gone horribly, horribly, incredibly horribly wrong.
Which is why the whole site is plastered with "Saving Power on Intel hardware". Because it's nonpartisan and definitely not aiming to portray Intel as the least power hungry vendor out there. Sure...
Were you using an external measurement or relying on the software to report it's own usage? For a truly comparable system one would want to use external measures (just ask Dave Jones).
Gutsy features a number of interesting problems. It seems the GNOME brightness feature doesn't dim the backlight, but rather fades the screen output closer to black. This energy saving method might work on CRTs. It works less well on LCDs. I noticed no immediate savings increasing or decreasing the brightness output, in direct contrast with previous versions. So even though the on-battery brightness daemon is super aggressive (30 second timeouts I think), it does no good. CPU usage is up overall, in part because of SABDFL's wish to make headlines shipping GL desktop by default.
But most of these "hints" are well known, but not enabled as they come with consequences. Wireless power output decreases range. Not polling the CD drive means you'll have to tell the computer when it's activated. I also suspect a number of these customizations aren't going to work well on hardware that isn't Intel -- try posting suggestions for nvidia chipsets and see how far you get. The best you can do is come up with a set of lightweight alternatives to the packages where these configurations matter, and let users and hardware vendors like Dell or System76 pick up the ones they like.
The neat thing about raytracing is that it's a highly parallel process. AA in raytracing means casing multiple rays per pixel, instead of just one. This lends itself to multi-chip / card rendering far better than traditional GPUs. Put two chips with access to the same scene and have em render half the pixels each isn't terrible. 4 is even better, and papers I've seen suggest a near linear relationship.
You know, someone has to say it: The Prime 3 controls are not perfect. They're somewhere between okay and not any better that the GC controls. Locking on for circle strafing is great, but it also re-centers the screen on the object of interest, without your cursor being re-aimed. So in a fast battle, you point at the man badguy, lock on to dodge and fight more effectively, but your aim is way off. There's a setting to fix this so that when you lock on, you're also aiming at the opponent. It's not very good at motion prediction though.
More importantly, the lack of turbo fire on the wiimote kills your thumb in ways NESmaniacs never imagined.
Near the end it becomes clear that one of them was relatively new, and never played Metal Gear before the 2d-3d transition. I"m not sure whether they're for or against MGS in 3d. Ghost Babel was a fantastic game that brought the most interesting parts from the 3d back to 2d, so I don't think it's clear-cut. But I think partly when you write for MTV maybe you don't want to use obscure references when a reference your entire audience would understand exists.
I like how since Sony or whoever told them to do it, it's now not Factor 5's fault. Instead they got an order on high to "make this game suck" and they followed through.
Picross DS's competitive online mode (don't ask) also penalizes disconnects. It's slightly unfortunate as the DS's wireless range is not all that good, but if the other option is losers disconnecting to avoid penalty I'm for it.
Finger print readers aren't all they sound. I was talking with Vint Cerf about it and his suggestion was that they're only okay as part of authentication, instead of the entirety. Ie, you'd still need a password. His reasoning was that if you needed to revoke a fingerprint, you can only do that ten times before you're out of luck. I'm not certain why you'd want to revoke a fingerprint (if you've got a demonstrated leak, I can't see the purpose of switching fingers).
My laptop came with a fingerprint reader, and I've got a few other things to say on it: * Your fingerprints change. Warts, scars, and the like can cause false rejection, locking you out of your system. And god forbid you lose a finger. * The laptop likely has the authentication matter smeared all over it, on the lid, on the LCD screen, etc. If they just swipe your bag, there's even more sources for prints. If you keep one of those mirror / powder makeup things (pardon my lack of knowledge in the matter), it's even more likely. Granted, it's not easy to duplicate * You can't use a fingerprint scan as an encryption key. They don't emit the fingerprint scanned (generally) and scanners are noisy, and designed to reject or accept against a known print within some likelihood of failure. This means you'll have to store the encryption key on disk, or use a password. * US export restrictions have caused designs to generally favor hardware implementation over software (it's easier to control export of hardware than software!). This is great for stuff like open source, because the algorithms for comparison are in hardware, all the software can do is pass it off to the hardware and get a result. There's likely some extra implications here I haven't yet thought of.
As far as I'm concerned, fingerprints are a matter of convenience than security. It's pretty clear for the data paranoid you need a password anyways, if only to prevent complete lockout from users, and stop probabilistic attacks.
I can give you a traditional undergraduate OS class answer, but it doesn't directly apply to the linux kernel without a lot of source code analysis and math: timeslicing. If you've got five processes ready to run, and 1 CPU, you have to schedule those 5 somehow. On today's desktops, you want to make it appear as if they're all running at once, so you give each program a small unit of time on CPU, and cycle through them in rapid succession. The trouble is, time taken switching processes is time not spent doing user calculations. The longer the time slice is, the less time spent every second on switching instead of calculating, at the expense of latency. So we've established a tradeoff between latency and throughput. Generally, "big-iron" users prefer throughput over latency. If they want five concurrent processes, they'll get a 5 CPU server, etc.
Remember, that this is an example, rather than something I"m pushing as the problem with the Linux kernel today. I've heard the current scheduler is an improvement in nearly all scenarios over the old O(1) scheduler. But during the early 2.6 development (it might have been 2.5 even) I recall reading developers testing X smoothness with cpu intensive kernel builds in the background. They were attempting to test how well the kernel handled latency under high loads, and were coming up with some goofy tricks to pass sleeping processes more time to their children and such. This has been more formalized with the CFS and SD and friends.
Then what does this mean for the IO scheduler, which has exactly that structure? There's a choice from a couple of I/O schedulers at build time, such as FIFO for embedded systems that want to reduce kernel memory demands, and predictive for desktops with plenty of memory and relatively slow disk.
A well designed kernel can have modular tools that are relatively loosely connected. The scheduler is in charge of picking who's next on CPU(s). This isn't thermonuclear warfare -- the only thing that strikes me as immediately able to break things is an assumption about what's running concurrently. I dare say anything that breaks as a result was already broken without the ifdef.
Slashdot Mirror
I personally favor the idea of collective bounties. A motivated individual places a bid for some feature or bugfix, interested individuals can chip in as well, and claims can sought after by the scarce talent. We've already seen this in part with the nouveau drive and GNOME bounties. Canonical tried it in Launchpad, but I think severely underfunded the launch and certainly didn't put the kind of effort needed to create a healthy market for this. This collective bargaining approach can help direct developers towards high value targets, and I think you give it too little consideration. So what about business? Well there the money is available, if it needs to be (at least for large enough businesses) and the knowledge should be as businesses should be able to research things they need. However there you run in to lack of reason. So let's say I need a package like this for my company. I decide to have one made and pay a lot of cash for it. I argue that in a lot of places, open source already has plentiful adoption. Websites adopt open source as a way to push fixes and improvements faster than vendors can do so. Huge regression in IIS performance on your queries? Well you can roll back or wait for the next release -- good luck getting your money back. The question of sharing is more complicated. If you think that the changes are a competitive edge, you have strong incentive not to release them back. However, there is a counter incentive here-- software is more than just your changes. By carrying a delta you're implicitly agreeing to maintain it locally, resolving merge conflicts along the way etc. Or you forswear upstream upgrades altogether. And at some point, you risk the chance someone else decides to publish a patch for this feature. At which point your hand is essentially forced.
I realize not all problems (ie lack of a good video editor) have speedy market responses. Entirely new products simply do have a long release cycle. But if the community can find 10k to put up for Open Source nvidia drivers, Imagine what something like a quality video editor system could drum up! Your argument about $500 ex post facto ignores what you're potentially getting for that investment: a static binary, with perhaps upgrade rights over a period of time, that at some point inevitably expire. In contrast, good open source licenses promote availability in perpetuity.
Open source isn't necessarily priceless. Education, talent, and time are still scarce resources. Open source just provides hired hands a platform for their interests and spare time, and a shared base to work from. If you're in IT for cheap labor, I still encourage you to look to offshore.
Clearly, you expect too much from someone who's job title includes the word "Evangelist".
I should point out that SGI has done exactly this: on behalf of their customers they go about fixing scalability problems in Linux. The results are quite interesting -- eight thousand CPU computers and the like. To give credit to the Evanglist, perhaps he was hoping coworkers and superiors at Intel would recognize the need and step up.
So randomize the ballot. Your awesome computer skills can do this, no?
Chroot is also used in building Debian packages. pbuilder sets up a seperate install to chroot into and ensure that build dependencies are correct by copying a base install, installing the build deps and attempting to build the package, eliminating some of those "works for me" FTBFS problems.
Even for-profit companies have a line item that says "Goodwill" on the budget.
I doubt the same bug occurs, but does anyone evaluate how OO.org fares in math flaws? I suspect some people hold OO.org to a lower standard than one should otherwise expect.
Granted, the above bug looks like a rounding error gone horribly, horribly, incredibly horribly wrong.
Good for you; take a stand against that kind of name-calling!
Which is why the whole site is plastered with "Saving Power on Intel hardware". Because it's nonpartisan and definitely not aiming to portray Intel as the least power hungry vendor out there. Sure...
Were you using an external measurement or relying on the software to report it's own usage? For a truly comparable system one would want to use external measures (just ask Dave Jones).
Gutsy features a number of interesting problems. It seems the GNOME brightness feature doesn't dim the backlight, but rather fades the screen output closer to black. This energy saving method might work on CRTs. It works less well on LCDs. I noticed no immediate savings increasing or decreasing the brightness output, in direct contrast with previous versions. So even though the on-battery brightness daemon is super aggressive (30 second timeouts I think), it does no good. CPU usage is up overall, in part because of SABDFL's wish to make headlines shipping GL desktop by default.
But most of these "hints" are well known, but not enabled as they come with consequences. Wireless power output decreases range. Not polling the CD drive means you'll have to tell the computer when it's activated. I also suspect a number of these customizations aren't going to work well on hardware that isn't Intel -- try posting suggestions for nvidia chipsets and see how far you get. The best you can do is come up with a set of lightweight alternatives to the packages where these configurations matter, and let users and hardware vendors like Dell or System76 pick up the ones they like.
The neat thing about raytracing is that it's a highly parallel process. AA in raytracing means casing multiple rays per pixel, instead of just one. This lends itself to multi-chip / card rendering far better than traditional GPUs. Put two chips with access to the same scene and have em render half the pixels each isn't terrible. 4 is even better, and papers I've seen suggest a near linear relationship.
You know, someone has to say it: The Prime 3 controls are not perfect. They're somewhere between okay and not any better that the GC controls. Locking on for circle strafing is great, but it also re-centers the screen on the object of interest, without your cursor being re-aimed. So in a fast battle, you point at the man badguy, lock on to dodge and fight more effectively, but your aim is way off. There's a setting to fix this so that when you lock on, you're also aiming at the opponent. It's not very good at motion prediction though.
More importantly, the lack of turbo fire on the wiimote kills your thumb in ways NESmaniacs never imagined.
Near the end it becomes clear that one of them was relatively new, and never played Metal Gear before the 2d-3d transition. I"m not sure whether they're for or against MGS in 3d. Ghost Babel was a fantastic game that brought the most interesting parts from the 3d back to 2d, so I don't think it's clear-cut. But I think partly when you write for MTV maybe you don't want to use obscure references when a reference your entire audience would understand exists.
I like how since Sony or whoever told them to do it, it's now not Factor 5's fault. Instead they got an order on high to "make this game suck" and they followed through.
Picross DS's competitive online mode (don't ask) also penalizes disconnects. It's slightly unfortunate as the DS's wireless range is not all that good, but if the other option is losers disconnecting to avoid penalty I'm for it.
I wasn't aware of any BIOS's that can drive a wireless card. Sounds impressive.
Well, I'm not about to advertise everyone laser etch STOLEN into their laptop lids.
Finger print readers aren't all they sound. I was talking with Vint Cerf about it and his suggestion was that they're only okay as part of authentication, instead of the entirety. Ie, you'd still need a password. His reasoning was that if you needed to revoke a fingerprint, you can only do that ten times before you're out of luck. I'm not certain why you'd want to revoke a fingerprint (if you've got a demonstrated leak, I can't see the purpose of switching fingers).
My laptop came with a fingerprint reader, and I've got a few other things to say on it:
* Your fingerprints change. Warts, scars, and the like can cause false rejection, locking you out of your system. And god forbid you lose a finger.
* The laptop likely has the authentication matter smeared all over it, on the lid, on the LCD screen, etc. If they just swipe your bag, there's even more sources for prints. If you keep one of those mirror / powder makeup things (pardon my lack of knowledge in the matter), it's even more likely. Granted, it's not easy to duplicate
* You can't use a fingerprint scan as an encryption key. They don't emit the fingerprint scanned (generally) and scanners are noisy, and designed to reject or accept against a known print within some likelihood of failure. This means you'll have to store the encryption key on disk, or use a password.
* US export restrictions have caused designs to generally favor hardware implementation over software (it's easier to control export of hardware than software!). This is great for stuff like open source, because the algorithms for comparison are in hardware, all the software can do is pass it off to the hardware and get a result. There's likely some extra implications here I haven't yet thought of.
As far as I'm concerned, fingerprints are a matter of convenience than security. It's pretty clear for the data paranoid you need a password anyways, if only to prevent complete lockout from users, and stop probabilistic attacks.
I can give you a traditional undergraduate OS class answer, but it doesn't directly apply to the linux kernel without a lot of source code analysis and math: timeslicing. If you've got five processes ready to run, and 1 CPU, you have to schedule those 5 somehow. On today's desktops, you want to make it appear as if they're all running at once, so you give each program a small unit of time on CPU, and cycle through them in rapid succession. The trouble is, time taken switching processes is time not spent doing user calculations. The longer the time slice is, the less time spent every second on switching instead of calculating, at the expense of latency. So we've established a tradeoff between latency and throughput. Generally, "big-iron" users prefer throughput over latency. If they want five concurrent processes, they'll get a 5 CPU server, etc.
Remember, that this is an example, rather than something I"m pushing as the problem with the Linux kernel today. I've heard the current scheduler is an improvement in nearly all scenarios over the old O(1) scheduler. But during the early 2.6 development (it might have been 2.5 even) I recall reading developers testing X smoothness with cpu intensive kernel builds in the background. They were attempting to test how well the kernel handled latency under high loads, and were coming up with some goofy tricks to pass sleeping processes more time to their children and such. This has been more formalized with the CFS and SD and friends.
Then what does this mean for the IO scheduler, which has exactly that structure? There's a choice from a couple of I/O schedulers at build time, such as FIFO for embedded systems that want to reduce kernel memory demands, and predictive for desktops with plenty of memory and relatively slow disk.
A well designed kernel can have modular tools that are relatively loosely connected. The scheduler is in charge of picking who's next on CPU(s). This isn't thermonuclear warfare -- the only thing that strikes me as immediately able to break things is an assumption about what's running concurrently. I dare say anything that breaks as a result was already broken without the ifdef.
What about tickless kernels?