It was actually on digg a month ago, but whoever submitted the latest digg version linked to his blog instead of the actual page to get around their dupe detection.
You're a known troll, and I'm pretty sure I've replied to a very similar troll of yours before, but I'll bite for the benefit of anyone else reading this thread.
1. Maybe this bug is fixed in the nightly build. That's because dozens of bugs are fixed every day and there are usually a lot of days of development between the released version and the latest nightly builds at the time someone reports a bug. If it's not trivial to reproduce, it's not a good use of the developer's time, since hundreds of bug reports are filed daily. If each reporter takes 5 mintes to try a nightly build, the average per-user time is going to be 5 extra minutes. If developers have to try convoluted steps to reproduce per bug, it's going to be hours of wasted time per developer.... even if the steps to reprdoce are simple, if the developer doesn't experience the bug in a nightly build, it's a valid question. The bug is either fixed in that nightly build, or other factors make it a works-for-me for the developer (for example, a changed preference setting). The only way to tell the two apart is to ask the user to test in a newer build.
2. Yes, this bug exists, but other things are more important. What, you think that just because an icon that's off by one pixel somewhere bothers you a lot, they should fix that before they fix actual functionality issues, or accessibility issues, or crashes, or add new features that will benefit hundreds of thousands of users? What kind of stupid complaint is this? Everybody intelligent prioritizes tasks.
3. No one has posted a TalkBack report. [If they had read the bug report, they would know that there is never a TalkBack report, because the bug crashes TalkBack, too, or a TalkBack report is not generated.] I've DEFINITELY responded to this before.
4. If you would just give us more information, we would fix this bug. I've responded to this too. I guess you just drop this list on any bug that mentions Mozilla. Anyhow, as I would have said before, do you think developers are clairvoyant? If you file a bug that says, "The URL bar is broken", what do you expect? If the developers don't have enough information to reproduce your bug, or can't reproduce it themselves, well, they need more information.
5. This bug report is a composite of other bugs, so this bug report is invalid. [The other bugs aren't specified.] I'm not going to point out further comments I've addressed before. This is a legitimate reason a bug is invalid. However, it is fair to complain that whoever closed the bug did not specify the bug #s. Do it in the bugs, not on slashdot, because it will be seen if it's in the bug report. Complain on IRC if it's specific people doing it.
6. You are using Firefox in a way that would crash any software. [But the same use does not crash any version of Opera.] I don't recall seeing anyone say that. Where you deleting random files in the Firefox directory or something?
7. I don't like the way you worded your bug report. [So, I didn't read it or think about it.] I don't recall seeing anyone say that. However, if your bug report is unreadable, it makes sense for the developer to move on to something he/she can actually understand...while at the same time letting the reporter know that he/she needs to write clearly for the problem to be understood so it can get addressed.
8. You should run a debugger and find what causes this problem yourself. [Then when you have done most of the work, tell us what causes the problem, and we may fix it.] Well, if no developers can reproduce it and the symptoms/steps to reproduce don't make it apparent where the problem lies, they can't do anything unless someone who can reproduce it does use debugging
This means that adding 2G of page space may not cost anything, but adding 2.5G may suddenly take up another chunk of real, non-pageable memory because the page table cannot itself be paged.
That's not true. For one thing, in most architectures, the page table size depends on the virtual address space size, which is fixed (e.g. 4GB for 32-bit systems). The page table is also usually heirarchical, which means that only the 4KB top level of the hierarchy needs to remain resident; the rest of the page table can be swapped. Even so, a full page table for a 32-bit address space is usually about 4MB per process (with standard 4KB pages), so when we're talking GBs of RAM, it's negligible.
Are air conditioning cost savings factored into these numbers? TFA doesn't mention AC costs. I would imagine that a few hundred watts of extra heat in a room makes the AC kick in more often, and switching bulbs might improve that.
The only way you'd get 30fps is if cut your ray trace depth to 1 or 2, used a couple of lights, cut the screen res down and forgot about fixing jaggies. It would look terrible. Oh and find time for all the other things that apps and games must do.
The Intel research paper that inspired TFA's author actually did benchmarks, and their scenes were pretty complex. Basically, raytracing's complexity scales with the log of the number of triangles in the scene, whereas the techniques currently used in GPUs scale linearly. At about 1M triangles per scene, even though the GPU is highly optimized and very parallel, a dual-cpu software raytracer can outperform the GPU.
Raytracing takes a tremendous amount of power - apps that demonstrate it in realtime usually run quite choppy If you read the Intel paper that inspired TFA's author to write his ill-informed article, you'll see that raytracing scales better with scene complexity, and Intel did benchmarks to show that after about 1M triangles per scene, software raytracers will outperform hardware GPUs using triangle pipelines (e.g. openGL, directX, shaders).
Sure, once we get to the point where there's enough processing power to deal with this well enough in realtime, it will happen The benchmarks in the Intel paper show that we are very close to that point right now.
I've heard from people in the industry that it has to do with getting the magnetic tape (mentioned by the grandparent) out of the door on its way to the fab, and is not directly related to the time the masks are created.
In SeaMonkey, that behavior is easy to do without any extensions. Just change the default cookie policy to only allow session cookies, and then add sites you trust to the list of sites that are allowed to set cookies. Here are my settings - this lets me stay logged in to sites like slashdot, amazon, have my bank remember my state, etc, without a persistent cookie from google.
That's because the UI is written in XUL, and the installer includes all the libraries for it, for all win32 platforms. Not all software for windows is so lucky and portable. You're mistaken about windows apps being portable.
You're full of it. If you've ever read Raymond Chen's blog you'd know just how much work Microsoft puts into maintaining binary compatibility - and the results show. Maybe you're the one person in a million who uses the few applications that do break, but in my experience, when upgrading to new Windows versions, only a tiny number of programs have problems (mostly games, which tend to abuse low-level features... Raymond's blog provides numerous examples where the applications that do break tend to be misusing APIs).
Getting back to SeaMonkey, it's not like the whole backend is reimplemented for each Windows version. The vast majority of the code really isn't at all affected by the Windows version. There's a lot of C++ code in SeaMonkey too (it's nowhere near being just XUL + JS on top of Gecko), and of all the SeaMonkey and Gecko C++ I've written I've only had to worry about the Windows version once - when I was modifying splash screen code to take advantage of new Windows 2000 features. There are certainly other cases where the code is optimized and takes advantage of features of later Windows version, but it's rarely more than a tiny change to accomodate all versions of Windows. I don't recall ever worrying about the Windows version in the rest of my patches at all.
Seriously, have you ever looked at the seamonkey download page where they offer a Fedora Core rpm build?
If you want the ability to be able to download and install, just use Fedora. Don't bitch if you're using a geek Linux like Ubuntu or Gentoo or Slackware or something. Fedora is a pretty usable Desktop OS right now, and most download sites offer rpm builds of their software. Not everything needs to be in a yum repository.
So if I want even non-proprietary applications to be readily available, I have to use one of a tiny number of distros (ignoring the fact that I'm sure there's some other project that provides DEBs but not RPMs). That seems to me like you actually don't have any real choices in the Linux world.
Look, there are other problems with desktop Linux, but the ones you cite aren't the bad ones. Hardware compatibility for example. Or kernel modules you need to recompile every single bloody kernel update. Drivers that only work under ndiswrapper. WPA support in Linux wireless-tools package instead of wpa_supplicant. Those are issues. Wireless support should be friggin' perfect by now, yet lags behind the windows world by a long shot. Those are barriers to penetration much more than the availability of a binary installer (which btw some companies also offer).
Those are certainly larger barriers to adoption, but I do think that the more limited binary compatibility with Linux is not something that should be ignored.
Depends. Do all 9x boxen have the.net runtime? Do they all use the same MFC? Only the most basic program can you make it run on any platform. Or are you coding in Java??? That's BS. SeaMonkey (and Firefox, and Thunderbird, and thousands of other appliactions) isn't a.net application or trivial MFC application, yet somehow runs on all versions of Windows from the past decade (even NT 3.51 with some minor caveats!). It's also not written in Java. It's a pretty serious piece of software.
Odd, I use FC5, and I use third party yum repositories for any software not officially provided by the main Fedora repository. [snip] See comments above about third party repositories. If you want to be bleeding edge, that's your problem, not the distro's.
So basically what you're saying is, in order to get an equally good experience as a user when your friend says, "Hey, there's this new SeaMonkey project that continues the Mozilla suite and adds some cool features", you have to hunt for third-party repositories and set them up in your package manager? Explain to me how this is not more complicated than Windows where you just go to the program's site and download the installer.
Only if they want to develop proprietary software for Linux.
If they provide the source, then whoever maintains the distro is the only one who has to worry about issues that you are fretting over.
That's the whole purpose of distros.
Even for OSS, that's just not the same as being able to distribute one package that works everywhere. On Windows (9x, 2k, XP Home, XP Pro, Vista's 7 versions), I can ship one binary package that works for everybody. Microsoft doesn't have to approve my package before making it easily available to users - any Windows user can download my one simple installer and have it work for them regardless of their version. Now look at Linux: there are many different distros, with many different package formats. I'd have to provide RPMs, DEBs, tarballs, and probably multiple versions in each format (since it might depend on different packages for different distros). Users would have to know which package to download. If the experience is going to be easy, I have to beg the distro's maintainer to provide an official package--some distros are very slow to add new products.
A real-world example of this is SeaMonkey. How long will it be until Debian users can install the software easily? Windows users can have the latest version as soon as we ship it. Linux users generally have to wait for their distro to provide an updated package. We do provide tarballs which you can extract anywhere, but that's not really user-friendly... we also provide an installer, but then you're using a method of adding software other than your distro's standard package management. We do ship source, and anyone is welcome to build it and include it in distros, but the vast majority of people just want to install a binary using whatever method they normally use (e.g. google for the website, download an installer, or search Synaptic, etc).
As much as I like AMD, I have to say that if Intel and nVidia teamed up they would probably beat the crap out of AMD + ATi.
People say that, but I have to wonder what Intel has to gain. I mean, they're already the biggest player in the graphics industry when it comes to market-share, so they clearly have the know-how to build graphics chips. Sure, they don't currently go after the enthusiast market, but there might be reasons for that: 1. Lower margins - Nvidia's gross margin is under 40%, and Intel's is close to 60%. 2. Huge time-to-market pressures. Right now, Intel and AMD ship products every few years, and make sure they work pretty well before shipping them. On the other hand, anyone who's bought bleeding-edge video cards know that they're buggy as hell until you get drivers that work around the problems because the companies don't really care whether the product works any longer than required to survive through the standard benchmarks.
Those are mostly kernel-related jobs - for server chips, having the OS kernel take full advantage of processors is a big deal, and Linux is a pretty big OS in the server arena.
When it comes to ATI/nvidia, however, Linux users make up a much smaller part of their target market (gamers).
That's probably because AMD missed earnings estimates - most of the drop happened between closing yesterday and opening today, not after The Inq's story.
See, reports like this are why developers get jaded. Hundreds of people say, "use the browser for 30 minutes". Developers use the browser for days and don't experience the problem. Now what? The user is generally either unable or unwilling to get into the nitty gritty of real leak hunting, so nothing can be done. The developer gets frustrated, wondering where this problem is that he can't find.
Fortunately, David Baron wrote the Leak Monitor extension, that looks for a relatively common type of leak, which you can install, but it doesn't catch everything.
Firefox 3.0 is at least a year in the future, mid-2007 that is. If you haven't switched from W98 nearly 10 years after it's been released, you're asking for trouble no matter what.
Not only that, but Firefox 2.0 will get security updates for quite a while (just like Firefox 1.0 did), so it really will be a long time before Windows 98 users have no up-to-date browser available.
I wonder if cell phones are being used to soften people up to this idea - consider camera phones. It costs money to get your picture off the camera through your provider. You might have a Bluetooth-capable phone like the Motorola E815, but Verizon disables the Bluetooth OBEX profile so you can't transfer files. You can either buy a $30 USB cable to hack the phone and re-enable OBEX, or pay to get your own content.
The only good debuggers I've used were part of IDEs. I don't care what linux geeks say - if they'd get past their "Micro$oft is teh satan!!1!" attitude, they'd discover how much they're missing out on (the Visual Studio debugger) when they use stuff like gdb/ddd. If you want your students to grow up using debuggers, give them an IDE. If you're ok with them deciding printf-debugging (i.e. printf's everywhere) is better than figuring out how to use gdb, well, have them use independent tools.
Last time I checked, speed of electron flow is only based on the material around it. Higher dialectric constant = lower speed of propgaition. Transmission lines aren't voodoo science, they are a property of the electrical length of the line and the rate of change of the signal on that line. It does not change the rate of propagation at all. Whether a given wire is 1" long, or 200 miles long, it will not change the speed of propagation.
I didn't say electron flow speed changes. I said signal propagtion speed changes, which is true, because if I send a "1" down a long transmission line, the receiver will get it faster than they'd get it if I send a "1" using RC-style signalling. As I tried to explain before, in a normal signalling scheme, you charge an entire line up to Vdd or Gnd, and don't detect a 1 or 0 until the signal crosses Vdd/2. Take an empty trough and start filling it up; see how long it takes the water level to reach half way up on the far side. It'll cross the half way point at the far side pretty soon after it crosses at the near side, but actually filling and emptying it will still take a while. With transmission line signalling, however, you never actually charge/discharge the whole line, but send a wave down it instead. Take a trough of water and make a ripple, then on the receiving side observe the ripple. If you want to read a proposal for on-chip transmission lines, read this.
There are a lot of issues involved with using transmission lines (for example, wires have to be long before transmission-line signalling becomes better, and you have to do impedance matching at the receiver to avoid reflections, and based on the paper I linked to, your wires need to be wide and thick), but they do offer some very cool properties.
Not to be cheeky, but it's quite easy to change a sine wave into a square wave: Schmidt trigger. While I can't rule this out entirely, I would imagine that if it was more economical to produce an LRC resonator, it would be built into devices already. These circuits have been around for decades. It's very difficult to beat quartz crystals in terms of stability, ease of use, and power consumption.
I didn't say it was a flawless idea, and I also didn't say it was a stupid idea. I DID say you have to design your circuits differently (i.e. your flip flops do schmitt-trigger-like things to compensate for the slow slew rates). I brought it up because it was an example of charge recovery that works in the real world. It does have downsides, but every option has downsides (be it power, skew, manufacturability, whatever). Based on the presentation I saw, the downsides of that particular clocking method are enough to keep it out of mass-produced designs for a while, but that doesn't mean somebody else might not have found a way to make charge-recovering clocks more realistic. It's worthwhile research (meaning it might not be in the CPU you buy tomorrow, it might not be in any mass produced CPU ever, but it might also lead to a design that IS mass produced in the future, based on the knowledge gained from this research).
Wrong. The clock drives into a high impedance node. (The CMOS receivers on the other side of the clock line). CMOS drivers do have the problem of connecting to ground temporarily during switching - more akin to spilling some of the water out of the bucket as you pour it, not pouring it entirely on the ground. This can be overcome using clocks that are 90deg out of phase.
That's not what I was talking about. Short-circuit current is not a big deal as long as your signal slew rates are good.
And if the cap that you're talking about is the 10pF or so that is on the gate of the reciever CMOS - there are larger fish to fry power wise than this minimal capacitance.
I mentioned only gate cap on the clock receivers to simplify things. Since you're goin
Slashdot Mirror
It was actually on digg a month ago, but whoever submitted the latest digg version linked to his blog instead of the actual page to get around their dupe detection.
Bump mapping definitely works with raytracing. In college I wrote a raytracer for a class - bump map support is not difficult.
You're a known troll, and I'm pretty sure I've replied to a very similar troll of yours before, but I'll bite for the benefit of anyone else reading this thread.
1. Maybe this bug is fixed in the nightly build.
That's because dozens of bugs are fixed every day and there are usually a lot of days of development between the released version and the latest nightly builds at the time someone reports a bug. If it's not trivial to reproduce, it's not a good use of the developer's time, since hundreds of bug reports are filed daily. If each reporter takes 5 mintes to try a nightly build, the average per-user time is going to be 5 extra minutes. If developers have to try convoluted steps to reproduce per bug, it's going to be hours of wasted time per developer.... even if the steps to reprdoce are simple, if the developer doesn't experience the bug in a nightly build, it's a valid question. The bug is either fixed in that nightly build, or other factors make it a works-for-me for the developer (for example, a changed preference setting). The only way to tell the two apart is to ask the user to test in a newer build.
2. Yes, this bug exists, but other things are more important.
What, you think that just because an icon that's off by one pixel somewhere bothers you a lot, they should fix that before they fix actual functionality issues, or accessibility issues, or crashes, or add new features that will benefit hundreds of thousands of users? What kind of stupid complaint is this? Everybody intelligent prioritizes tasks.
3. No one has posted a TalkBack report. [If they had read the bug report, they would know that there is never a TalkBack report, because the bug crashes TalkBack, too, or a TalkBack report is not generated.]
I've DEFINITELY responded to this before.
4. If you would just give us more information, we would fix this bug.
I've responded to this too. I guess you just drop this list on any bug that mentions Mozilla. Anyhow, as I would have said before, do you think developers are clairvoyant? If you file a bug that says, "The URL bar is broken", what do you expect? If the developers don't have enough information to reproduce your bug, or can't reproduce it themselves, well, they need more information.
5. This bug report is a composite of other bugs, so this bug report is invalid. [The other bugs aren't specified.]
I'm not going to point out further comments I've addressed before. This is a legitimate reason a bug is invalid. However, it is fair to complain that whoever closed the bug did not specify the bug #s. Do it in the bugs, not on slashdot, because it will be seen if it's in the bug report. Complain on IRC if it's specific people doing it.
6. You are using Firefox in a way that would crash any software. [But the same use does not crash any version of Opera.]
I don't recall seeing anyone say that. Where you deleting random files in the Firefox directory or something?
7. I don't like the way you worded your bug report. [So, I didn't read it or think about it.]
I don't recall seeing anyone say that. However, if your bug report is unreadable, it makes sense for the developer to move on to something he/she can actually understand...while at the same time letting the reporter know that he/she needs to write clearly for the problem to be understood so it can get addressed.
8. You should run a debugger and find what causes this problem yourself. [Then when you have done most of the work, tell us what causes the problem, and we may fix it.]
Well, if no developers can reproduce it and the symptoms/steps to reproduce don't make it apparent where the problem lies, they can't do anything unless someone who can reproduce it does use debugging
Fortunately, the suite still exists as SeaMonkey.
This means that adding 2G of page space may not cost anything, but adding 2.5G may suddenly take up another chunk of real, non-pageable memory because the page table cannot itself be paged.
That's not true. For one thing, in most architectures, the page table size depends on the virtual address space size, which is fixed (e.g. 4GB for 32-bit systems). The page table is also usually heirarchical, which means that only the 4KB top level of the hierarchy needs to remain resident; the rest of the page table can be swapped. Even so, a full page table for a 32-bit address space is usually about 4MB per process (with standard 4KB pages), so when we're talking GBs of RAM, it's negligible.
Are air conditioning cost savings factored into these numbers? TFA doesn't mention AC costs. I would imagine that a few hundred watts of extra heat in a room makes the AC kick in more often, and switching bulbs might improve that.
The only way you'd get 30fps is if cut your ray trace depth to 1 or 2, used a couple of lights, cut the screen res down and forgot about fixing jaggies. It would look terrible. Oh and find time for all the other things that apps and games must do.
The Intel research paper that inspired TFA's author actually did benchmarks, and their scenes were pretty complex. Basically, raytracing's complexity scales with the log of the number of triangles in the scene, whereas the techniques currently used in GPUs scale linearly. At about 1M triangles per scene, even though the GPU is highly optimized and very parallel, a dual-cpu software raytracer can outperform the GPU.
Raytracing takes a tremendous amount of power - apps that demonstrate it in realtime usually run quite choppy
If you read the Intel paper that inspired TFA's author to write his ill-informed article, you'll see that raytracing scales better with scene complexity, and Intel did benchmarks to show that after about 1M triangles per scene, software raytracers will outperform hardware GPUs using triangle pipelines (e.g. openGL, directX, shaders).
Sure, once we get to the point where there's enough processing power to deal with this well enough in realtime, it will happen
The benchmarks in the Intel paper show that we are very close to that point right now.
I've heard from people in the industry that it has to do with getting the magnetic tape (mentioned by the grandparent) out of the door on its way to the fab, and is not directly related to the time the masks are created.
Oops... I missed your note at the top in italics (thought you were just quoting the grandparent)
Where have I seen this post before.... oh right... on Slashdot, by other people.
In SeaMonkey, that behavior is easy to do without any extensions. Just change the default cookie policy to only allow session cookies, and then add sites you trust to the list of sites that are allowed to set cookies. Here are my settings - this lets me stay logged in to sites like slashdot, amazon, have my bank remember my state, etc, without a persistent cookie from google.
That's because the UI is written in XUL, and the installer includes all the libraries for it, for all win32 platforms. Not all software for windows is so lucky and portable. You're mistaken about windows apps being portable.
You're full of it. If you've ever read Raymond Chen's blog you'd know just how much work Microsoft puts into maintaining binary compatibility - and the results show. Maybe you're the one person in a million who uses the few applications that do break, but in my experience, when upgrading to new Windows versions, only a tiny number of programs have problems (mostly games, which tend to abuse low-level features... Raymond's blog provides numerous examples where the applications that do break tend to be misusing APIs).
Getting back to SeaMonkey, it's not like the whole backend is reimplemented for each Windows version. The vast majority of the code really isn't at all affected by the Windows version. There's a lot of C++ code in SeaMonkey too (it's nowhere near being just XUL + JS on top of Gecko), and of all the SeaMonkey and Gecko C++ I've written I've only had to worry about the Windows version once - when I was modifying splash screen code to take advantage of new Windows 2000 features. There are certainly other cases where the code is optimized and takes advantage of features of later Windows version, but it's rarely more than a tiny change to accomodate all versions of Windows. I don't recall ever worrying about the Windows version in the rest of my patches at all.
Seriously, have you ever looked at the seamonkey download page where they offer a Fedora Core rpm build?
If you want the ability to be able to download and install, just use Fedora. Don't bitch if you're using a geek Linux like Ubuntu or Gentoo or Slackware or something. Fedora is a pretty usable Desktop OS right now, and most download sites offer rpm builds of their software. Not everything needs to be in a yum repository.
So if I want even non-proprietary applications to be readily available, I have to use one of a tiny number of distros (ignoring the fact that I'm sure there's some other project that provides DEBs but not RPMs). That seems to me like you actually don't have any real choices in the Linux world.
Look, there are other problems with desktop Linux, but the ones you cite aren't the bad ones. Hardware compatibility for example. Or kernel modules you need to recompile every single bloody kernel update. Drivers that only work under ndiswrapper. WPA support in Linux wireless-tools package instead of wpa_supplicant. Those are issues. Wireless support should be friggin' perfect by now, yet lags behind the windows world by a long shot. Those are barriers to penetration much more than the availability of a binary installer (which btw some companies also offer).
Those are certainly larger barriers to adoption, but I do think that the more limited binary compatibility with Linux is not something that should be ignored.
Depends. Do all 9x boxen have the .net runtime? Do they all use the same MFC? Only the most basic program can you make it run on any platform. Or are you coding in Java??? .net application or trivial MFC application, yet somehow runs on all versions of Windows from the past decade (even NT 3.51 with some minor caveats!). It's also not written in Java. It's a pretty serious piece of software.
That's BS. SeaMonkey (and Firefox, and Thunderbird, and thousands of other appliactions) isn't a
Odd, I use FC5, and I use third party yum repositories for any software not officially provided by the main Fedora repository.
[snip]
See comments above about third party repositories. If you want to be bleeding edge, that's your problem, not the distro's.
So basically what you're saying is, in order to get an equally good experience as a user when your friend says, "Hey, there's this new SeaMonkey project that continues the Mozilla suite and adds some cool features", you have to hunt for third-party repositories and set them up in your package manager? Explain to me how this is not more complicated than Windows where you just go to the program's site and download the installer.
Only if they want to develop proprietary software for Linux.
If they provide the source, then whoever maintains the distro is the only one who has to worry about issues that you are fretting over.
That's the whole purpose of distros.
Even for OSS, that's just not the same as being able to distribute one package that works everywhere. On Windows (9x, 2k, XP Home, XP Pro, Vista's 7 versions), I can ship one binary package that works for everybody. Microsoft doesn't have to approve my package before making it easily available to users - any Windows user can download my one simple installer and have it work for them regardless of their version. Now look at Linux: there are many different distros, with many different package formats. I'd have to provide RPMs, DEBs, tarballs, and probably multiple versions in each format (since it might depend on different packages for different distros). Users would have to know which package to download. If the experience is going to be easy, I have to beg the distro's maintainer to provide an official package--some distros are very slow to add new products.
A real-world example of this is SeaMonkey. How long will it be until Debian users can install the software easily? Windows users can have the latest version as soon as we ship it. Linux users generally have to wait for their distro to provide an updated package. We do provide tarballs which you can extract anywhere, but that's not really user-friendly... we also provide an installer, but then you're using a method of adding software other than your distro's standard package management. We do ship source, and anyone is welcome to build it and include it in distros, but the vast majority of people just want to install a binary using whatever method they normally use (e.g. google for the website, download an installer, or search Synaptic, etc).
Yeah, because there are no good uses at all.
As much as I like AMD, I have to say that if Intel and nVidia teamed up they would probably beat the crap out of AMD + ATi.
People say that, but I have to wonder what Intel has to gain. I mean, they're already the biggest player in the graphics industry when it comes to market-share, so they clearly have the know-how to build graphics chips. Sure, they don't currently go after the enthusiast market, but there might be reasons for that:
1. Lower margins - Nvidia's gross margin is under 40%, and Intel's is close to 60%.
2. Huge time-to-market pressures. Right now, Intel and AMD ship products every few years, and make sure they work pretty well before shipping them. On the other hand, anyone who's bought bleeding-edge video cards know that they're buggy as hell until you get drivers that work around the problems because the companies don't really care whether the product works any longer than required to survive through the standard benchmarks.
well corporations are shizophrenic, but: http://www.amd-jobs.de/de/einstieg/freiestellen_os rc.php
Those are mostly kernel-related jobs - for server chips, having the OS kernel take full advantage of processors is a big deal, and Linux is a pretty big OS in the server arena.
When it comes to ATI/nvidia, however, Linux users make up a much smaller part of their target market (gamers).
That's probably because AMD missed earnings estimates - most of the drop happened between closing yesterday and opening today, not after The Inq's story.
See, reports like this are why developers get jaded. Hundreds of people say, "use the browser for 30 minutes". Developers use the browser for days and don't experience the problem. Now what? The user is generally either unable or unwilling to get into the nitty gritty of real leak hunting, so nothing can be done. The developer gets frustrated, wondering where this problem is that he can't find.
Fortunately, David Baron wrote the Leak Monitor extension, that looks for a relatively common type of leak, which you can install, but it doesn't catch everything.
Sure, everyone breaks laws, but do you really want to hire someone stupid enough to advertise that (and provide photographic evidence) on the web?
Firefox 3.0 is at least a year in the future, mid-2007 that is. If you haven't switched from W98 nearly 10 years after it's been released, you're asking for trouble no matter what.
Not only that, but Firefox 2.0 will get security updates for quite a while (just like Firefox 1.0 did), so it really will be a long time before Windows 98 users have no up-to-date browser available.
I wonder if cell phones are being used to soften people up to this idea - consider camera phones. It costs money to get your picture off the camera through your provider. You might have a Bluetooth-capable phone like the Motorola E815, but Verizon disables the Bluetooth OBEX profile so you can't transfer files. You can either buy a $30 USB cable to hack the phone and re-enable OBEX, or pay to get your own content.
The only good debuggers I've used were part of IDEs. I don't care what linux geeks say - if they'd get past their "Micro$oft is teh satan!!1!" attitude, they'd discover how much they're missing out on (the Visual Studio debugger) when they use stuff like gdb/ddd. If you want your students to grow up using debuggers, give them an IDE. If you're ok with them deciding printf-debugging (i.e. printf's everywhere) is better than figuring out how to use gdb, well, have them use independent tools.
Last time I checked, speed of electron flow is only based on the material around it. Higher dialectric constant = lower speed of propgaition. Transmission lines aren't voodoo science, they are a property of the electrical length of the line and the rate of change of the signal on that line. It does not change the rate of propagation at all. Whether a given wire is 1" long, or 200 miles long, it will not change the speed of propagation.
I didn't say electron flow speed changes. I said signal propagtion speed changes, which is true, because if I send a "1" down a long transmission line, the receiver will get it faster than they'd get it if I send a "1" using RC-style signalling. As I tried to explain before, in a normal signalling scheme, you charge an entire line up to Vdd or Gnd, and don't detect a 1 or 0 until the signal crosses Vdd/2. Take an empty trough and start filling it up; see how long it takes the water level to reach half way up on the far side. It'll cross the half way point at the far side pretty soon after it crosses at the near side, but actually filling and emptying it will still take a while. With transmission line signalling, however, you never actually charge/discharge the whole line, but send a wave down it instead. Take a trough of water and make a ripple, then on the receiving side observe the ripple. If you want to read a proposal for on-chip transmission lines, read this.
There are a lot of issues involved with using transmission lines (for example, wires have to be long before transmission-line signalling becomes better, and you have to do impedance matching at the receiver to avoid reflections, and based on the paper I linked to, your wires need to be wide and thick), but they do offer some very cool properties.
Not to be cheeky, but it's quite easy to change a sine wave into a square wave: Schmidt trigger. While I can't rule this out entirely, I would imagine that if it was more economical to produce an LRC resonator, it would be built into devices already. These circuits have been around for decades. It's very difficult to beat quartz crystals in terms of stability, ease of use, and power consumption.
I didn't say it was a flawless idea, and I also didn't say it was a stupid idea. I DID say you have to design your circuits differently (i.e. your flip flops do schmitt-trigger-like things to compensate for the slow slew rates). I brought it up because it was an example of charge recovery that works in the real world. It does have downsides, but every option has downsides (be it power, skew, manufacturability, whatever). Based on the presentation I saw, the downsides of that particular clocking method are enough to keep it out of mass-produced designs for a while, but that doesn't mean somebody else might not have found a way to make charge-recovering clocks more realistic. It's worthwhile research (meaning it might not be in the CPU you buy tomorrow, it might not be in any mass produced CPU ever, but it might also lead to a design that IS mass produced in the future, based on the knowledge gained from this research).
Wrong. The clock drives into a high impedance node. (The CMOS receivers on the other side of the clock line). CMOS drivers do have the problem of connecting to ground temporarily during switching - more akin to spilling some of the water out of the bucket as you pour it, not pouring it entirely on the ground. This can be overcome using clocks that are 90deg out of phase.
That's not what I was talking about. Short-circuit current is not a big deal as long as your signal slew rates are good.
And if the cap that you're talking about is the 10pF or so that is on the gate of the reciever CMOS - there are larger fish to fry power wise than this minimal capacitance.
I mentioned only gate cap on the clock receivers to simplify things. Since you're goin