The obvious answer that everyone seems to be ignoring is that you get the best fuel efficiency by not going anywhere at all. Thus we should all become hermits and all turn our cars into permanent drive-in theaters in the back yard.
The stat I've heard before on fuel efficiency is 90km/h or ~50mph, but JWSmythe's comment makes sense also.
Until Yahoo gets subpoenaed to pull the email off of the back ups that they haven't deleted yet. Anyway, you could make a strong argument that given the circumstances, deleting the email would be considered destruction of evidence, which a US court _could_ hit you for.
Personally, I would be a bit suspicious employing someone who is freely willing to give away their time. First, how long are they going to be around before they finally burn out? Or, will the person change their mind at a later date and decide that they need to be compensated for that past work (perhaps be under working later on)?. Or perhaps they're only treating the job as a tie over until something better comes along?
I would say that there really aren't many people who are willing to put their full skill behind a for profit venture when they aren't properly compensated and don't expect to be in the future. The only people you get in that group are extreme idealists, who are probably just inexperienced (for now) and those who feel they don't have any choice but to stay. To me this sounds like a recipe for a disgruntled and ineffectual workforce.
Assuming that it didn't arrive with the probe, the wikipedia article also suggests that perchlorate causes thyroid problems. So if we make it there, we'll have access to air, but will have to deal with another potential harmful problem for staying.
I read an article (that may be wrong) that stated that oil traders only needed to pay for 10% of the contract that they bid on. If that's the case then it makes biding high prices a fairly low risk, especially when the prices keep going up. There's also been talk in the news about making more strict trading guidelines, but obviously the people making the money on this are doing their best to raise red flags..
Here's my idea, make the whole tld thing optional. If you specify a domain without the tld, you get the most general version of that site, regardless of localization/internationalization. If you need something specific pertaining to gov't or localized, use your.us,.ca,.eu,.cn or whichever pertains.
This way there's no fooling around with what you are going to get and you won't have 18 versions of the same domain name.
Oops, too bad there are already a few million domains that already conflict with this idea.
After 22 years of loud clicking, I wonder if you'll sustain any hearing damage.. A sturdy keyboard is a great thing, but at least put in some rubber or something to muffle the sound.
I agree, but I think it's more accurate to say that, we can see part of the result before it is outputted, and correlate that to a likely value. So basically, what they're showing (in a novel way) is that some conditions make you predisposed to make a certain decision. This is one of the aspects of how neural networks operate.., so the idea isn't really new.
My board has the NVidia older 430 chipset which might be part of the problem. I'm probably just going to pick up an M-Audio or similar. Even without the glitches, I'm still not really happy with it (in Windows too).
His view on ray tracing is pretty much summed up by:
David Kirk, NVIDIA: I'm not sure which specific advantages you are referring to, but I can cover some common misconceptions that are promulgated by the CPU ray tracing community. Some folks make the argument that rasterization is inherently slower because you must process and attempt to draw every triangle (even invisible ones)--thus, at best the execution time scales linearly with the number of triangles. Ray tracing advocates boast that a ray tracer with some sort of hierarchical acceleration data structure can run faster, because not every triangle must be drawn and that ray tracing will always be faster for complex scenes with lots of triangles, but this is provably false.
There are several fallacies in this line of thinking, but I will cover only two. First, the argument that the hierarchy allows the ray tracer to not visit all of the triangles ignores the fact that all triangles must be visited to build the hierarchy in the first place. Second, most rendering engines in games and professional applications that use rasterization also use hierarchy and culling to avoid visiting and drawing invisible triangles. Backface culling has long been used to avoid drawing triangles that are facing away from the viewer (the backsides of objects, hidden behind the front sides), and hierarchical culling can be used to avoid drawing entire chunks of the scene. Thus there is no inherent advantage in ray tracing vs. rasterization with respect to hierarchy and culling./blockquote
I dunno, might be a Ubuntu issue then. Mine on an Asus NVidia m2n mobo wasn't even detected until 7.10 and I've had almost constant issues with it since then.
So you would think, but the linux support for the awfully common Intal HDA series of cards is still pretty bad. Granted, I don't know if it's poor software to blame, but getting sound out of these things (when you can at all) is an adventure with lots of crackles, pops, and pulling out of your hair. If it wasn't for the fact that the hardware has an RCA S/PDIF output, I'd still be using my 8 yro SB Live Value..
It isn't an apples to apples comparison anyway, the fact remains that OO.org is still a Java application while MS Office is not. I strongly suspect that that is the main reason for the performance difference, although OO.org shows similar uptime performance problems to Firefox (Large sheets that have had a lot of calculations done to them get bogged down after a while, which is corrected by a restart).
Just because you have an abstraction layer, doesn't mean that you can have a pass-through for limited cases where it's better to use a DBMS specific feature.
That doesn't really legitimize the claims made in the summary however. This is./ though, so probably not worth making a big fuss about it. Anyway, even last year I was interested in giving FreeBSD a try as our DB host but I haven't had time. It's just a shame that most readers aren't going to get much useful information from the summary or discussion.
Yep, it's usually a good idea to read the whole article.
The telling slide though is 17, from the summary, the so-called "Latest Linux Kernel" is Linux 2.6.23.0.214.rc8.git2.fc8, a release candidate on an unstable branch of the kernel. Even with that being the case, the graph shows a slight edge given to FreeBSD, until there's a blip in the Linux results between 9-16 threads, after which the performance levels out. The fact remains, while the results for FreeBSD are clearly in FreeBSD's favour after 8 threads, I don't think you can make any judgments on the results until the benchmark includes a Linux 2.6.24 series server kernel.
The next slide, 18, is interesting though, as neither of the Linux kernels handle MySQL's concurrency nearly as well. There's are some reasons why I prefer Postgres though : )
The article is probably misleading (surprise, surprise), as the tuning documentation for PostgreSQL *states* that good IO performance has more of an impact than good CPU performance. Additionally, some other information I've read (search for postgres tuning/optimi(z|s)ation online) recommends FreeBSD because of its strong IO performance. I'll go out on a limb and assume that MySQL's performance attributes are similar.
In my opinion, the article summary is a pretty big red herring because the SMP performance may not have a huge impact on the result.
That's also fine, until Microsoft decides to go after you once you've reviewed the source, but happen to work on a parallel product, say Linux. This may be a cynical analysis, but the fact remains that this could be a trap, and slashdot previously covered similar problems with the source code releases of XP to Gov't, etc staff.
Slashdot Mirror
The obvious answer that everyone seems to be ignoring is that you get the best fuel efficiency by not going anywhere at all. Thus we should all become hermits and all turn our cars into permanent drive-in theaters in the back yard. The stat I've heard before on fuel efficiency is 90km/h or ~50mph, but JWSmythe's comment makes sense also.
Until Yahoo gets subpoenaed to pull the email off of the back ups that they haven't deleted yet. Anyway, you could make a strong argument that given the circumstances, deleting the email would be considered destruction of evidence, which a US court _could_ hit you for.
Personally, I would be a bit suspicious employing someone who is freely willing to give away their time. First, how long are they going to be around before they finally burn out? Or, will the person change their mind at a later date and decide that they need to be compensated for that past work (perhaps be under working later on)?. Or perhaps they're only treating the job as a tie over until something better comes along?
I would say that there really aren't many people who are willing to put their full skill behind a for profit venture when they aren't properly compensated and don't expect to be in the future. The only people you get in that group are extreme idealists, who are probably just inexperienced (for now) and those who feel they don't have any choice but to stay. To me this sounds like a recipe for a disgruntled and ineffectual workforce.
Assuming that it didn't arrive with the probe, the wikipedia article also suggests that perchlorate causes thyroid problems. So if we make it there, we'll have access to air, but will have to deal with another potential harmful problem for staying.
I read an article (that may be wrong) that stated that oil traders only needed to pay for 10% of the contract that they bid on. If that's the case then it makes biding high prices a fairly low risk, especially when the prices keep going up. There's also been talk in the news about making more strict trading guidelines, but obviously the people making the money on this are doing their best to raise red flags..
Here's my idea, make the whole tld thing optional. If you specify a domain without the tld, you get the most general version of that site, regardless of localization/internationalization. If you need something specific pertaining to gov't or localized, use your .us, .ca, .eu, .cn or whichever pertains.
This way there's no fooling around with what you are going to get and you won't have 18 versions of the same domain name.
Oops, too bad there are already a few million domains that already conflict with this idea.
After 22 years of loud clicking, I wonder if you'll sustain any hearing damage.. A sturdy keyboard is a great thing, but at least put in some rubber or something to muffle the sound.
I agree, but I think it's more accurate to say that, we can see part of the result before it is outputted, and correlate that to a likely value. So basically, what they're showing (in a novel way) is that some conditions make you predisposed to make a certain decision. This is one of the aspects of how neural networks operate.., so the idea isn't really new.
That is included in the D2X, which is around the same price as the X-FI's
http://bugtrack.alsa-project.org/main/index.php/Matrix:Vendor-Asus The alsa wiki suggests that the DX is not supported yet, but the D and D2X are (and appear to use a newer chipset to boost).
I believe that it's because the themselves chips are being re-branded for OEM's.
My board has the NVidia older 430 chipset which might be part of the problem. I'm probably just going to pick up an M-Audio or similar. Even without the glitches, I'm still not really happy with it (in Windows too).
Examples please..
http://www.pcper.com/article.php?aid=530/
His view on ray tracing is pretty much summed up by:
I dunno, might be a Ubuntu issue then. Mine on an Asus NVidia m2n mobo wasn't even detected until 7.10 and I've had almost constant issues with it since then.
So you would think, but the linux support for the awfully common Intal HDA series of cards is still pretty bad. Granted, I don't know if it's poor software to blame, but getting sound out of these things (when you can at all) is an adventure with lots of crackles, pops, and pulling out of your hair. If it wasn't for the fact that the hardware has an RCA S/PDIF output, I'd still be using my 8 yro SB Live Value..
They aren't available in Canada (and elsewhere?) yet.
Right you are http://wiki.services.openoffice.org/wiki/Java_and_OpenOffice.org
It isn't an apples to apples comparison anyway, the fact remains that OO.org is still a Java application while MS Office is not. I strongly suspect that that is the main reason for the performance difference, although OO.org shows similar uptime performance problems to Firefox (Large sheets that have had a lot of calculations done to them get bogged down after a while, which is corrected by a restart).
Just because you have an abstraction layer, doesn't mean that you can have a pass-through for limited cases where it's better to use a DBMS specific feature.
That doesn't really legitimize the claims made in the summary however. This is ./ though, so probably not worth making a big fuss about it. Anyway, even last year I was interested in giving FreeBSD a try as our DB host but I haven't had time. It's just a shame that most readers aren't going to get much useful information from the summary or discussion.
Yep, it's usually a good idea to read the whole article.
The telling slide though is 17, from the summary, the so-called "Latest Linux Kernel" is Linux 2.6.23.0.214.rc8.git2.fc8, a release candidate on an unstable branch of the kernel. Even with that being the case, the graph shows a slight edge given to FreeBSD, until there's a blip in the Linux results between 9-16 threads, after which the performance levels out. The fact remains, while the results for FreeBSD are clearly in FreeBSD's favour after 8 threads, I don't think you can make any judgments on the results until the benchmark includes a Linux 2.6.24 series server kernel.
The next slide, 18, is interesting though, as neither of the Linux kernels handle MySQL's concurrency nearly as well. There's are some reasons why I prefer Postgres though : )
The article is probably misleading (surprise, surprise), as the tuning documentation for PostgreSQL *states* that good IO performance has more of an impact than good CPU performance. Additionally, some other information I've read (search for postgres tuning/optimi(z|s)ation online) recommends FreeBSD because of its strong IO performance. I'll go out on a limb and assume that MySQL's performance attributes are similar.
In my opinion, the article summary is a pretty big red herring because the SMP performance may not have a huge impact on the result.
That's also fine, until Microsoft decides to go after you once you've reviewed the source, but happen to work on a parallel product, say Linux. This may be a cynical analysis, but the fact remains that this could be a trap, and slashdot previously covered similar problems with the source code releases of XP to Gov't, etc staff.