71.6 PB/s is pretty impressive, but you only get that for 0.28s out of every 22,292s. I can just see the progress bar: stalled, stalled, stalled, 71.6 PB/s, 35.8PB/s, 23.8PB/s, 17.6PB/s, 14.3PB/s, stalled, stalled...
Peak bandwidth is good for records, but it's not all that useful if you can't maintain it.
But if you first use KDE without having sound set up, it will save the fact that everything's muted. If you then log in as root to set things up, set the volume and verify that it is working, and then log out as root and log back in as yourself, it will restore the muted sound settings.
Also, it at least used to be the case that, if you try to use Konqueror without otherwise using KDE, it will restore your volume settings at some unexpected moment.
Really, any patch that gets put into a kernel which gets distributed in binary form should modify the version string to indicate that it's there. I personally think the security fixes should never change the main version number, but should be distributed in the form of a patch (or a set of patches) that applies to every kernel version that had the issue and that adds something to the version string to indicate that it fixed it. Security fixes should be released already backported to previous versions, which both avoids the issue of what you do with current testing changes and also deals with issues of people who can't use the latest version.
OSRM does have a vested interest in the outcome, but it is in finding any problems and getting them fixed before they'd have to pay to defend them in court.
A TCO study is useful if the people who do it are offering to reimburse you any cost overruns.
Come now, nothing's perfect. Every once in a while, the universe will totally botch obeying natural law. Granted, it's incredibly unlikely that this will happen at a macroscopic scale, but...
I'd like to see an overseas IT worker check whether my network cable is plugged in securely. IT tends to involve solving a lot of problems which are due to hardware or are obvious if you look at the hardware.
Actually, Linux does support his sound hardware. He got it working with every distro he tried, and then muted it, and decided that this was somehow a driver issue. In fact, it's because there are a ton of ways your audio can get muted in Linux, from rebooting without a script to save the volume or set it at boot to running a program that has its own ideas of what your volume controls should be (Konqueror, IIRC, mutes everything if you go to a page with sound; the flash plugin mutes everything when it starts, etc).
Solution: get a volume control program for X, and leave it running at all times, thereby blocking other programs' attempts to control the volume.
The only problem I've had recently with audio is that some programs mess with the audio controls. For some reason web browsers seem to think that I shouldn't listen to CDs while I browse the web. The solution I've found is to have xmixer (built for OSS) running at all times. This blocks other programs' attempts to mess with it.
Sun doesn't make commodity processors, and they (at least in theory) have much better memory controllers already. Since it's a lot easier to improve the bandwidth on access to memory than the latency, it makes a lot of sense to uberthread their CPU, because they can move a lot of data in a single round-trip. If you have time to get 64 threads to their next cache misses in the time it takes to start getting data, and you can have 64 requests in flight at the same time, you're going to keep the processor 64 times as busy with a lot of threading than with a single thread per processor.
There are now multi-threaded garbage collectors which never pause. The GC runs in a separate thread tracking which objects have not been referenced recently and collecting ones which haven't been referenced during the time the whole heap was scanned (in much the same way that cache eviction algorithms work). It parallelizes nicely out of the program's normal operation (for the simple reason that things that are garbage aren't used by the program). On allocation, it can be made to work or fail immediately, if desired. With multiple threads, the allocating thread can block on garbage collection finding more space while other threads (which are not allocating anything) run unhindered.
Modern garbage collection is not really any slower than modern virtual memory with swap, and doesn't really make things any less predictable than swap does. It's not all that different, except that it determines memory that's especially stale, and discards it entirely.
An afternoon with Valgrind should track down most of these without too much effort. It's really gotten to be a nice "please tell me what's wrong with my program" tool, capable of letting you send in bug reports like "function X leaks a 20-byte chunk of memory and a 4-byte chunk every time I call it with these arguments." For now you can't determine things like "bytes 16-19 of the leaked chunk are a pointer to a filename", but I suspect that will be in a later version (determined by what system calls are called with it).
One thing I'd really like to see in Java is Object.free(), which would tell the garbage collector that the object is garbage and can be freed, and cause any further use of the object to throw a FreedMemoryException. This would be useful both as a hint to the system (letting it get rid of things the object references early) and as a debugging aid (so you can find cases where stuff remains in use after you don't think it will). Of course, it violates Java's sandbox design to have a C-style free() which recycles the address space.
I bet it would be a pretty quick glibc hack to support "a:" as a synonym for "/mnt/floppy", "d:" as a synonym for "/mnt/cdrom", and "c:" as a synonym for something else that makes the user happy, based on an environment variable. That's why we need a useability study: we need to know what things people will try, so we can make them work if possible, and make them easy to replace otherwise.
Windows on the other hand, you can go to the control panel and what you want to change will likely be in there somewhere, unless it's application specific, and you don't have to read any manuals or docs to figure out how to configure your system - it's intuitive.
I have to agree. With Windows you might be able to configure what you want to change if you can figure out where the heck it is, and the only way you'll figure it out is either instinct or by trying everything. With Linux, there's plenty of documentation on the web. What's more, people are talking about creating more useful documentation and putting it on the web.
I think that the total height of the learning curve matters at all. Most Linux gurus never learn all of the options to "ls". What matters more is how steep the climb to the first plateau is. If you can get the user to the point of having completed the first task of their choosing, there's a good chance that they're hooked, and will use your system despite it being very difficult to do anything further.
How difficult it is to set up Linux depends a lot on what you want to do. The shortest path to a bash prompt involves putting a Knoppix CD in the drive, turning on the computer, and clicking on the picture of the monitor. Everything is autodetected. (In fact, it took three experienced Linux users two days to get X working with Debian on a new Intel motherboard; Knoppix autodetected the right things and worked perfectly with no input)
On the other hand, Knoppix isn't what most Linux users thing of when they think of a Linux system. But it is much closer to what a Windows user would expect of an operating system. My complaints: too much disorganized junk in the menus, and the network doesn't get restarted automatically with the settings you had last time even if you've installed to the hard drive.
There doesn't seem to be any reason you couldn't enter a graphical game (so long as you don't enter a non-interactive one). You'd get fewer judges, probably, than one that was text-based, and there would probably be a bunch of discussion, but that doesn't mean you couldn't enter it. Of course, it would be judged against text, which is a much easier medium to be expressive in.
There is, in fact, a substantial discussion in the interactive fiction community about whether games should be "simulationist" or not; the simulationist camp would like the world of the story to actually function completely correctly, which the non-simulationist camp prefers only those parts which fit with the story to be implemented. Of course, randomness is only a possibility with a simulationist approach (although it is not frequently used for anything important).
There are examples of works which are definitely literary. In Photopia, for example, the ineractor cannot change the outcome of any of the scenes, but instead essentially delivers the lines of a series of characters. The interactor takes the part of an actor in a play, with the author as playwright. It functions like a book in that the plot is fixed and scripted, but the reader is not outside of the action, but is actually there choosing how characters' speeches are worded, and setting up the details of the experience. In fact, right at the beginning, you make a descision which is critical to what will happen, and the entire story hinges on making the wrong choice; you (as the character you play in that scene) would wish that you'd only been wiser. But, in fact, the game makes whichever choice you make be the wrong one, and the story does happen regardless. The interactivity doesn't actually let you make the right choice (and foil the author's attempt to have a story), but it make you (as the character) responsible for what happens. It wouldn't be an especially good static fiction story; it would be a paragraph in the newspaper at most. But as it is actually presented, the main character is your daughter, your classmate, your babysitter, because the game has put you in the shoes of a number of people with various relationships to her, and asked you to walk a mile.
Modern IF is really about getting a reader to make an emotional investment in the outcome of the story by playing a role in it rather than simply providing a world in which any story (or, more likely, no story of interest) can happen. The trick is to hide the author's control while making it constantly effective.
To use the computer analogy, it's like they took a computer and tried looking for where the cache is. After performing a bunch of graphics tests, they found that the cache is on the graphics card.
I suppose there is one thing here that people are not generally aware of: working memory (and long-term memory) is not distributed evenly throughout the brain, but is, rather, in the areas where the things you're remembering are processed.
Google is doing well with their search engine, and making a bunch of money. If they continue tweaking their algorithms as needed, they will continue to make this money, but there's not that much tweaking it can productively get at any particular point in time. This means that they have programmers (some of whom have unusual names) who they need to keep around, and to do that, they need to keep them interested and they need to keep paying them. I bet the entire point of Orkut, from Google's perspective, is that Orkut (the person) feels like doing it, and Google doesn't want him to quit. If it keeps the programmers happy, it's worthwhile. Oh, it might be good for business at some point.
Actually, getting VC is 90% knowing the right people. So Google's management went to the team and asked them if they knew anyone influential. The team said, "We don't know. Let's write a program to find out."
So I open the attachment. Hmm... the message didn't mention a program. Or the other person doesn't have a good reason to be sending programs to me. Better find out what this is all about before I run it.
The broken thing about Windows is that users have no way of knowing what will happen if they click on an attachment. Usually, they view the contents of the attached file. But sometimes it destroys their system instead. The expectation is that there will be no side effects of the operation; at most, they will be given the opportunity to save the file. But this assumption is violated by viruses which don't even use a security hole.
I don't think the Google is going to try the portal thing. After all, they're no less aware than we are that nobody else has made that work. In fact, they just made their search pages simpler.
On the other hand, that doesn't mean they can't have other features. I think they're likely to keep adding special things you can "search" for, like UPS packages and "(the speed of light / (440 nm)) in THz", since these don't make the interface any more complicated.
They also already have other pages available, like news.google.com (which indexes news sites in the form of a news site). As long as they keep the reputation of the brand good, and keep the search site focused and the results good, it doesn't matter how much they branch out. They seem to have the right attitude towards advertizers: provide ads primarily to people who are actually searching for products, not to people who are looking for content. They can probably extend their offerings as competently and respectfully of their audience. And they might as well; they've already got the best search engine team out there, and they've got money to expand, so new things they try will use new employee effort, and not detract from the search engine.
Or, in JDK 1.5, a typesafe enum. Perhaps it ought to also support Strings, but I think enums satisfy the biggest set of issues (plus, it automatically figures out the enum that your constants have to come from).
Really, most of the problems with Java are fixed in JDK 1.5; the biggest issue with Java being considered a "real-world" language is that features aren't included until they have been implemented and tested for useability, safety, and complete specification. This makes it move somewhat slower, but at least it's not broken all the time.
One issue is that there is no safe state for the system to go to if the control system breaks down. Bringing the power grid in an area down safely is as hard as bringing it up safely (which, if you remember, took a while) and is harder than just keeping the system running.
The system is full of inductors, whose voltage drop is determined by the change in current through them. If you disconnect a transmission line, suddenly you're trying to change the current to 0, which puts all of the inductors at whatever voltage is necessary to make the current change more slowly. Generally, the way of making the current change more slowly is either to shoot a bolt of lightning across the gap you're creating or to melt your equipment into a conductive lump of metal, but this is only a temporary solution. Instead, the inductors (inside transformers and such) can melt down so that they aren't inductors any more and the current can change more quickly. Of course, when this happens, the next segment of transmission line is now not getting current, so it has the same problem.
The only safe way to bring down the grid is by coordinating with the adjacent grids to carefully remove the load on the line you want to disable; but that's not really an option when the problem is that communication is out.
Slashdot Mirror
71.6 PB/s is pretty impressive, but you only get that for 0.28s out of every 22,292s. I can just see the progress bar: stalled, stalled, stalled, 71.6 PB/s, 35.8PB/s, 23.8PB/s, 17.6PB/s, 14.3PB/s, stalled, stalled...
Peak bandwidth is good for records, but it's not all that useful if you can't maintain it.
But if you first use KDE without having sound set up, it will save the fact that everything's muted. If you then log in as root to set things up, set the volume and verify that it is working, and then log out as root and log back in as yourself, it will restore the muted sound settings.
Also, it at least used to be the case that, if you try to use Konqueror without otherwise using KDE, it will restore your volume settings at some unexpected moment.
Really, any patch that gets put into a kernel which gets distributed in binary form should modify the version string to indicate that it's there. I personally think the security fixes should never change the main version number, but should be distributed in the form of a patch (or a set of patches) that applies to every kernel version that had the issue and that adds something to the version string to indicate that it fixed it. Security fixes should be released already backported to previous versions, which both avoids the issue of what you do with current testing changes and also deals with issues of people who can't use the latest version.
More likely they want to make sure they're understanding the issue correctly and write up a good explanation.
OSRM does have a vested interest in the outcome, but it is in finding any problems and getting them fixed before they'd have to pay to defend them in court.
A TCO study is useful if the people who do it are offering to reimburse you any cost overruns.
Come now, nothing's perfect. Every once in a while, the universe will totally botch obeying natural law. Granted, it's incredibly unlikely that this will happen at a macroscopic scale, but...
I'd like to see an overseas IT worker check whether my network cable is plugged in securely. IT tends to involve solving a lot of problems which are due to hardware or are obvious if you look at the hardware.
Actually, Linux does support his sound hardware. He got it working with every distro he tried, and then muted it, and decided that this was somehow a driver issue. In fact, it's because there are a ton of ways your audio can get muted in Linux, from rebooting without a script to save the volume or set it at boot to running a program that has its own ideas of what your volume controls should be (Konqueror, IIRC, mutes everything if you go to a page with sound; the flash plugin mutes everything when it starts, etc).
Solution: get a volume control program for X, and leave it running at all times, thereby blocking other programs' attempts to control the volume.
The only problem I've had recently with audio is that some programs mess with the audio controls. For some reason web browsers seem to think that I shouldn't listen to CDs while I browse the web. The solution I've found is to have xmixer (built for OSS) running at all times. This blocks other programs' attempts to mess with it.
Sun doesn't make commodity processors, and they (at least in theory) have much better memory controllers already. Since it's a lot easier to improve the bandwidth on access to memory than the latency, it makes a lot of sense to uberthread their CPU, because they can move a lot of data in a single round-trip. If you have time to get 64 threads to their next cache misses in the time it takes to start getting data, and you can have 64 requests in flight at the same time, you're going to keep the processor 64 times as busy with a lot of threading than with a single thread per processor.
There are now multi-threaded garbage collectors which never pause. The GC runs in a separate thread tracking which objects have not been referenced recently and collecting ones which haven't been referenced during the time the whole heap was scanned (in much the same way that cache eviction algorithms work). It parallelizes nicely out of the program's normal operation (for the simple reason that things that are garbage aren't used by the program). On allocation, it can be made to work or fail immediately, if desired. With multiple threads, the allocating thread can block on garbage collection finding more space while other threads (which are not allocating anything) run unhindered.
Modern garbage collection is not really any slower than modern virtual memory with swap, and doesn't really make things any less predictable than swap does. It's not all that different, except that it determines memory that's especially stale, and discards it entirely.
An afternoon with Valgrind should track down most of these without too much effort. It's really gotten to be a nice "please tell me what's wrong with my program" tool, capable of letting you send in bug reports like "function X leaks a 20-byte chunk of memory and a 4-byte chunk every time I call it with these arguments." For now you can't determine things like "bytes 16-19 of the leaked chunk are a pointer to a filename", but I suspect that will be in a later version (determined by what system calls are called with it).
One thing I'd really like to see in Java is Object.free(), which would tell the garbage collector that the object is garbage and can be freed, and cause any further use of the object to throw a FreedMemoryException. This would be useful both as a hint to the system (letting it get rid of things the object references early) and as a debugging aid (so you can find cases where stuff remains in use after you don't think it will). Of course, it violates Java's sandbox design to have a C-style free() which recycles the address space.
I bet it would be a pretty quick glibc hack to support "a:" as a synonym for "/mnt/floppy", "d:" as a synonym for "/mnt/cdrom", and "c:" as a synonym for something else that makes the user happy, based on an environment variable. That's why we need a useability study: we need to know what things people will try, so we can make them work if possible, and make them easy to replace otherwise.
Windows on the other hand, you can go to the control panel and what you want to change will likely be in there somewhere, unless it's application specific, and you don't have to read any manuals or docs to figure out how to configure your system - it's intuitive.
I have to agree. With Windows you might be able to configure what you want to change if you can figure out where the heck it is, and the only way you'll figure it out is either instinct or by trying everything. With Linux, there's plenty of documentation on the web. What's more, people are talking about creating more useful documentation and putting it on the web.
I think that the total height of the learning curve matters at all. Most Linux gurus never learn all of the options to "ls". What matters more is how steep the climb to the first plateau is. If you can get the user to the point of having completed the first task of their choosing, there's a good chance that they're hooked, and will use your system despite it being very difficult to do anything further.
How difficult it is to set up Linux depends a lot on what you want to do. The shortest path to a bash prompt involves putting a Knoppix CD in the drive, turning on the computer, and clicking on the picture of the monitor. Everything is autodetected. (In fact, it took three experienced Linux users two days to get X working with Debian on a new Intel motherboard; Knoppix autodetected the right things and worked perfectly with no input)
On the other hand, Knoppix isn't what most Linux users thing of when they think of a Linux system. But it is much closer to what a Windows user would expect of an operating system. My complaints: too much disorganized junk in the menus, and the network doesn't get restarted automatically with the settings you had last time even if you've installed to the hard drive.
There doesn't seem to be any reason you couldn't enter a graphical game (so long as you don't enter a non-interactive one). You'd get fewer judges, probably, than one that was text-based, and there would probably be a bunch of discussion, but that doesn't mean you couldn't enter it. Of course, it would be judged against text, which is a much easier medium to be expressive in.
There is, in fact, a substantial discussion in the interactive fiction community about whether games should be "simulationist" or not; the simulationist camp would like the world of the story to actually function completely correctly, which the non-simulationist camp prefers only those parts which fit with the story to be implemented. Of course, randomness is only a possibility with a simulationist approach (although it is not frequently used for anything important).
There are examples of works which are definitely literary. In Photopia, for example, the ineractor cannot change the outcome of any of the scenes, but instead essentially delivers the lines of a series of characters. The interactor takes the part of an actor in a play, with the author as playwright. It functions like a book in that the plot is fixed and scripted, but the reader is not outside of the action, but is actually there choosing how characters' speeches are worded, and setting up the details of the experience. In fact, right at the beginning, you make a descision which is critical to what will happen, and the entire story hinges on making the wrong choice; you (as the character you play in that scene) would wish that you'd only been wiser. But, in fact, the game makes whichever choice you make be the wrong one, and the story does happen regardless. The interactivity doesn't actually let you make the right choice (and foil the author's attempt to have a story), but it make you (as the character) responsible for what happens. It wouldn't be an especially good static fiction story; it would be a paragraph in the newspaper at most. But as it is actually presented, the main character is your daughter, your classmate, your babysitter, because the game has put you in the shoes of a number of people with various relationships to her, and asked you to walk a mile.
Modern IF is really about getting a reader to make an emotional investment in the outcome of the story by playing a role in it rather than simply providing a world in which any story (or, more likely, no story of interest) can happen. The trick is to hide the author's control while making it constantly effective.
To use the computer analogy, it's like they took a computer and tried looking for where the cache is. After performing a bunch of graphics tests, they found that the cache is on the graphics card.
I suppose there is one thing here that people are not generally aware of: working memory (and long-term memory) is not distributed evenly throughout the brain, but is, rather, in the areas where the things you're remembering are processed.
Google is doing well with their search engine, and making a bunch of money. If they continue tweaking their algorithms as needed, they will continue to make this money, but there's not that much tweaking it can productively get at any particular point in time. This means that they have programmers (some of whom have unusual names) who they need to keep around, and to do that, they need to keep them interested and they need to keep paying them. I bet the entire point of Orkut, from Google's perspective, is that Orkut (the person) feels like doing it, and Google doesn't want him to quit. If it keeps the programmers happy, it's worthwhile. Oh, it might be good for business at some point.
Actually, getting VC is 90% knowing the right people. So Google's management went to the team and asked them if they knew anyone influential. The team said, "We don't know. Let's write a program to find out."
So I open the attachment. Hmm... the message didn't mention a program. Or the other person doesn't have a good reason to be sending programs to me. Better find out what this is all about before I run it.
The broken thing about Windows is that users have no way of knowing what will happen if they click on an attachment. Usually, they view the contents of the attached file. But sometimes it destroys their system instead. The expectation is that there will be no side effects of the operation; at most, they will be given the opportunity to save the file. But this assumption is violated by viruses which don't even use a security hole.
I don't think the Google is going to try the portal thing. After all, they're no less aware than we are that nobody else has made that work. In fact, they just made their search pages simpler.
On the other hand, that doesn't mean they can't have other features. I think they're likely to keep adding special things you can "search" for, like UPS packages and "(the speed of light / (440 nm)) in THz", since these don't make the interface any more complicated.
They also already have other pages available, like news.google.com (which indexes news sites in the form of a news site). As long as they keep the reputation of the brand good, and keep the search site focused and the results good, it doesn't matter how much they branch out. They seem to have the right attitude towards advertizers: provide ads primarily to people who are actually searching for products, not to people who are looking for content. They can probably extend their offerings as competently and respectfully of their audience. And they might as well; they've already got the best search engine team out there, and they've got money to expand, so new things they try will use new employee effort, and not detract from the search engine.
Or, in JDK 1.5, a typesafe enum. Perhaps it ought to also support Strings, but I think enums satisfy the biggest set of issues (plus, it automatically figures out the enum that your constants have to come from).
Really, most of the problems with Java are fixed in JDK 1.5; the biggest issue with Java being considered a "real-world" language is that features aren't included until they have been implemented and tested for useability, safety, and complete specification. This makes it move somewhat slower, but at least it's not broken all the time.
It's a really tempting idea, but on second thought, do you actually want someone behind you in an SUV to be blind?
One issue is that there is no safe state for the system to go to if the control system breaks down. Bringing the power grid in an area down safely is as hard as bringing it up safely (which, if you remember, took a while) and is harder than just keeping the system running.
The system is full of inductors, whose voltage drop is determined by the change in current through them. If you disconnect a transmission line, suddenly you're trying to change the current to 0, which puts all of the inductors at whatever voltage is necessary to make the current change more slowly. Generally, the way of making the current change more slowly is either to shoot a bolt of lightning across the gap you're creating or to melt your equipment into a conductive lump of metal, but this is only a temporary solution. Instead, the inductors (inside transformers and such) can melt down so that they aren't inductors any more and the current can change more quickly. Of course, when this happens, the next segment of transmission line is now not getting current, so it has the same problem.
The only safe way to bring down the grid is by coordinating with the adjacent grids to carefully remove the load on the line you want to disable; but that's not really an option when the problem is that communication is out.