Yeah, I think so. IIRC it's called tagged command queueing - the drive can have multiple requests pending and instead of doing them first come first served, they're fulfilled in order of estimated latency to that point.
I believe Western Digital's recent Raptor IDE drives have the same feature.
The benefit of this seems contingent upon having multiple requests pending, which AFAIK is hard on linux as there's no non-blocking file IO. To me, this reads like a workaround for that.
Unless it's a computer book.. I know I've got books that act as references to software that no-one uses anymore because newer versions have come out, as well as references for APIs that I end up not using because expansions in newer versions have rendered it incomplete
It may be true, of course, that they've not become incorrect, and that they may be of historical interest, but that's all the use they are now, and it seems a great waste
Sure, it may not seem as natural to read off a screen as it is to read off paper (primarily, I think, because you can hold a book in your hand, and remember the position you were reading from by that reference), but I'd rather have E-books, or even a web page or stand alone reference program for that, as it avoids the wastage.
English isn't an efficient language in terms of the amount of stuff you have to write down to convey an idea.. Take Gzip - gzip an average english text and you'll find it reduces to about a third its former size, and that's without taking special account of the particular grammar to improve this compression.
For text writing, people get used to doing it properly and don't notice this inefficiency, but suddenly it becomes greatly more apparent when using a more limited text entry device..
So, people start abbreviating "you" to U and so on. Cretinous, but a sufficient skunkworks method of addressing the problem. We could do much better, though, by specifically designing a separate compact form of the language for efficient entry on small keypads.
The optimisers in sun's Java VM work on run-time profiling - they identify the most run sections of code and use the more elaborate optimisation steps on these segments alone.
Benchmarks that consist of one small loop will do very well under this scheme, as the critical loop will get all of the optimisation effort, but I suspect that in programs where the CPU time is more distributed over many code sections, this scheme will perform less well.
C doesn't have the benefit of this run-time profiling to aid in optimising critical sections, but it can more afford to apply its optimisations across the entire codebase.
I'd be interested to see results of a benchmark of code where CPU time is more distributed..
No, it won't. People who are interested in getting a mac will probably already have one or be getting one soon. People with Intel PCs are probably staying with Intel PCs. I think the market divisions are strong enough that Intel doesn't need to worry about this too much.
Pervasive computing
on
USB Menorah
·
· Score: 3, Funny
While basically gimmics, stuff like this USB powered menorah and the USB toothbrush may be looked back on historically as the dawning of the pervasive computing age..
Next thing will be to make them interface via wireless ethernet.
Licensing, by definition, defines limitations on your use of a peice of software and requires certain preconditions to be satisfied by you. If you don't agree to the limitations, or to meet the preconditions, then it's up to you to write or obtain an analogue of the software for your own use - hence a limitation on reuse.
Patents, perhaps I was off in naming this a re-use issue. Still, the flexibility inherent in computer software is bounded only by power. Concerns of a legal nature imposing arbitrary restrictions are a real shame.
like when the retarded kid at school asks you how to become more popular..
Still, the biggest advantage I can think of is the open source model - the industry has been working for years on ways to increase reuse, but commercial licensing and patent issues get in the way of that.
I'd like to point out that the nature of open-source de-emphasizes the importance of central decisions such as this.
Linus and his helpers are the de-facto maintainers, yes, because people find they generally make a good job of it. AFAIK the only legal claim they have is to the name "linux".
If you want the 2.4 kernel line to still have new features added, fine. Download the source, add the features, put it up for download. You could even apply the security and stabilisation patches from the main tree to your "experimental" tree..
Not particularly directed at Farscape, perhaps, but I see a lot of criticism about various sci-fi shows for a lack of originality, in that a lot of basic tech and plot concepts seem mirrored across many different series.
I think creating an original premise for sci-fi is now extremely hard, all the main aspects of possible futures being represented in one show or another. I know I can't think of anything new to base a story on.
Can anyone point to some recent sci-fi that is truly original? Thanks.
Really, I'm always amazed how fast hamsters and the like can chew through a stack of papers. Not to mention, they're also cheaper than an actual shredder. Cute too.
Personally, I think the main thing that would benefit the anti-spam cause now is more structure - in a software sense.
There's already quite a few good, pretty effective techniques of filtering, but a truly best-case scenario would be arrived at using a combination of techniques.
Look at the anti-spam tech available at the moment. There's filters that act as POP3 proxies, filters that run as a plug-in to a specific client (or built-in), and the odd mail server add-in. There's even the case of remote mailboxes (eg using IMAP) which is difficult to deal with any way apart from having the filter on the server.
Spam filtering is best set-up on a client-by-client basis, because people tend to get different types of mail as normal. Also, if we're doing it on a client-by-client basis, end user interface is very important - any manual classification and configuration of such filters would be best done inside the user interface of the client software, in much the same way as client-specific plugins do it. To do this in a way consistent across client packages (necessary if we want to tackle the problem as a whole and not just for some people) would require a standard protocol for querying graphs of mail filters, relaying any corrections and reconfiguring said filter graph.
I'd like to see a protocol built upon Seive (a language in RFC form for notating mail filtering rules) and a standard for mail filter components (standard COM/CORBA interfaces, whatever). The seive language could provide flexibly reconfigurable "plumbing" between the individual filters.
Even if one only uses one filter under such a mechanism, there'd still be benefits from a standardised software interface and ability to control from within any mail client.
I always thought that the real virtue of computers over older ways of doing things was flexibility - the way you can expand and alter what a computer will do for you simply by adding new programs..
This, to me, hints at the direction we should be taking in training computer users - Knowing how to use one application very well (such as word) is not really the point. True computer skill is, I think, the ability to work out how software works easily.
This skill can be taught just as easily on macs and acorn archimedeses than on the Windows platform. In fact, using a different OS may actually help this process, as students are less likely to be familiar with the school OS and therefore would have to use that intuition more, thus honing it.
I've always been a bit suspicious of wind power, myself, as I doubt that the environmental impact is really as low as they say.
The main concern is variability of wind conditions. You're not guaranteed the average output from them, (winds to high, they need to be shutdown or be dangerous, winds too low, low output) and this would require one of the following strategies to deal with it:
A: Build so many of them all over the place that it's statistically very unlikely production will fall below demand. This would use a lot of land, and be pretty uneconomical.
B: Endeavor to store the energy. Pretty much the only way to store that much juice is by creating a lake by flooding some valley, using excess energy (when you have any) to pump water into it, and when demand exceeds production, let the water run out and drive turbines.
Personally, I wouldn't describe either of these options as being particularly environmentally sussed solutions.
Spam filtering is even more successful because we essentially categorize e-mails to two labels: "spam" or "not spam"
True. You could simply have a spam and a not spam category. I don't think that'll necessarily lead to the highest accuracies though.
Spam naturally seems to come in several categories - porn, penis enlargements, mortgages etc. However, it's unlikely that any one spam will simultaneously advertise porn and mortgages. Simply having a "spam" and a "not" category will not take advantage of distinctions such as that.
When setting up systems such as popfile, consider creating subcategories for each type of spam you tend to get. More work to train, true, but likely to be more accurat once you're done.
Well, they have in some ways.. Increases in capacity have come due mainly to vast increases in the areal density of the media. This, in turn, yielded massive increases in the rate the data moved under the heads..
The problem with hard disks isn't the data transfer rates they are capable of - it's their latency we need to worry about.
We need better defragmentation algorithms - I suspect that files are usually accessed in list order.. When running a program, for example, it's always going to want to read the same files in the same order. If we can arrange files that are usually accessed to be contiguous on the disk surface, and also make the filing system read the whole list of files that are situated contiguously into the disk cache when the first file in that list is read then the relatively high burst transfer rates will take more precedence over the access times, and things will seem a lot quicker.
Linux is better than Windows because it's so complex and difficult to use?
No, but to every coin there's a flip-side. A lot of the criticisms one side in this windows vs linux debate are only problems depending on how you look at them.
The complexity of package management is a good example - The fact that linux is available in so many different distributions, and for quite a few different processors means that package management in linux can be quite a mess.
Microsoft could easily use the packaging situation as a big point against linux in advertising. Linux fanatics could easily advertise the system on its diversity.
A lot of the time in software design there's trade-offs to be made, and while there's frequently good arguments to balancing the system in one way, there'd still invariably be other advantages to balancing the situation another way.
Personally, I'd rather learn to deal with the packaging problem than yield the advantages that gave rise to that problem, but I could certainly understand that you prefer it the other way.
One of the greatest strengths of the UNIX platform is its diversity..
Package installation is a simple prospect on the Windows platform for the simple reason that the platform has little diversity.
Windows supports a very limited set of processors.. So there's one factor that windows packaging doesn't have to worry about.
Windows doesn't generally provide seperately compiled binaries for slightly different processors ("Fat binaries" are used instead, wasting space).. So the packaging system doesn't have to worry about that. On linux, on the other hand, you can get separate packages for an athlon-tbird version and an original athlon version.
On an MS system, the installers contain all the libraries the package needs that have the potential to not be on the system already. This could make the packages rather large, but ensures the user doesn't have to deal with dependencies. Personally, I'd rather deal with dependencies myself than super-size every installer that relies on a shared object..
Furthermore, on windows there arn't several different distributions to worry about, so the installers don't have to deal with that either.
All of these point confer more flexibility to the unix system but have the inevitable consequence that package management can get to be rather a complex art. We could simplify package management a great deal, but it'd mean giving up the above advantages.
The question of what is on "the edge" can be answered by how much controversy the thing recieves - Something accepted by all will be mainstream, "the edge" denotes a radical departure and whenever there's a radical departure there's going to be quite a few people complaining about it.
It would seem to me that this whole palladium situation is the most controversial software project in a while, so it could probably be termed "on the edge", too.
Slashdot Mirror
Yes. I found that. Then I realised I had the hard disk in PIO only mode. A recompile with DMA support and it's smooth as silk.
Yeah, I think so. IIRC it's called tagged command queueing - the drive can have multiple requests pending and instead of doing them first come first served, they're fulfilled in order of estimated latency to that point.
I believe Western Digital's recent Raptor IDE drives have the same feature.
The benefit of this seems contingent upon having multiple requests pending, which AFAIK is hard on linux as there's no non-blocking file IO. To me, this reads like a workaround for that.
Unless it's a computer book.. I know I've got books that act as references to software that no-one uses anymore because newer versions have come out, as well as references for APIs that I end up not using because expansions in newer versions have rendered it incomplete
It may be true, of course, that they've not become incorrect, and that they may be of historical interest, but that's all the use they are now, and it seems a great waste
Sure, it may not seem as natural to read off a screen as it is to read off paper (primarily, I think, because you can hold a book in your hand, and remember the position you were reading from by that reference), but I'd rather have E-books, or even a web page or stand alone reference program for that, as it avoids the wastage.
English isn't an efficient language in terms of the amount of stuff you have to write down to convey an idea.. Take Gzip - gzip an average english text and you'll find it reduces to about a third its former size, and that's without taking special account of the particular grammar to improve this compression.
For text writing, people get used to doing it properly and don't notice this inefficiency, but suddenly it becomes greatly more apparent when using a more limited text entry device..
So, people start abbreviating "you" to U and so on. Cretinous, but a sufficient skunkworks method of addressing the problem. We could do much better, though, by specifically designing a separate compact form of the language for efficient entry on small keypads.
The optimisers in sun's Java VM work on run-time profiling - they identify the most run sections of code and use the more elaborate optimisation steps on these segments alone.
Benchmarks that consist of one small loop will do very well under this scheme, as the critical loop will get all of the optimisation effort, but I suspect that in programs where the CPU time is more distributed over many code sections, this scheme will perform less well.
C doesn't have the benefit of this run-time profiling to aid in optimising critical sections, but it can more afford to apply its optimisations across the entire codebase.
I'd be interested to see results of a benchmark of code where CPU time is more distributed..
No, it won't. People who are interested in getting a mac will probably already have one or be getting one soon. People with Intel PCs are probably staying with Intel PCs. I think the market divisions are strong enough that Intel doesn't need to worry about this too much.
While basically gimmics, stuff like this USB powered menorah and the USB toothbrush may be looked back on historically as the dawning of the pervasive computing age..
Next thing will be to make them interface via wireless ethernet.
Licensing, by definition, defines limitations on your use of a peice of software and requires certain preconditions to be satisfied by you. If you don't agree to the limitations, or to meet the preconditions, then it's up to you to write or obtain an analogue of the software for your own use - hence a limitation on reuse.
Patents, perhaps I was off in naming this a re-use issue. Still, the flexibility inherent in computer software is bounded only by power. Concerns of a legal nature imposing arbitrary restrictions are a real shame.
like when the retarded kid at school asks you how to become more popular..
Still, the biggest advantage I can think of is the open source model - the industry has been working for years on ways to increase reuse, but commercial licensing and patent issues get in the way of that.
I'd like to point out that the nature of open-source de-emphasizes the importance of central decisions such as this.
Linus and his helpers are the de-facto maintainers, yes, because people find they generally make a good job of it. AFAIK the only legal claim they have is to the name "linux".
If you want the 2.4 kernel line to still have new features added, fine. Download the source, add the features, put it up for download. You could even apply the security and stabilisation patches from the main tree to your "experimental" tree..
Not particularly directed at Farscape, perhaps, but I see a lot of criticism about various sci-fi shows for a lack of originality, in that a lot of basic tech and plot concepts seem mirrored across many different series.
I think creating an original premise for sci-fi is now extremely hard, all the main aspects of possible futures being represented in one show or another. I know I can't think of anything new to base a story on.
Can anyone point to some recent sci-fi that is truly original? Thanks.
Carefully used, italics will do the job.
eg: Wow! that post was just so insightful.
Dear Rusty?
Or even just buy a hamster.
Really, I'm always amazed how fast hamsters and the like can chew through a stack of papers. Not to mention, they're also cheaper than an actual shredder. Cute too.
Personally, I think the main thing that would benefit the anti-spam cause now is more structure - in a software sense.
There's already quite a few good, pretty effective techniques of filtering, but a truly best-case scenario would be arrived at using a combination of techniques.
Look at the anti-spam tech available at the moment. There's filters that act as POP3 proxies, filters that run as a plug-in to a specific client (or built-in), and the odd mail server add-in. There's even the case of remote mailboxes (eg using IMAP) which is difficult to deal with any way apart from having the filter on the server.
Spam filtering is best set-up on a client-by-client basis, because people tend to get different types of mail as normal. Also, if we're doing it on a client-by-client basis, end user interface is very important - any manual classification and configuration of such filters would be best done inside the user interface of the client software, in much the same way as client-specific plugins do it. To do this in a way consistent across client packages (necessary if we want to tackle the problem as a whole and not just for some people) would require a standard protocol for querying graphs of mail filters, relaying any corrections and reconfiguring said filter graph.
I'd like to see a protocol built upon Seive (a language in RFC form for notating mail filtering rules) and a standard for mail filter components (standard COM/CORBA interfaces, whatever). The seive language could provide flexibly reconfigurable "plumbing" between the individual filters.
Even if one only uses one filter under such a mechanism, there'd still be benefits from a standardised software interface and ability to control from within any mail client.
Are you casting aspersions on the reliability of AMDs new line of processors?
I always thought that the real virtue of computers over older ways of doing things was flexibility - the way you can expand and alter what a computer will do for you simply by adding new programs..
This, to me, hints at the direction we should be taking in training computer users - Knowing how to use one application very well (such as word) is not really the point. True computer skill is, I think, the ability to work out how software works easily.
This skill can be taught just as easily on macs and acorn archimedeses than on the Windows platform. In fact, using a different OS may actually help this process, as students are less likely to be familiar with the school OS and therefore would have to use that intuition more, thus honing it.
I think that's overstating the matter somewhat.. the Windows 2000 patch only works on Service Pack one. Not two or three.
There's at least one excuse not to use it.
Well, I think the main benefit to applications like this of IPv6 will be the multicasting support.
Sure, multicasting is also available in IPv4 via IGMP, but I highly suspect that it won't really get used too much until IPv6 is the norm.
I've always been a bit suspicious of wind power, myself, as I doubt that the environmental impact is really as low as they say.
The main concern is variability of wind conditions. You're not guaranteed the average output from them, (winds to high, they need to be shutdown or be dangerous, winds too low, low output) and this would require one of the following strategies to deal with it:
A: Build so many of them all over the place that it's statistically very unlikely production will fall below demand. This would use a lot of land, and be pretty uneconomical.
B: Endeavor to store the energy. Pretty much the only way to store that much juice is by creating a lake by flooding some valley, using excess energy (when you have any) to pump water into it, and when demand exceeds production, let the water run out and drive turbines.
Personally, I wouldn't describe either of these options as being particularly environmentally sussed solutions.
Spam filtering is even more successful because we essentially categorize e-mails to two labels: "spam" or "not spam"
True. You could simply have a spam and a not spam category. I don't think that'll necessarily lead to the highest accuracies though.
Spam naturally seems to come in several categories - porn, penis enlargements, mortgages etc. However, it's unlikely that any one spam will simultaneously advertise porn and mortgages. Simply having a "spam" and a "not" category will not take advantage of distinctions such as that.
When setting up systems such as popfile, consider creating subcategories for each type of spam you tend to get. More work to train, true, but likely to be more accurat once you're done.
Well, they have in some ways.. Increases in capacity have come due mainly to vast increases in the areal density of the media. This, in turn, yielded massive increases in the rate the data moved under the heads..
The problem with hard disks isn't the data transfer rates they are capable of - it's their latency we need to worry about.
We need better defragmentation algorithms - I suspect that files are usually accessed in list order.. When running a program, for example, it's always going to want to read the same files in the same order. If we can arrange files that are usually accessed to be contiguous on the disk surface, and also make the filing system read the whole list of files that are situated contiguously into the disk cache when the first file in that list is read then the relatively high burst transfer rates will take more precedence over the access times, and things will seem a lot quicker.
Linux is better than Windows because it's so complex and difficult to use?
No, but to every coin there's a flip-side. A lot of the criticisms one side in this windows vs linux debate are only problems depending on how you look at them.
The complexity of package management is a good example - The fact that linux is available in so many different distributions, and for quite a few different processors means that package management in linux can be quite a mess.
Microsoft could easily use the packaging situation as a big point against linux in advertising. Linux fanatics could easily advertise the system on its diversity.
A lot of the time in software design there's trade-offs to be made, and while there's frequently good arguments to balancing the system in one way, there'd still invariably be other advantages to balancing the situation another way.
Personally, I'd rather learn to deal with the packaging problem than yield the advantages that gave rise to that problem, but I could certainly understand that you prefer it the other way.
One of the greatest strengths of the UNIX platform is its diversity..
Package installation is a simple prospect on the Windows platform for the simple reason that the platform has little diversity.
Windows supports a very limited set of processors.. So there's one factor that windows packaging doesn't have to worry about.
Windows doesn't generally provide seperately compiled binaries for slightly different processors ("Fat binaries" are used instead, wasting space).. So the packaging system doesn't have to worry about that. On linux, on the other hand, you can get separate packages for an athlon-tbird version and an original athlon version.
On an MS system, the installers contain all the libraries the package needs that have the potential to not be on the system already. This could make the packages rather large, but ensures the user doesn't have to deal with dependencies. Personally, I'd rather deal with dependencies myself than super-size every installer that relies on a shared object..
Furthermore, on windows there arn't several different distributions to worry about, so the installers don't have to deal with that either.
All of these point confer more flexibility to the unix system but have the inevitable consequence that package management can get to be rather a complex art. We could simplify package management a great deal, but it'd mean giving up the above advantages.
The question of what is on "the edge" can be answered by how much controversy the thing recieves - Something accepted by all will be mainstream, "the edge" denotes a radical departure and whenever there's a radical departure there's going to be quite a few people complaining about it.
It would seem to me that this whole palladium situation is the most controversial software project in a while, so it could probably be termed "on the edge", too.