Hard to meet both requirements at work without requiring a lot of effort on your part.
If you don't mind the changes coming closer to upstream release regardless of the next 'major' release, Fedora may be best for you, but be prepared for them to make choices you don't seek out.
If you only want an app to update when you choose, and no other time, go with Ubuntu. If you have exceptions, be preparred to manage them on a case-by-case basis (I have some PPAs added to mine for projects I have enthusiast type interest in, for example). This necessitates more work, but it's the price to be paid if you care about 'key' applications and fear the rest of the system changing.
Alternatively, I would respect Fedora still if they used 2.6.31 now, and updated Fedora 12 to 2.6.32 when it released without waiting for Fedora 13. I still wouldn't use it, but I would respect them more for properly serving the needs of the enthusiast in a healthier manner.
I understand kernel module 'ABI', the only attempts to make that promise have failed miserably. 'API' (I know that kernel devs *hate* that term to describe compiling against their headers, but practically speaking...) in the '2.6.18' kernel isn't even stable.
Also, many of the features in the kernel are not safe. I have seen RHEL5.1 servers start getting system errors by going to RHEL5.2, requiring workarounds in their platform because of a change in how they managed certain things having certain edge scenarios that are made worse. Not saying it's an insurmountable problem, but not the sort of thing I want to see in a production update from 5.1 to 5.2.
In userspace, I can't recall a glibc binary incompatible change in 5.x, admittedly, but I also don't think they go crazy with the glibc features so much (however, they did jump firefox versions in a manner that broke some firefox extensions that would work in 5.1 when they jumped in 5.2, a desktop 'friendly' change, but again, a change made because they can't stand to be 'stale', even though a whole lot of 'enterprise' is entirely about 'stale' for the sake of stability and low risk of breakage with third-party software/solutions.
However, I don't see the point in sticking with 2.6.18 for stability purposes, and then turning around and making drivers that compile against 2.6.18 impossible to compile against your '2.6.18' because '2.6.18-164-el5' is nearly as much patch as it is original kernel.
First off, a disclaimer, as far as Fedora is concerned, they might as well keep doing what they are doing, or else there wouldn't me much difference between them and Ubuntu, as they have very similar release schedules and such. If someone feels like you, they have Fedora, if they feel like me, Ubuntu. Satisfying both of us with the same project would not be feasible. I simply want to be clear on what each distro does differently so that people are educated. Too often I see people play nice and be unwilling to call out the downsides of distro choices, making selecting one a more daunting task. Fedora's choices, in my opinion, cater to a certain class of enthusiasts but precludes suitability for 'everyone'.
That said, I would suggest discipline in development and forgoing features completely. I see backporting obvious bugfixes, but not features. In this case, if a feature will be in 2.6.32, either go with 2.6.31 and ignore it, or wait for 2.6.32 (i.e. the memory page dedupe feature). Backporting features and creating a relative frankenstein that is '2.6.31' in name only doesn't make sense to me. They already show they'd be willing to go to a new kernel post-release, so its not like they are even saying they have to wait 6 months. This isn't so terrible in Fedora, as the releases are at least in the near future and not a huge chasm to bridge. For RHEL, the monster they have created being called '2.6.18' holds no meaning. They've backported enough to not look like 2.6.18 did much, and yet there is so much not backported so it's not like any recent kernel either. It's an amalgamation of features/function changes that I don't like seeing in an enterprise 'service pack' series, exacerbated by that particular mix being validated only in RHEL and not the larger community.
You mention drivers, but new driver modules (frequently provided for by the hardware vendor) is a tad different from backporting major features (i.e. I think the choice of KVM in RHEL 5.4 would have been better served by waiting for RHEL6, advancing the schedule if they feel it is important enough). LSI probably already provided a driver developed against 2.6.18 and RHEL can fold that in, but don't fold in a major SCSI subsystem change while you are at it just because you think it safe. If I download a third party driver for a NIC that RHEL doesn't support, I don't want that compile to be impossible by going from RHEL5.2 to RHEL5.3, which often occurs.
It is subjective that Fedora does 'a lot more things a lot better'. They certainly have distinct aims from Ubuntu and gain some benefits, but I personally find Fedora to suffer some phenomena that Ubuntu does not:
-Out-of-the-box media/driver experience: Fedora goes purist and the out-of-the-box experience suffers for it with lack of popular codecs and optimal drivers for nVidia cards. Ubuntu caters to the user experience and takes care of this out of the box. You have to add RPM fusion repositories to make Fedora cope with this, which isn't insurmountable, but isn't out of the box.
-Fedora is not even stable within a release cycle in terms of offered featureset. I.e. I recall gaim 1.x being replaced with gaim 2.0 one day without requiring any particular update. This is good for enthusiasts who always want the cutting edge, bad for end-users who only want change at certain times they could expect (and for documenters doing screenshots). I recall once Fedora reving the kernel revision entirely without jumping releases. This wasn't bad in and of itself, but they jumped before nVidia supported it, and my X was hosed. Ubuntu is more conservative with this, knowing it will just be 6 months before a new cycle comes anyway.
-Fedora is 'too' comfortable with cutting edge changes, even to the point of releasing versions ahead of upstream *or* backporting code from future versions into older versions that upstream projects didn't want to do. For example, they backported things from the 2.6.32 branch to 2.6.31. The upstream kernel people weren't comfortable enough with the features to allow them into 2.6.31 or any release that aligned with their cycle, so they simply put 2.6.32 stuff into 2.6.31. This has been a longstanding tendency with RH (everyone probably remembers the gcc 2.96 debacle). BTW, this is even worse in RHEL, where they will backport 2.6.3x changes to 2.6.18, severely breaking third party kernel modules that code for the 'API' of 2.6.18 that gets broken by the massive amount of backports. Some third party even writes to newer 'apis', but wraps it with '> 2.6.26' sorts of ifdefs and thus assumes the 'old' api and RHEL will completely screw those assumptions. Ubuntu *usually* doesn't jump the gun (GRUB 2 is an example of going before the upstream declares 'ready' though).
-I *still* can't quite put my finger on it, but something about the Ubuntu desktop feels, subjectively to me, more whole rather than merely a conglomeration of the parts. This may simply be a matter of certain tastes they appear to me, because I can't nail it down.
You change a few characters, the block that contained those characters gets duplicated. If there is insufficient space, that write() syscall returns some errno to indicate the file system is unable to service the request. You will lose the pending data, but the original will stay intact. This allows the pool to be grown or all contents to remain readable to go to a new disk. A simple rule for storage providersd is that a mere read operation should *never* require additional disk space to succeed, and that a write needs to be dropped.
It's harder to predict what effect a change to the disk *will* have on a system (and by extension, have a precise concept of how much 'free' space you really have), but it doesn't have to be that different in behavior from a 'normal' full filesystem today, or a filesystem with sparse files that grows without any 'ls' output changes.
Any filesystem implementing copy-on-write at all, data dedupe, and/or compression is already a strategy where the risk of exhausting oversubscribed storage due to unanticipated compression ratios or uniqueness is a risk. It's a reason why you have to be pretty explicit to NetApp filers implementing these features that you are accepting the risk of exhausting allocations if you actually make use of these features to the point of advertising more storage capacity than you actually have.
You don't even need a fancy filesystem to expose yourself to this today: $ dd if=/dev/zero of=bigfile bs=1M seek=8191 count=1 1+0 records in 1+0 records out 1048576 bytes (1.0 MB) copied, 0.00426769 s, 246 MB/s jbjohnso@wirbelwind:~$ ls -lh bigfile
8.0G 2009-11-02 20:06 bigfile ~$ du -sh bigfile 1.0M bigfile
This possibility has been around a long file and the world hasn't melted. Essentially, if someone is using these features, they should be well aware of the risks incurred.
They have the 'verify' mode to do what you prescribe, though I'm presuming it comes with a hefty performance penalty.
I have no idea if they do this up front, inducing latency on all write operations, or as it goes.
What I would like to see is a strategy where it does the hash calculation, writes block to new part of disk assuming it is unique, records the block location as an unverified block in a hash table, and schedules a dedupe scan if one not already pending. Then, a very low priority io task could scan that structure for block locations that have yet to be verified, and then scan all the blocks that match its hash for sameness and update the structures to retroactively make it a single copy (effectively unlinking a block deemed duplicate after the fact). The absolute hard guarantee of sameness without a write performance penalty.
I'm very far from a filesystem designer, and I recognize the likelihood of a collision given sufficiently large block size is low, but I'd really be wary of something that relies on not having bad luck to accidentally lose data on a write due to an unlikely hash collision.
It doesn't say the precision of the flops. Unless things have recently changed, the outlandish flops spec of GPU derived compute platforms have all been 32-bit precision, whilst the TOP500 score is explicitly 64-bit precision.
By communicate, I was implying a bi-directional link. The reason I said IPv6 client and IPv4 server is to reflect the fact that it *could* be feasible with NAT to do that. IPv4 could never talk to an IPv6 host even in theory without the IPv6 endpoint starting it, but I think that would be ok if the likes of google/yahoo/every major company retained an IPv4 presence and many clients could live happily in IPv6 world since they don't have to worry about business lost because they can't be called up by random IPv4 clients, and could still happily reach IPv4-only companies.
However, those 'crappy end-user routers' require that ISPs maintain their IPv4 infrastructure. If IPv4 infrastructure must be maintained, the IPv6 infrastructure by and large ranks as a 'novelty' and as such is pretty much not on the priority list of most ISPs.
IPv6 itself isn't a premature technology. If suddenly adopted every where, the world would ultimately not have the NAT problem anymore. The problem is that no solution that would extend the address space can exist and be perfectly inter-operable with IPv4 during a transitional period.
Have some blessed strategy to have IPv6->IPv4 NAT in place at the ISP level, and it's feasible. Problem is, that would have to compete with the more straightforward case of IPv4->IPv4 NAT that is much cheaper to strategize around. Sadly, it looks more and more like the 'real' solution is the NAT we have today, as it fits the needs of 95% of the internet users even if you took their one public IP address away.
I assume he refers to the ability to realistically have more than one public address in your house, whether it be static or dynamic in nature. I personally have one public IPv4 address and maybe half a dozen devices to share it.
And to extend on his point, I will bet in the next year or so ISPs will start issuing addresses to residences that are in a private subnet range and charge people extra for not being behind a NAT gateway (if they haven't already).
Hypothetically, assuming only one tier of NAT, could be around 4 quadrillion or so. Beyond what is reasonable, but suffice to say, even the fanciest phones can get by without a universally addressable IP for 99.9% of their users, and I anticipate the cellular carriers to take full advantage of that before putting users on IPv6, effectively 'breaking' most of the 'real' internet as far as their customers would observe and think of it. A lot would be easier with managing their network with globally unique addresses, but as it stands they could segregate management of phones such that 16 million are in one 10. namespace, another 16 million are in a distinct 10. namespace, etc etc.
First and perhaps foremost, a lot of the industry has formulated a non-trivial amount of their business plan around the artificial scarcity of IPv4. It is recommended that even residences get/48 prefixes, though some have asked that to be reduced to/56, giving every person up to 255 subnets to route, each subnet being able to host 18 quintillion hosts in a globally unique fashion. Giving a singe IP address just won't cut it since no one has bothered to do NATing on IPv6.
Secondly, no sanctioned way exists for an IPv6 only 'client' to communicate with an IPv4 'server'. I know that the engineers of IPv6 have a pure vision of a peer to peer internet where NAT is evil, but they needed to embrace it to get a very bad problem addressed. If it were baked in, then ISPs would suddenly have an incentive to migrate. As it stands, IPv6 represents only a financial burden, since it requires investment *and* they can't cut off IPv4 due to lack of interoperability. With this, suddenly, the still valuable IPv4 space wouldn't need to be given out to end customers, and IPv6 could carry them through.
One alternative would be for ISPs to start giving out private IPv4 addresses and doing the NATing for IPv4 that way, then assigning IPv6 networks for usage more in the spirit of symmetric peers. However, ISPs aren't particularly incentivized to go beyond the first step of taking away globaly IPv4 addresses. This comes to a third reason, we can still game the system with ISP level NAT a lot more since a vast majority of IP addresses in use are used by people who wouldn't even know they were behind an external NAT gateway if it happened to them one day. Most every modern internet usage is designed to tolerate NATs. Torrent and friends are more impacted than others, but most people still use http for 99% of their internet experience, and do not serve at all.
-Aggressive purchase/selloff of unused IP space (there are companies with class As that come no where near 16.7 million systems). -ISPs dropping granting an IP to residential customers and phones on the base plans, using NAT upstream
In other words, the world is so IPv6 averse that the IP exhaustion will not really happen in the medium-term future. While it is sad, the fact that 95% of the internet does not care or know about having a globally unique IP address will keep NAT a viable solution for a while. I.e. just as some people pay extra for a single static IP address, in the next few years, expect to have to pay a premium for a single real IP for others to reach you at.
I would characterize Apple's efforts as legitimate, and Palm's as inappropriate (I won't go to 'illegal').
There are generic USB interfaces (HID devices, mass storage, RNDIS, the list goes on) that implementers would be shady for locking to a whitelist of vendor ids and/or product ids. On that front, a competitor may cry foul and abuse of USB technology in an anti-competitive way.
On the other hand, Apple has a number of aspects to iTunes media sync that are not part of any industry spec, are not proposed as standards, not openly documented by the party controlling the technology, and are not guaranteed to stay exactly as they are understood today as they progress. Apple from a business perspective has clear motive, but from a technical standpoint, they don't want to give the impression something will work they do not commit to. Palm pulls similar stuff (an alternative media player was rejected from their App Catalog because it reverse-engineered unsupported APIs). Palm does get a point for explicitly suggesting homebrew for such endeavors, but it's clear that both parties aren't enthusiastic about their controlled user experience running away from their ability to guarantee consistent behavior.
Meanwhile, Palm is using vendor ids/device ids they are not supposed to use. This is simply bad form. It corrupts the use of the identifiers for the purpose of unambiguous identification.
If Palm wants to compete with Apple the way it is today, they should write their own proprietary stack and an iTunes competitor (either hooking into Amazon or some other competitor or trying to go it their own). I can understand though that they don't want to be in that business though. I would rather they did not do this personally, but it is an option.
If Palm simply wants to be the vendor of a portable media player portion of an open, interoperable environment, they should drive a standard that others can implement. Maybe they partner with another company to ensure one media sync software exists, but for all their complaining about Apple not playing fair, they are not pursuing measures which would allow arbitrary companies to properly interoperate. Maybe they can drive a new class id, or extend an existing one with an addional subclass and/or protocol id. The extent to their interaction with the USB-IF has been to simply whine, whereas their interaction should be to address an emerging common use of USB that may warrant a standard and making the requisite technical contributions to make that a reality. Maybe it's a higher-order specification (i.e. a standard database format, filesystem, and layout) that can either be on a USB mass storage device or an eSATA device, etc etc. Either way, I'd like to see that rather than Palm trying to subvert an Apple technology repeatedly.
I know its domain intentionally excludes OSX, Unix, and Linux (Wine comes closest, but always is subject to the whims of MS). Mono trails MS in.NET at all times and that's when MS is ostensibly *trying* to play nice. MS isn't trying to play nice at all with DirectX.
Microsoft's agenda is clear, they have a lockin technology and they want to keep it that way.
PhysX was trying to make a market for PPUs (and relatively failing). nVidia bought them up to make the technology another marketing bullet point for their GPU parts, not to sell GPU parts as mere physics calculations. Sure, they'll take the business as it comes incidently, but they have no interest in anything that could remotely be construed as putting something other than their role as a graphics adapter vendor first.
I think I trend more toward a duct tape programmer but will adjust my styles to suite the rest of the project I happen to be working on at the time. As a frequent duct tape programmer, that doesn't mean I have a free pass to write piss-poor, unmaintainable code. It means I should be disciplined in my coding without others constantly having to double-check that I'm being disciplined. Bad coders are bad coders, no matter what framework you put them in. Overly architected scenarios aim to keep a developer's ability to screw up code to a small area, but they can always make a mess of the code they write.
My strategy is to not try to use an architecture discussion ahead of time to predict if a peer's code is going to be bad, I wait for him/her to start checking in, and scan his/her's commits. If it looks fantastic, I am pleased and move on. If it looks like absolute garbage and is going to cause major problems, I will take measures to correct. If it isn't exactly what I want to see, and I believe I have a better way, but their approach seems workable as well, I keep my mouth shut because I know the debate will not be worth it. I fully expect my code to be read by others and critiqued as well without excessive discussion ahead of time.
Slashdot Mirror
Hard to meet both requirements at work without requiring a lot of effort on your part.
If you don't mind the changes coming closer to upstream release regardless of the next 'major' release, Fedora may be best for you, but be prepared for them to make choices you don't seek out.
If you only want an app to update when you choose, and no other time, go with Ubuntu. If you have exceptions, be preparred to manage them on a case-by-case basis (I have some PPAs added to mine for projects I have enthusiast type interest in, for example). This necessitates more work, but it's the price to be paid if you care about 'key' applications and fear the rest of the system changing.
Alternatively, I would respect Fedora still if they used 2.6.31 now, and updated Fedora 12 to 2.6.32 when it released without waiting for Fedora 13. I still wouldn't use it, but I would respect them more for properly serving the needs of the enthusiast in a healthier manner.
Holy cow, they absolutely do not.
I understand kernel module 'ABI', the only attempts to make that promise have failed miserably. 'API' (I know that kernel devs *hate* that term to describe compiling against their headers, but practically speaking...) in the '2.6.18' kernel isn't even stable.
Also, many of the features in the kernel are not safe. I have seen RHEL5.1 servers start getting system errors by going to RHEL5.2, requiring workarounds in their platform because of a change in how they managed certain things having certain edge scenarios that are made worse. Not saying it's an insurmountable problem, but not the sort of thing I want to see in a production update from 5.1 to 5.2.
In userspace, I can't recall a glibc binary incompatible change in 5.x, admittedly, but I also don't think they go crazy with the glibc features so much (however, they did jump firefox versions in a manner that broke some firefox extensions that would work in 5.1 when they jumped in 5.2, a desktop 'friendly' change, but again, a change made because they can't stand to be 'stale', even though a whole lot of 'enterprise' is entirely about 'stale' for the sake of stability and low risk of breakage with third-party software/solutions.
However, I don't see the point in sticking with 2.6.18 for stability purposes, and then turning around and making drivers that compile against 2.6.18 impossible to compile against your '2.6.18' because '2.6.18-164-el5' is nearly as much patch as it is original kernel.
First off, a disclaimer, as far as Fedora is concerned, they might as well keep doing what they are doing, or else there wouldn't me much difference between them and Ubuntu, as they have very similar release schedules and such. If someone feels like you, they have Fedora, if they feel like me, Ubuntu. Satisfying both of us with the same project would not be feasible. I simply want to be clear on what each distro does differently so that people are educated. Too often I see people play nice and be unwilling to call out the downsides of distro choices, making selecting one a more daunting task. Fedora's choices, in my opinion, cater to a certain class of enthusiasts but precludes suitability for 'everyone'.
That said, I would suggest discipline in development and forgoing features completely. I see backporting obvious bugfixes, but not features. In this case, if a feature will be in 2.6.32, either go with 2.6.31 and ignore it, or wait for 2.6.32 (i.e. the memory page dedupe feature). Backporting features and creating a relative frankenstein that is '2.6.31' in name only doesn't make sense to me. They already show they'd be willing to go to a new kernel post-release, so its not like they are even saying they have to wait 6 months. This isn't so terrible in Fedora, as the releases are at least in the near future and not a huge chasm to bridge. For RHEL, the monster they have created being called '2.6.18' holds no meaning. They've backported enough to not look like 2.6.18 did much, and yet there is so much not backported so it's not like any recent kernel either. It's an amalgamation of features/function changes that I don't like seeing in an enterprise 'service pack' series, exacerbated by that particular mix being validated only in RHEL and not the larger community.
You mention drivers, but new driver modules (frequently provided for by the hardware vendor) is a tad different from backporting major features (i.e. I think the choice of KVM in RHEL 5.4 would have been better served by waiting for RHEL6, advancing the schedule if they feel it is important enough). LSI probably already provided a driver developed against 2.6.18 and RHEL can fold that in, but don't fold in a major SCSI subsystem change while you are at it just because you think it safe. If I download a third party driver for a NIC that RHEL doesn't support, I don't want that compile to be impossible by going from RHEL5.2 to RHEL5.3, which often occurs.
It is subjective that Fedora does 'a lot more things a lot better'. They certainly have distinct aims from Ubuntu and gain some benefits, but I personally find Fedora to suffer some phenomena that Ubuntu does not:
-Out-of-the-box media/driver experience: Fedora goes purist and the out-of-the-box experience suffers for it with lack of popular codecs and optimal drivers for nVidia cards. Ubuntu caters to the user experience and takes care of this out of the box. You have to add RPM fusion repositories to make Fedora cope with this, which isn't insurmountable, but isn't out of the box.
-Fedora is not even stable within a release cycle in terms of offered featureset. I.e. I recall gaim 1.x being replaced with gaim 2.0 one day without requiring any particular update. This is good for enthusiasts who always want the cutting edge, bad for end-users who only want change at certain times they could expect (and for documenters doing screenshots). I recall once Fedora reving the kernel revision entirely without jumping releases. This wasn't bad in and of itself, but they jumped before nVidia supported it, and my X was hosed. Ubuntu is more conservative with this, knowing it will just be 6 months before a new cycle comes anyway.
-Fedora is 'too' comfortable with cutting edge changes, even to the point of releasing versions ahead of upstream *or* backporting code from future versions into older versions that upstream projects didn't want to do. For example, they backported things from the 2.6.32 branch to 2.6.31. The upstream kernel people weren't comfortable enough with the features to allow them into 2.6.31 or any release that aligned with their cycle, so they simply put 2.6.32 stuff into 2.6.31. This has been a longstanding tendency with RH (everyone probably remembers the gcc 2.96 debacle). BTW, this is even worse in RHEL, where they will backport 2.6.3x changes to 2.6.18, severely breaking third party kernel modules that code for the 'API' of 2.6.18 that gets broken by the massive amount of backports. Some third party even writes to newer 'apis', but wraps it with '> 2.6.26' sorts of ifdefs and thus assumes the 'old' api and RHEL will completely screw those assumptions. Ubuntu *usually* doesn't jump the gun (GRUB 2 is an example of going before the upstream declares 'ready' though).
-I *still* can't quite put my finger on it, but something about the Ubuntu desktop feels, subjectively to me, more whole rather than merely a conglomeration of the parts. This may simply be a matter of certain tastes they appear to me, because I can't nail it down.
But it's not such a huge problem.
You change a few characters, the block that contained those characters gets duplicated. If there is insufficient space, that write() syscall returns some errno to indicate the file system is unable to service the request. You will lose the pending data, but the original will stay intact. This allows the pool to be grown or all contents to remain readable to go to a new disk. A simple rule for storage providersd is that a mere read operation should *never* require additional disk space to succeed, and that a write needs to be dropped.
It's harder to predict what effect a change to the disk *will* have on a system (and by extension, have a precise concept of how much 'free' space you really have), but it doesn't have to be that different in behavior from a 'normal' full filesystem today, or a filesystem with sparse files that grows without any 'ls' output changes.
Any filesystem implementing copy-on-write at all, data dedupe, and/or compression is already a strategy where the risk of exhausting oversubscribed storage due to unanticipated compression ratios or uniqueness is a risk. It's a reason why you have to be pretty explicit to NetApp filers implementing these features that you are accepting the risk of exhausting allocations if you actually make use of these features to the point of advertising more storage capacity than you actually have.
You don't even need a fancy filesystem to expose yourself to this today:
$ dd if=/dev/zero of=bigfile bs=1M seek=8191 count=1
1+0 records in
1+0 records out
1048576 bytes (1.0 MB) copied, 0.00426769 s, 246 MB/s
jbjohnso@wirbelwind:~$ ls -lh bigfile
8.0G 2009-11-02 20:06 bigfile
~$ du -sh bigfile
1.0M bigfile
This possibility has been around a long file and the world hasn't melted. Essentially, if someone is using these features, they should be well aware of the risks incurred.
They have the 'verify' mode to do what you prescribe, though I'm presuming it comes with a hefty performance penalty.
I have no idea if they do this up front, inducing latency on all write operations, or as it goes.
What I would like to see is a strategy where it does the hash calculation, writes block to new part of disk assuming it is unique, records the block location as an unverified block in a hash table, and schedules a dedupe scan if one not already pending. Then, a very low priority io task could scan that structure for block locations that have yet to be verified, and then scan all the blocks that match its hash for sameness and update the structures to retroactively make it a single copy (effectively unlinking a block deemed duplicate after the fact). The absolute hard guarantee of sameness without a write performance penalty.
I'm very far from a filesystem designer, and I recognize the likelihood of a collision given sufficiently large block size is low, but I'd really be wary of something that relies on not having bad luck to accidentally lose data on a write due to an unlikely hash collision.
It is on their 'ideas' page:
http://btrfs.wiki.kernel.org/index.php/Project_ideas
(content based storage)
It doesn't say the precision of the flops. Unless things have recently changed, the outlandish flops spec of GPU derived compute platforms have all been 32-bit precision, whilst the TOP500 score is explicitly 64-bit precision.
http://en.wikipedia.org/wiki/FLOPS
nVidia's Tesla C1060 GPU computing card performs around 933 GFLOPS in single precision calculations
the same Nvidia Tesla C1060 capable of 78 GFLOPS in double precision
someone who turned out to be a felonious swindler and a cheat (and probable psychopath)?
To be fair, that really could be any sufficiently successful executive.
By communicate, I was implying a bi-directional link. The reason I said IPv6 client and IPv4 server is to reflect the fact that it *could* be feasible with NAT to do that. IPv4 could never talk to an IPv6 host even in theory without the IPv6 endpoint starting it, but I think that would be ok if the likes of google/yahoo/every major company retained an IPv4 presence and many clients could live happily in IPv6 world since they don't have to worry about business lost because they can't be called up by random IPv4 clients, and could still happily reach IPv4-only companies.
However, those 'crappy end-user routers' require that ISPs maintain their IPv4 infrastructure. If IPv4 infrastructure must be maintained, the IPv6 infrastructure by and large ranks as a 'novelty' and as such is pretty much not on the priority list of most ISPs.
IPv6 itself isn't a premature technology. If suddenly adopted every where, the world would ultimately not have the NAT problem anymore. The problem is that no solution that would extend the address space can exist and be perfectly inter-operable with IPv4 during a transitional period.
Have some blessed strategy to have IPv6->IPv4 NAT in place at the ISP level, and it's feasible. Problem is, that would have to compete with the more straightforward case of IPv4->IPv4 NAT that is much cheaper to strategize around. Sadly, it looks more and more like the 'real' solution is the NAT we have today, as it fits the needs of 95% of the internet users even if you took their one public IP address away.
Dancing turtles are indeed quite evil.
I assume he refers to the ability to realistically have more than one public address in your house, whether it be static or dynamic in nature. I personally have one public IPv4 address and maybe half a dozen devices to share it.
And to extend on his point, I will bet in the next year or so ISPs will start issuing addresses to residences that are in a private subnet range and charge people extra for not being behind a NAT gateway (if they haven't already).
How much private IP space is available?
Hypothetically, assuming only one tier of NAT, could be around 4 quadrillion or so. Beyond what is reasonable, but suffice to say, even the fanciest phones can get by without a universally addressable IP for 99.9% of their users, and I anticipate the cellular carriers to take full advantage of that before putting users on IPv6, effectively 'breaking' most of the 'real' internet as far as their customers would observe and think of it. A lot would be easier with managing their network with globally unique addresses, but as it stands they could segregate management of phones such that 16 million are in one 10. namespace, another 16 million are in a distinct 10. namespace, etc etc.
First and perhaps foremost, a lot of the industry has formulated a non-trivial amount of their business plan around the artificial scarcity of IPv4. It is recommended that even residences get /48 prefixes, though some have asked that to be reduced to /56, giving every person up to 255 subnets to route, each subnet being able to host 18 quintillion hosts in a globally unique fashion. Giving a singe IP address just won't cut it since no one has bothered to do NATing on IPv6.
Secondly, no sanctioned way exists for an IPv6 only 'client' to communicate with an IPv4 'server'. I know that the engineers of IPv6 have a pure vision of a peer to peer internet where NAT is evil, but they needed to embrace it to get a very bad problem addressed. If it were baked in, then ISPs would suddenly have an incentive to migrate. As it stands, IPv6 represents only a financial burden, since it requires investment *and* they can't cut off IPv4 due to lack of interoperability. With this, suddenly, the still valuable IPv4 space wouldn't need to be given out to end customers, and IPv6 could carry them through.
One alternative would be for ISPs to start giving out private IPv4 addresses and doing the NATing for IPv4 that way, then assigning IPv6 networks for usage more in the spirit of symmetric peers. However, ISPs aren't particularly incentivized to go beyond the first step of taking away globaly IPv4 addresses. This comes to a third reason, we can still game the system with ISP level NAT a lot more since a vast majority of IP addresses in use are used by people who wouldn't even know they were behind an external NAT gateway if it happened to them one day. Most every modern internet usage is designed to tolerate NATs. Torrent and friends are more impacted than others, but most people still use http for 99% of their internet experience, and do not serve at all.
-Aggressive purchase/selloff of unused IP space (there are companies with class As that come no where near 16.7 million systems).
-ISPs dropping granting an IP to residential customers and phones on the base plans, using NAT upstream
In other words, the world is so IPv6 averse that the IP exhaustion will not really happen in the medium-term future. While it is sad, the fact that 95% of the internet does not care or know about having a globally unique IP address will keep NAT a viable solution for a while. I.e. just as some people pay extra for a single static IP address, in the next few years, expect to have to pay a premium for a single real IP for others to reach you at.
I would characterize Apple's efforts as legitimate, and Palm's as inappropriate (I won't go to 'illegal').
There are generic USB interfaces (HID devices, mass storage, RNDIS, the list goes on) that implementers would be shady for locking to a whitelist of vendor ids and/or product ids. On that front, a competitor may cry foul and abuse of USB technology in an anti-competitive way.
On the other hand, Apple has a number of aspects to iTunes media sync that are not part of any industry spec, are not proposed as standards, not openly documented by the party controlling the technology, and are not guaranteed to stay exactly as they are understood today as they progress. Apple from a business perspective has clear motive, but from a technical standpoint, they don't want to give the impression something will work they do not commit to. Palm pulls similar stuff (an alternative media player was rejected from their App Catalog because it reverse-engineered unsupported APIs). Palm does get a point for explicitly suggesting homebrew for such endeavors, but it's clear that both parties aren't enthusiastic about their controlled user experience running away from their ability to guarantee consistent behavior.
Meanwhile, Palm is using vendor ids/device ids they are not supposed to use. This is simply bad form. It corrupts the use of the identifiers for the purpose of unambiguous identification.
If Palm wants to compete with Apple the way it is today, they should write their own proprietary stack and an iTunes competitor (either hooking into Amazon or some other competitor or trying to go it their own). I can understand though that they don't want to be in that business though. I would rather they did not do this personally, but it is an option.
If Palm simply wants to be the vendor of a portable media player portion of an open, interoperable environment, they should drive a standard that others can implement. Maybe they partner with another company to ensure one media sync software exists, but for all their complaining about Apple not playing fair, they are not pursuing measures which would allow arbitrary companies to properly interoperate. Maybe they can drive a new class id, or extend an existing one with an addional subclass and/or protocol id. The extent to their interaction with the USB-IF has been to simply whine, whereas their interaction should be to address an emerging common use of USB that may warrant a standard and making the requisite technical contributions to make that a reality. Maybe it's a higher-order specification (i.e. a standard database format, filesystem, and layout) that can either be on a USB mass storage device or an eSATA device, etc etc. Either way, I'd like to see that rather than Palm trying to subvert an Apple technology repeatedly.
I know its domain intentionally excludes OSX, Unix, and Linux (Wine comes closest, but always is subject to the whims of MS). Mono trails MS in .NET at all times and that's when MS is ostensibly *trying* to play nice. MS isn't trying to play nice at all with DirectX.
Microsoft's agenda is clear, they have a lockin technology and they want to keep it that way.
You express a desire for an API from Microsoft to become dominant?
PhysX was trying to make a market for PPUs (and relatively failing). nVidia bought them up to make the technology another marketing bullet point for their GPU parts, not to sell GPU parts as mere physics calculations. Sure, they'll take the business as it comes incidently, but they have no interest in anything that could remotely be construed as putting something other than their role as a graphics adapter vendor first.
I think I trend more toward a duct tape programmer but will adjust my styles to suite the rest of the project I happen to be working on at the time. As a frequent duct tape programmer, that doesn't mean I have a free pass to write piss-poor, unmaintainable code. It means I should be disciplined in my coding without others constantly having to double-check that I'm being disciplined. Bad coders are bad coders, no matter what framework you put them in. Overly architected scenarios aim to keep a developer's ability to screw up code to a small area, but they can always make a mess of the code they write.
My strategy is to not try to use an architecture discussion ahead of time to predict if a peer's code is going to be bad, I wait for him/her to start checking in, and scan his/her's commits. If it looks fantastic, I am pleased and move on. If it looks like absolute garbage and is going to cause major problems, I will take measures to correct. If it isn't exactly what I want to see, and I believe I have a better way, but their approach seems workable as well, I keep my mouth shut because I know the debate will not be worth it. I fully expect my code to be read by others and critiqued as well without excessive discussion ahead of time.