I said BigDecimal is appropriate for most business use cases, especially when dealing with money, as you can control the precision and rounding behavior. The problem with floating point formulas is that they don't always round in the way you want or need them to. If you've ever applied percentage discounts and then added up the results you will see that iusing float or double often causes you to be off by one or two cents. Here is a good post on the problem with relevant examples.
Stated another way, if you are collecting a floating point value as input, chances are it has to deal with GIS coordinates, monetary values, grade point average, or perhaps some scientific value with known precision, in which case BigDecimal would be more appropriate and therefore immune to this particular problem.
NumberConverter (which uses DecimalFormat.parse) will produce either a Long or a Double (if the value will not fit into a Long). (I was mistaken in an earlier post where I stated that it produces a BigDecimal. You can specify BigDecimal parsing using DecimalFormat.setParseBigDecimal, but this is not the default.) I looked at the source code for DigitFormat on grepcode and it looks like Sun's DecimalFormat implementation parses all the digits in the input string as a DigitList object, which then reconstructs the string before calling Double.parseDouble. The result is that "2.2250738585072012e-308" becomes "2.2250738585072014" before being passed into Double.parseDouble. So if you're using DecimalFormat or, for example, (which is backed by javax.faces.convert.NumberConverter, which uses DecimalFormat) then you should be safe.
Well, technically all JSF apps are also servlet-based, and I was initially concerned that everything was affected based on comment #53 in the source article, but I tried the header on my local applications with no ill effects (my application does use resource bundles and would by necessity look at the locale headers). I also looked at jmx-console and web-console to make sure they were okay--these are by and large basic servlet/JSP apps. (JBoss 5.1, Java 1.6.0_22 64 bit.)
The JVM itself is definitely affected, as the following code results in infinite loops/freezes:
package foo;
public class Foo {
public static void main(String... args) {
Double.parseDouble("2.2250738585072012e-308");
}
}
So either you have to write code to explicitly parse headers as floats/doubles, or there's some bug in some legacy framework(s).
Either way, JSF has been around since 2004, and recent demand for AJAX, SOAP, social network integration, and other modern features would seem to drive newer technologies. So there are probably a significant number of applications affected, but they are probably still in the minority.
I haven't used floats or doubles in a long time. From a business perspective (think monetary values) it almost always makes more sense to use BigDecimal and apply rounding rules, particularly if those values are stored in a database where scale and precision are known or required. I would imagine the same would be true for scientific values, GIS coordinates, etc. (anything with a known precision). The only use for float/double that comes to mind is something where absolute precision isn't critical and speed is important, such as graphics/physics calculations for games, in which case you generally wouldn't be parsing user-entered values anyway.
Also, the default/packaged JSF numeric input converters produce either Long or BigDecimal values (per spec) depending on whether a decimal is present, so this should only affect a very small subset of use cases that are easily patched or avoided (old JSP/servlet code, Struts, etc.)
Bulldozer will come out sometime this year (summer-ish), which will mean two things: first, there will be a new chipset (9-series with AM3+ socket) and 8-core chip (32nm process) from AMD with all the new bells and whistles if you want the latest and greatest; and second, the Athlon and Phenom CPUs and 8-series motherboards will get a lot cheaper. Might be worth the wait, at least for the new AM3+ boards, which will also support a cheap Athlon or Phenom until the Bulldozer CPUs show up/get cheaper.
Not really. A "rolling" standard allows the periodic adoption and standardization of a single tag or attribute, which would allow progress on that front while the vendors continue to bicker about the other proposed changes. It's like of like the JCP process was (sans incorporation into a major version release). Different ideas are proposed: some get formalized and adopted and some languish. Nothing wrong with that. The result is that you get a browser or update with support for (for example) WSR-1234 which might be embedded video or canvasing or something, and after a (short) while they all will pretty much have it. And because it's incremental, it's easier to implement and release updates quickly, rather than rewriting the entire engine every two years.
It never had complete control, but it did its job. It established a level playing field and and brought parity (more or less) to four different browser engines. Now that there *is* competition, all four vendors are busy as bees trying to add new features and mimic the new features added by the other vendors. So we don't need a standard per se, as long as we have users that have iPhones expecting that a web page will work the same way on their desktops.
So kudos to the W3C for making it viable for other browsers to come to market and compete, and kudos to Mozilla for making that dream a reality. Now it's all about innovation and compatibility.
Back in the day, searching for illegal downloads using normal search terms didn't really yield any useful results. Instead, you had to add "z" to the end of everything... for example "warez", "mp3z", "serialz", etc. And now "torrentz" I suppose. So I doubt that censoring copyright-infringement vernacular will have any impact whatsoever on legitimate uses of P2P software, especially considering that normal search terms will result in any number of legitimate MP3/video download sites. And for crying out loud, it's on the *instant* search, which has got to be the least useful feature I have ever seen in any search engine.
Not entirely. You should be able to determine the QoS from your house to the local MUX (which I can and do with my DIR-655 QoS controls), but beyond that all the traffic is munged together on the backbone, so there are other considerations.
I think carriers must be allowed to prioritize *types* of traffic, but should not be able to discriminate based on the source of traffic. For example, RTP requests for VoIP/IPTV should take priority over web browsing (within reason) to effect the quality of service one would expect using such services. However, de-prioritizing NetFlix traffic in favor of Comcast traffic should be a big no-no.
If carriers had to give the same priority to spam, P2P, HTTP, etc. as it did to RTP (or more generally, UDP) traffic, then we'd be in a world of hurt as adoption rates for those services increase.
Re:Making it just as heavy as Gnome and KDE now?
on
Xfce 4.8 Released
·
· Score: 1
I still get Konqueror crashes almost daily. It all seems to point back to Nepomuk and Akonadi. I'm going to give 4.6 a shot when Natty comes out, and if they haven't figured out Akonadi by then I give up.
Most of that can be addressed with virtualization. A VM on a beefy workstation is better than native on a 4-year old laptop, and it's secure enough provided it all stays within the VM.
And imagine how easy it would be to farm out VDIs with everything pre-built and in a working state. Something broken? Re-download the VDI, log in using your credentials, and wait for all the logon scripts to initialize/personalize your desktop and E-mail.
COTS stuff (closed source) is appropriate if your company has a budget and your interoperability requirements are low. If they want to spend money on a product or support, then that's their business.
Where open source excels in business is where you have unfunded mandates and/or a requirement for deep integration with other software.
(Note: my answer would be very different if your boss was asking you to do more work for the same money, but as you didn't say anything about that I assume that isn't the case.)
I really don't see why it would be any different. Your original statement was spot on: if the role dictates Y work in Z time with salary X, you either accept that or you don't. You can't find a different job; they can find a different employee. If you both decide that you are valuable to one another, you can reach some sort of agreement.
The key point is good faith. Will the extra work actually benefit the project, or are you just thrashing and logging hours so that it *looks* like your accomplishing something? Will your manager share the credit, and make sure your name comes up for merit-based compensation (President's club, spot bonuses, etc.)? Will you get comp time, or will unused leave get paid out at the end of the year? That sort of thing.
It may not pay off immediately, but if you establish a reputation of being a reliable team player then it will pay off eventually as promotions, etc. go around.
The last thing you want to do is be confrontational. If you don't want to work 12 hour days--then don't. Put in a little extra, maybe take short lunches, and show that you're on task. I don't think any reasonable manager would complain about that, and if he or she does, you can use that as an opportunity to provide your own perspective.
If Microsoft only supports H.264 and Google/Mozilla/Opera only supports WebM, the winner is - beyond a shadow of a doubt - Adobe and flash
And Google. If Adobe/Flash retain their position as the pre-eminent platform for video, and if Apple continues to block Flash on iOS, then Google will have an advantage over Apple when it comes do displaying video on handheld devices.
That was a vsync issue that was fixed a while ago and released as an update 10.04 (6.13.1-12 I think). I never experienced it myself. I think the drivers are on 6.13.2 now which is scheduled for Natty, but you can get it from the PPAs I think. 6.13.1 has been really solid for me.
I realize this is a troll, but I recently upgraded my system and initially couldn't boot Ubuntu. No big deal, I thought, I'll just install Windows and use that until Natty comes out, and maybe I'll have better luck with the new kernel. So to get my Windows environment up to speed I had to install a third-party, 32-bit IM app (Trillian) for which I had to register a new account I'll never use; I had to install Microsoft Security Essentials and Live Essentials (of which I only would use Live E-mail); I had to download and install OpenOffice; download and install all of my drivers for all of my devices; download and install Collab Subversion (which also requires an account registration), TortoiseSVN, and Maven; and then I had to set up paths, etc. After all that (about 10 hours of downloading and installing) I still didn't have a decent terminal and no SSH. So I had to download PuTTY, which, while good, is no substitute for gnome-terminal and GNU utils. Still no less, tail, grep, vi, symbolic links, mount utilities, etc., so I was looking at *also* installing Cygwin (32-bit!) and dealing with that hassle.
Not to mention that there were 59 critical updates that took about 3 hours to download and install.
Needless to say, about 24 hours into the change I was nearly having panic attacks at the prospect of using this system. I was seriously contemplating downgrading and sending my new parts back and eating the restocking fees.
Luckily it turns out that my Ubuntu issue was related to a hardware conflict between my old Audigy 2 card and the on-board IEEE 1394 on the new mobo (I think). Once I ripped out the Audigy I didn't have a single issue with Ubuntu. Took me all of 2 hours to install the OS and what I needed via the software center, and that including downloading and installing the 212 updates. (Note that more than half of the stuff I had to manually install under Windows was already there in the base Ubuntu install, and I didn't have to register any accounts.)
From time to time I look at hardware compatibility, video performance, etc. and think that I might be happier in Windows. And maybe I would be, if I didn't have to do anything productive. But from a development perspective Windows is Hell, and I will not go back to it by choice.
I think the issue with the open source radeon drivers isn't that the developers don't know how to implement stuff, or that it's a closed API or whatever. The problem is one of manpower. Reading the Phoronix forums it looks like there's maybe 2 guys that do the majority of the commits (for the really hard stuff anyways) and they just have too many things to do. I recall one post explaining that some kind of compiler was needed, and so one of the developers stubbed out a very simple one to be able to move forward on something else, with the intention of coming back and replacing the stubbed out compiler later, when the more critical issues were addressed. The compiler was a key component to all sorts of 3D stuff and was a critical factor in performance, but functionality and performance take a back seat to compatibility and stability.
My hope is that with the release of these open source drivers a lot of that boilerplate stuff will come with it, so that the community can truly focus on implementing newer APIs and such, although I don't know enough about video driver development to know whether that's necessarily the case.
For what it's worth, my AMD CPU and ASUS motherboard (quad core AMD 870 chipset) work just fine in Linux, as does my AMD/ATI video card. As did my previous AMD CPU/motherboard. I have yet to be disappointed by them.
I must be weird, but I love laptop-ish keyboards. I type a *lot* and have issues with RSI from time to time, but I've found that the lighter I actually have to touch a key the fewer flare-ups I have. I'm currently using a Logitech Illuminated Keyboard with some kind of hybrid ("PerfectStroke") system. I barely have to tap the keys to get a response.
This in contrast to an "ergonomic" keyboard I tried (GoldTouch) where I had to mash the keys mercilessly to get a response, which caused all sorts of issues.
I don't think I've ever had the opportunity to try a model M (or similar), but if it falls in the former category then I could definitely understand the attraction (although I absolutely could do without the noise),
I just checked and it looks like it has. I was contemplating upgrading from 4x2GB of DDR2-667 to 4x4GB, and I think the price of 16GB kits was between $400 and $500 (median) with individual 4GB sticks going for $100-$120. I see now that there are some cheaper 4GB DDR2 sticks going for around $75. Although, that's still $300 right there, which is right at what I paid for a new mobo + 16GB of DDR-1600. I don't know if prices will go any lower though... AFAIK most places are trying to ramp down production on DDR2 so they can switch to DDR3, so as long as demand exceeds supply then prices will be higher.
Anyway, I figure I'll be happier to have DDR3 in case one of them goes bad, so for me it was worth the extra effort for the upgrade.
Everything is networked, but as long as you have latency there will be a need to perform rendering locally. The stuff that needs to be sent over the network (commands, data) is already handled by HTTP (or proprietary TCP/UDP protocols).
I have never, not once, used X remotely, in the 10+ years I've been using Linux. I use Linux because, as a developer, there is no reasonable (free) alternative to the GNU tool set, console emulators, etc. available in Linux. But I have a single machine with a single monitor and I really don't need to run applications on other systems. I also use it on my Netbook because it's fast, functional, and virus free. In neither scenario do I have any need whatsoever for remotely running applications. So why have the overhead?
I would much prefer the smallest, most lightweight rendering layer possible, so that I get the maximum performance with the least CPU/GPU cycles. Running through API after API is silly 99% of the time. The problem is that with X I don't really have the option--it's always on. At least with X on top of Wayland I can run lean when I want to.
I can see where it would be useful in a server situation, but I would imagine no sane sysadmin would use Ubuntu in the server room. Ubuntu is a consumer distro that is targeting the home PC / netbook segment, which loves the shiny. For them, Wayland is a perfect fit.
The AMD drivers AFAIK are supported almost entirely by the community. There are some devs at AMD that contribute to the drivers, and AMD has been releasing specs and documentation in increments. 3D is still not fully supported on most chipsets, so you need the FGLRX drivers for that, but for normal 2D desktop operations the radeon drivers are actually faster and more stable (fewer artifacts, etc.). At least, that's been my experience. The radeon driver also supports KMS (FGLRX does not) meaning it's the only option for Wayland.
There is also a lot of developer activity on the forums (Phoronix in particular) and you can really see progress being made literally from day to day. It looks like come Christmas/early next year the open source radeon 3D stiff will start catching up to FGLRX in the upstream releases (Xorg, Mesa, Gallium) but it will probably be a while before that finds its way into most distros.
If you're a KDE user, however, you'll probably want to stick with NVidia for a little while longer. Kwin compositing does not work well with FGLRX or the radeon driver and the KDE devs insist that it's the driver (whereas Compiz runs just fine on the same drivers).
Slashdot Mirror
I said BigDecimal is appropriate for most business use cases, especially when dealing with money, as you can control the precision and rounding behavior. The problem with floating point formulas is that they don't always round in the way you want or need them to. If you've ever applied percentage discounts and then added up the results you will see that iusing float or double often causes you to be off by one or two cents. Here is a good post on the problem with relevant examples.
Stated another way, if you are collecting a floating point value as input, chances are it has to deal with GIS coordinates, monetary values, grade point average, or perhaps some scientific value with known precision, in which case BigDecimal would be more appropriate and therefore immune to this particular problem.
NumberConverter (which uses DecimalFormat.parse) will produce either a Long or a Double (if the value will not fit into a Long). (I was mistaken in an earlier post where I stated that it produces a BigDecimal. You can specify BigDecimal parsing using DecimalFormat.setParseBigDecimal, but this is not the default.) I looked at the source code for DigitFormat on grepcode and it looks like Sun's DecimalFormat implementation parses all the digits in the input string as a DigitList object, which then reconstructs the string before calling Double.parseDouble. The result is that "2.2250738585072012e-308" becomes "2.2250738585072014" before being passed into Double.parseDouble. So if you're using DecimalFormat or, for example, (which is backed by javax.faces.convert.NumberConverter, which uses DecimalFormat) then you should be safe.
Well, technically all JSF apps are also servlet-based, and I was initially concerned that everything was affected based on comment #53 in the source article, but I tried the header on my local applications with no ill effects (my application does use resource bundles and would by necessity look at the locale headers). I also looked at jmx-console and web-console to make sure they were okay--these are by and large basic servlet/JSP apps. (JBoss 5.1, Java 1.6.0_22 64 bit.)
The JVM itself is definitely affected, as the following code results in infinite loops/freezes:
package foo;
public class Foo {
public static void main(String... args) {
Double.parseDouble("2.2250738585072012e-308");
}
}
So either you have to write code to explicitly parse headers as floats/doubles, or there's some bug in some legacy framework(s).
Either way, JSF has been around since 2004, and recent demand for AJAX, SOAP, social network integration, and other modern features would seem to drive newer technologies. So there are probably a significant number of applications affected, but they are probably still in the minority.
I haven't used floats or doubles in a long time. From a business perspective (think monetary values) it almost always makes more sense to use BigDecimal and apply rounding rules, particularly if those values are stored in a database where scale and precision are known or required. I would imagine the same would be true for scientific values, GIS coordinates, etc. (anything with a known precision). The only use for float/double that comes to mind is something where absolute precision isn't critical and speed is important, such as graphics/physics calculations for games, in which case you generally wouldn't be parsing user-entered values anyway.
Also, the default/packaged JSF numeric input converters produce either Long or BigDecimal values (per spec) depending on whether a decimal is present, so this should only affect a very small subset of use cases that are easily patched or avoided (old JSP/servlet code, Struts, etc.)
Bulldozer will come out sometime this year (summer-ish), which will mean two things: first, there will be a new chipset (9-series with AM3+ socket) and 8-core chip (32nm process) from AMD with all the new bells and whistles if you want the latest and greatest; and second, the Athlon and Phenom CPUs and 8-series motherboards will get a lot cheaper. Might be worth the wait, at least for the new AM3+ boards, which will also support a cheap Athlon or Phenom until the Bulldozer CPUs show up/get cheaper.
Not really. A "rolling" standard allows the periodic adoption and standardization of a single tag or attribute, which would allow progress on that front while the vendors continue to bicker about the other proposed changes. It's like of like the JCP process was (sans incorporation into a major version release). Different ideas are proposed: some get formalized and adopted and some languish. Nothing wrong with that. The result is that you get a browser or update with support for (for example) WSR-1234 which might be embedded video or canvasing or something, and after a (short) while they all will pretty much have it. And because it's incremental, it's easier to implement and release updates quickly, rather than rewriting the entire engine every two years.
It never had complete control, but it did its job. It established a level playing field and and brought parity (more or less) to four different browser engines. Now that there *is* competition, all four vendors are busy as bees trying to add new features and mimic the new features added by the other vendors. So we don't need a standard per se, as long as we have users that have iPhones expecting that a web page will work the same way on their desktops.
So kudos to the W3C for making it viable for other browsers to come to market and compete, and kudos to Mozilla for making that dream a reality. Now it's all about innovation and compatibility.
Back in the day, searching for illegal downloads using normal search terms didn't really yield any useful results. Instead, you had to add "z" to the end of everything ... for example "warez", "mp3z", "serialz", etc. And now "torrentz" I suppose. So I doubt that censoring copyright-infringement vernacular will have any impact whatsoever on legitimate uses of P2P software, especially considering that normal search terms will result in any number of legitimate MP3/video download sites. And for crying out loud, it's on the *instant* search, which has got to be the least useful feature I have ever seen in any search engine.
Not entirely. You should be able to determine the QoS from your house to the local MUX (which I can and do with my DIR-655 QoS controls), but beyond that all the traffic is munged together on the backbone, so there are other considerations.
I think carriers must be allowed to prioritize *types* of traffic, but should not be able to discriminate based on the source of traffic. For example, RTP requests for VoIP/IPTV should take priority over web browsing (within reason) to effect the quality of service one would expect using such services. However, de-prioritizing NetFlix traffic in favor of Comcast traffic should be a big no-no.
If carriers had to give the same priority to spam, P2P, HTTP, etc. as it did to RTP (or more generally, UDP) traffic, then we'd be in a world of hurt as adoption rates for those services increase.
I still get Konqueror crashes almost daily. It all seems to point back to Nepomuk and Akonadi. I'm going to give 4.6 a shot when Natty comes out, and if they haven't figured out Akonadi by then I give up.
Real soon now...
Most of that can be addressed with virtualization. A VM on a beefy workstation is better than native on a 4-year old laptop, and it's secure enough provided it all stays within the VM.
And imagine how easy it would be to farm out VDIs with everything pre-built and in a working state. Something broken? Re-download the VDI, log in using your credentials, and wait for all the logon scripts to initialize/personalize your desktop and E-mail.
COTS stuff (closed source) is appropriate if your company has a budget and your interoperability requirements are low. If they want to spend money on a product or support, then that's their business.
Where open source excels in business is where you have unfunded mandates and/or a requirement for deep integration with other software.
(Note: my answer would be very different if your boss was asking you to do more work for the same money, but as you didn't say anything about that I assume that isn't the case.)
I really don't see why it would be any different. Your original statement was spot on: if the role dictates Y work in Z time with salary X, you either accept that or you don't. You can't find a different job; they can find a different employee. If you both decide that you are valuable to one another, you can reach some sort of agreement.
The key point is good faith. Will the extra work actually benefit the project, or are you just thrashing and logging hours so that it *looks* like your accomplishing something? Will your manager share the credit, and make sure your name comes up for merit-based compensation (President's club, spot bonuses, etc.)? Will you get comp time, or will unused leave get paid out at the end of the year? That sort of thing.
It may not pay off immediately, but if you establish a reputation of being a reliable team player then it will pay off eventually as promotions, etc. go around.
The last thing you want to do is be confrontational. If you don't want to work 12 hour days--then don't. Put in a little extra, maybe take short lunches, and show that you're on task. I don't think any reasonable manager would complain about that, and if he or she does, you can use that as an opportunity to provide your own perspective.
If Microsoft only supports H.264 and Google/Mozilla/Opera only supports WebM, the winner is - beyond a shadow of a doubt - Adobe and flash
And Google. If Adobe/Flash retain their position as the pre-eminent platform for video, and if Apple continues to block Flash on iOS, then Google will have an advantage over Apple when it comes do displaying video on handheld devices.
That was a vsync issue that was fixed a while ago and released as an update 10.04 (6.13.1-12 I think). I never experienced it myself. I think the drivers are on 6.13.2 now which is scheduled for Natty, but you can get it from the PPAs I think. 6.13.1 has been really solid for me.
I realize this is a troll, but I recently upgraded my system and initially couldn't boot Ubuntu. No big deal, I thought, I'll just install Windows and use that until Natty comes out, and maybe I'll have better luck with the new kernel. So to get my Windows environment up to speed I had to install a third-party, 32-bit IM app (Trillian) for which I had to register a new account I'll never use; I had to install Microsoft Security Essentials and Live Essentials (of which I only would use Live E-mail); I had to download and install OpenOffice; download and install all of my drivers for all of my devices; download and install Collab Subversion (which also requires an account registration), TortoiseSVN, and Maven; and then I had to set up paths, etc. After all that (about 10 hours of downloading and installing) I still didn't have a decent terminal and no SSH. So I had to download PuTTY, which, while good, is no substitute for gnome-terminal and GNU utils. Still no less, tail, grep, vi, symbolic links, mount utilities, etc., so I was looking at *also* installing Cygwin (32-bit!) and dealing with that hassle.
Not to mention that there were 59 critical updates that took about 3 hours to download and install.
Needless to say, about 24 hours into the change I was nearly having panic attacks at the prospect of using this system. I was seriously contemplating downgrading and sending my new parts back and eating the restocking fees.
Luckily it turns out that my Ubuntu issue was related to a hardware conflict between my old Audigy 2 card and the on-board IEEE 1394 on the new mobo (I think). Once I ripped out the Audigy I didn't have a single issue with Ubuntu. Took me all of 2 hours to install the OS and what I needed via the software center, and that including downloading and installing the 212 updates. (Note that more than half of the stuff I had to manually install under Windows was already there in the base Ubuntu install, and I didn't have to register any accounts.)
From time to time I look at hardware compatibility, video performance, etc. and think that I might be happier in Windows. And maybe I would be, if I didn't have to do anything productive. But from a development perspective Windows is Hell, and I will not go back to it by choice.
I think the issue with the open source radeon drivers isn't that the developers don't know how to implement stuff, or that it's a closed API or whatever. The problem is one of manpower. Reading the Phoronix forums it looks like there's maybe 2 guys that do the majority of the commits (for the really hard stuff anyways) and they just have too many things to do. I recall one post explaining that some kind of compiler was needed, and so one of the developers stubbed out a very simple one to be able to move forward on something else, with the intention of coming back and replacing the stubbed out compiler later, when the more critical issues were addressed. The compiler was a key component to all sorts of 3D stuff and was a critical factor in performance, but functionality and performance take a back seat to compatibility and stability.
My hope is that with the release of these open source drivers a lot of that boilerplate stuff will come with it, so that the community can truly focus on implementing newer APIs and such, although I don't know enough about video driver development to know whether that's necessarily the case.
For what it's worth, my AMD CPU and ASUS motherboard (quad core AMD 870 chipset) work just fine in Linux, as does my AMD/ATI video card. As did my previous AMD CPU/motherboard. I have yet to be disappointed by them.
I must be weird, but I love laptop-ish keyboards. I type a *lot* and have issues with RSI from time to time, but I've found that the lighter I actually have to touch a key the fewer flare-ups I have. I'm currently using a Logitech Illuminated Keyboard with some kind of hybrid ("PerfectStroke") system. I barely have to tap the keys to get a response.
This in contrast to an "ergonomic" keyboard I tried (GoldTouch) where I had to mash the keys mercilessly to get a response, which caused all sorts of issues.
I don't think I've ever had the opportunity to try a model M (or similar), but if it falls in the former category then I could definitely understand the attraction (although I absolutely could do without the noise),
8pen addresses this, and looks pretty cool.
That being said, they'll have to pry my keyboard out of my cold dead hands.
I just checked and it looks like it has. I was contemplating upgrading from 4x2GB of DDR2-667 to 4x4GB, and I think the price of 16GB kits was between $400 and $500 (median) with individual 4GB sticks going for $100-$120. I see now that there are some cheaper 4GB DDR2 sticks going for around $75. Although, that's still $300 right there, which is right at what I paid for a new mobo + 16GB of DDR-1600. I don't know if prices will go any lower though ... AFAIK most places are trying to ramp down production on DDR2 so they can switch to DDR3, so as long as demand exceeds supply then prices will be higher.
Anyway, I figure I'll be happier to have DDR3 in case one of them goes bad, so for me it was worth the extra effort for the upgrade.
Everything is networked, but as long as you have latency there will be a need to perform rendering locally. The stuff that needs to be sent over the network (commands, data) is already handled by HTTP (or proprietary TCP/UDP protocols).
I have never, not once, used X remotely, in the 10+ years I've been using Linux. I use Linux because, as a developer, there is no reasonable (free) alternative to the GNU tool set, console emulators, etc. available in Linux. But I have a single machine with a single monitor and I really don't need to run applications on other systems. I also use it on my Netbook because it's fast, functional, and virus free. In neither scenario do I have any need whatsoever for remotely running applications. So why have the overhead?
I would much prefer the smallest, most lightweight rendering layer possible, so that I get the maximum performance with the least CPU/GPU cycles. Running through API after API is silly 99% of the time. The problem is that with X I don't really have the option--it's always on. At least with X on top of Wayland I can run lean when I want to.
I can see where it would be useful in a server situation, but I would imagine no sane sysadmin would use Ubuntu in the server room. Ubuntu is a consumer distro that is targeting the home PC / netbook segment, which loves the shiny. For them, Wayland is a perfect fit.
The AMD drivers AFAIK are supported almost entirely by the community. There are some devs at AMD that contribute to the drivers, and AMD has been releasing specs and documentation in increments. 3D is still not fully supported on most chipsets, so you need the FGLRX drivers for that, but for normal 2D desktop operations the radeon drivers are actually faster and more stable (fewer artifacts, etc.). At least, that's been my experience. The radeon driver also supports KMS (FGLRX does not) meaning it's the only option for Wayland.
There is also a lot of developer activity on the forums (Phoronix in particular) and you can really see progress being made literally from day to day. It looks like come Christmas/early next year the open source radeon 3D stiff will start catching up to FGLRX in the upstream releases (Xorg, Mesa, Gallium) but it will probably be a while before that finds its way into most distros.
If you're a KDE user, however, you'll probably want to stick with NVidia for a little while longer. Kwin compositing does not work well with FGLRX or the radeon driver and the KDE devs insist that it's the driver (whereas Compiz runs just fine on the same drivers).