Yup. It's a pretty horrible API to and has completely insane integration with both event delivery and drawing, which made sense when you were trying to squeeze the last possible bit of performance out of a 33MHz machine without double-buffered graphics but make absolutely no sense now. It definitely does need to be replaced, the problem is getting people to agree on what. Microsoft tried to make ActiveX a replacement, but no one else adopted it. The only reason NPAPI still survives is that it's the only way of making a plugin that all of the major browsers support. Maybe now Chrome market share is enough that they can make all of the plugin makers implement a new API. Or maybe plugins just aren't as important anymore...
My guess is that you weren't using Windows. On most *NIX platforms, installing either was pretty trivial. On Windows, however, MySQL had a point-and-click installer years before PostgreSQL worked reliably on the platform. For web developers working on Windows, this meant that if they wanted to install the same DB on their dev machine as on their deployment system, MySQL was a clear winner.
When I was a student, you could get a student license to Windows 2000 and Visual Studio for under £100. You can now get both the latest OS and dev tools for free under the academic licensing. You don't need to have lots of disposable income to afford free...
Your metric will end up with no computer books being available. It took about 2 days between my last book being published and it being possible to find pirate copies online, and yet people are still buying it so obviously some people would rather have the dead-tree edition, and I suspect that most of those would happily buy it at a fraction of the price in a charity shop...
SHA256 is not an error correcting code. It can not correct even single-bit flips. If it could, it would be useless as a cryptographic hash. If you could take a hash and some data that was close to the data for which the hash was computed, and find the single-bit flip that would allow the data to match the hash, then you'd have a very easy way of creating SHA256 collisions. And if you had such an algorithm, you wouldn't use it in a filesystem, you'd use it to break all of the systems that rely on SHA256 collisions being difficult to create. If you want error correcting codes in a filesystem, then you'd use an error correcting code, not a cryptographic hash.
MSR has a budget of close to $6bn annually. This is just for blue-skies research and does not include the development budget for things that MS actually turns into products. IBM's total R&D budget is also $6bn annually. So, I'd say they're pretty close...
I'm sure that venture capitalists would love to fund someone with a new idea and a business model, knowing that they have no recourse when one of the existing players in the market sitting on a large war chest decides to throw ten times the engineering resources at the same problem. First mover advantage only goes so far...
Who do you think is going to be amending the patents when they're going through the cycle of submit, have prior art reported, amend, resubmit. Hint: It's not engineers...
My memory is slightly fuzzy, since it's over ten years since I studied this, but here goes:
Single-bit errors in DRAM are caused by the capacitor that stores the data being discharged. This means that the transitions happen in one direction: from charged to discharged. With parity RAM, you can tell that an error has occurred, but you can't tell what the error is. The parity and ECC checks happen in the the digital circuitry and so have no knowledge of the analogue state. Since ECC uses Hamming codes, it can detect more than single-bit errors, but it can only fix one bit flip (the bias isn't actually required, but it does make the code shorter).
In the good ol' US of A if you bring your phone to another company, you pay the same thing everyone else is paying. No discount for not getting a new shiney through the new company.
If you bring your phone to another company, you are not going to get a contract with a phone, you're going to get a SIM-only plan.
If I have two files, with block IDs ABCDE and EFCGH, how would I place them on disk in such a way that a single sequential read would allow me to read either file? Without dedup, it's easy: ABCDEEFCGH, for example. With partial dedup, you could write them as ABCDEFCGH, eliminating the duplication of the E, but you've still got two copies of C. With full deduplication, if you write the first file contiguously, then you are going to need at least two seeks while reading the second - EF{seek}C{seek}GH.
The obvious distinction is whether they invest a engineering effort in developing things. Most patent trolls just buy up patents and then try to turn them into money. Companies like ARM also don't make things, but the stuff that they license has obvious value: creating it independently from scratch would require a lot of time and money. Typically, these companies don't just license patents, they also provide detailed designs, engineering support, and so on.
I only spent a few minutes looking last time I was in the US, but I found lots of mobile phone shops that were willing to give cheaper SIM-only deals and even more such deals were available online. Eventually I decided that since my phone had OSMAnd for offline maps and I had WiFi in the hotel (and a lot of coffee shops and so on), I didn't need to bother with mobile coverage.
When people say GSM, they mean the ETSI standards, including UMTS, HSPA and LTE. Most vaguely recent 'GSM' phones speak at least GSM and UMTS, many also do HSPA and the latest ones do LTE as well. All of the newer standards are also patented, but they're RAND licensed and so there's lots of competition among device makers.
That's not what I mean. The defragmentation should happen as part of the normal read / write process. It should not be a separate task, because there is no gain at all (and a significant penalty) from defragmenting files that you (almost) never access.
The main advantage of VMs over processes is that they have a much smaller amount of OS state. In a VM, almost all of the state is within the VM. There's a tiny amount for the PV devices, but that's it. In a POSIX OS, even the state associated with the file descriptor table is huge and then there are things like locks that are blocking in the kernel and all of the state that is associated with the scheduler and so on. If you want to move a process from one host to another, it's decidedly nontrivial, especially if it has open files and sockets. Hypervisors, however, are designed to suspend, resume, clone, and migrate VMs.
No, what they've 'invented' is called a LibOS, and in combination with the hypervisor is called either a separation kernel or an exokernel, depending on which community you're in. And they aren't claiming to have invented it - academic literature is full of them - they're claiming to have implemented one that is BSD licensed, available now, and runs existing Linux binaries.
Additionally unfounded. Given that BSD sources can be downloaded, modified, and their changes never see the light of day the loss of information is virtually guaranteed. Not to say it doesn't happen with the GPL, but it's actually a legal risk to allow it to happen.
Take a look at the donors list to the FreeBSD Foundation and see how many of them are big companies (e.g. NetApp, Juniper) that ship proprietary products built on FreeBSD, yet still contribute back changes. And then look at companies like Google, which build their infrastructure on Linux but keep a lot of changes public. The GPL doesn't force them to give anything back unless they distribute the modified version, and they don't distribute the modified Linux that they run on their servers. It's only a legal risk if you are distributing the software, but given that 90% of all developers are working on in-house software that is never intended for distribution then that means that the GPL only ever forces the 10% of potential developers who are working on commodity off-the-shelf software to release code, and they are the ones who are least likely to touch the GPL in the first place.
Over the years, I've worked with companies that have maintained private forks of GPL'd projects, because they don't want the potential liability of distributing things under the GPL. When they take some of our BSDL code, however, they'll push back patches because there's no possible legal obligation arising from their doing so, and it's cheaper to have all of their changes upstream than maintain a private fork. I've also worked with companies that have done a clean-room reimplementation of a project rather than touch the GPL (in many cases, it's remained private, in some they've released it under a permissive license).
It's using a (heavily modified) FreeBSD kernel with the Linux compat layer, so it's not surprising. And the 1% speedup isn't the real win. The benefit is that you can make a very small VM image that can spool up new instances in about a second. It isn't that you can run a single instance 1% faster, it's that when you get load spikes you can start up 1000 new instances in between getting the SYN and sending the ACK...
That's well and good, until you realize that a typical email server usually has an MTA (postfix, courier, sendmail, whatever), some sort of spam trap/filter (in addition to external ones), maybe a means to more efficiently handle distie lists, SASL auth (postfix typically handles that nowadays, but...), and probably some sort of webmail thingy. That's way more than "one app".
And in the deployment scenarios that this is intended for, each one of those would be running in a separate VM. If you have lots more incoming mail, you might spin up more spam filter instances dynamically. You'd probably only have a single persistent VM for the storage, but everything else would be scaled dynamically.
Slashdot Mirror
Yup. It's a pretty horrible API to and has completely insane integration with both event delivery and drawing, which made sense when you were trying to squeeze the last possible bit of performance out of a 33MHz machine without double-buffered graphics but make absolutely no sense now. It definitely does need to be replaced, the problem is getting people to agree on what. Microsoft tried to make ActiveX a replacement, but no one else adopted it. The only reason NPAPI still survives is that it's the only way of making a plugin that all of the major browsers support. Maybe now Chrome market share is enough that they can make all of the plugin makers implement a new API. Or maybe plugins just aren't as important anymore...
My guess is that you weren't using Windows. On most *NIX platforms, installing either was pretty trivial. On Windows, however, MySQL had a point-and-click installer years before PostgreSQL worked reliably on the platform. For web developers working on Windows, this meant that if they wanted to install the same DB on their dev machine as on their deployment system, MySQL was a clear winner.
When I was a student, you could get a student license to Windows 2000 and Visual Studio for under £100. You can now get both the latest OS and dev tools for free under the academic licensing. You don't need to have lots of disposable income to afford free...
Your metric will end up with no computer books being available. It took about 2 days between my last book being published and it being possible to find pirate copies online, and yet people are still buying it so obviously some people would rather have the dead-tree edition, and I suspect that most of those would happily buy it at a fraction of the price in a charity shop...
Superstition is the nonsense other people believe, faith is the nonsense I believe.
SHA256 is not an error correcting code. It can not correct even single-bit flips. If it could, it would be useless as a cryptographic hash. If you could take a hash and some data that was close to the data for which the hash was computed, and find the single-bit flip that would allow the data to match the hash, then you'd have a very easy way of creating SHA256 collisions. And if you had such an algorithm, you wouldn't use it in a filesystem, you'd use it to break all of the systems that rely on SHA256 collisions being difficult to create. If you want error correcting codes in a filesystem, then you'd use an error correcting code, not a cryptographic hash.
MSR has a budget of close to $6bn annually. This is just for blue-skies research and does not include the development budget for things that MS actually turns into products. IBM's total R&D budget is also $6bn annually. So, I'd say they're pretty close...
I'm sure that venture capitalists would love to fund someone with a new idea and a business model, knowing that they have no recourse when one of the existing players in the market sitting on a large war chest decides to throw ten times the engineering resources at the same problem. First mover advantage only goes so far...
Who do you think is going to be amending the patents when they're going through the cycle of submit, have prior art reported, amend, resubmit. Hint: It's not engineers...
None of the listed companies come close to IBM for patents filed per year.
Single-bit errors in DRAM are caused by the capacitor that stores the data being discharged. This means that the transitions happen in one direction: from charged to discharged. With parity RAM, you can tell that an error has occurred, but you can't tell what the error is. The parity and ECC checks happen in the the digital circuitry and so have no knowledge of the analogue state. Since ECC uses Hamming codes, it can detect more than single-bit errors, but it can only fix one bit flip (the bias isn't actually required, but it does make the code shorter).
In the good ol' US of A if you bring your phone to another company, you pay the same thing everyone else is paying. No discount for not getting a new shiney through the new company.
If you bring your phone to another company, you are not going to get a contract with a phone, you're going to get a SIM-only plan.
If I have two files, with block IDs ABCDE and EFCGH, how would I place them on disk in such a way that a single sequential read would allow me to read either file? Without dedup, it's easy: ABCDEEFCGH, for example. With partial dedup, you could write them as ABCDEFCGH, eliminating the duplication of the E, but you've still got two copies of C. With full deduplication, if you write the first file contiguously, then you are going to need at least two seeks while reading the second - EF{seek}C{seek}GH.
The obvious distinction is whether they invest a engineering effort in developing things. Most patent trolls just buy up patents and then try to turn them into money. Companies like ARM also don't make things, but the stuff that they license has obvious value: creating it independently from scratch would require a lot of time and money. Typically, these companies don't just license patents, they also provide detailed designs, engineering support, and so on.
It's much easier to sell an unlocked phone than a locked one, so that's still valuable.
I only spent a few minutes looking last time I was in the US, but I found lots of mobile phone shops that were willing to give cheaper SIM-only deals and even more such deals were available online. Eventually I decided that since my phone had OSMAnd for offline maps and I had WiFi in the hotel (and a lot of coffee shops and so on), I didn't need to bother with mobile coverage.
When people say GSM, they mean the ETSI standards, including UMTS, HSPA and LTE. Most vaguely recent 'GSM' phones speak at least GSM and UMTS, many also do HSPA and the latest ones do LTE as well. All of the newer standards are also patented, but they're RAND licensed and so there's lots of competition among device makers.
That's not what I mean. The defragmentation should happen as part of the normal read / write process. It should not be a separate task, because there is no gain at all (and a significant penalty) from defragmenting files that you (almost) never access.
The main advantage of VMs over processes is that they have a much smaller amount of OS state. In a VM, almost all of the state is within the VM. There's a tiny amount for the PV devices, but that's it. In a POSIX OS, even the state associated with the file descriptor table is huge and then there are things like locks that are blocking in the kernel and all of the state that is associated with the scheduler and so on. If you want to move a process from one host to another, it's decidedly nontrivial, especially if it has open files and sockets. Hypervisors, however, are designed to suspend, resume, clone, and migrate VMs.
No, what they've 'invented' is called a LibOS, and in combination with the hypervisor is called either a separation kernel or an exokernel, depending on which community you're in. And they aren't claiming to have invented it - academic literature is full of them - they're claiming to have implemented one that is BSD licensed, available now, and runs existing Linux binaries.
C++ has had a reliable standardised ABI for years. It's supported everywhere except Windows...
Additionally unfounded. Given that BSD sources can be downloaded, modified, and their changes never see the light of day the loss of information is virtually guaranteed. Not to say it doesn't happen with the GPL, but it's actually a legal risk to allow it to happen.
Take a look at the donors list to the FreeBSD Foundation and see how many of them are big companies (e.g. NetApp, Juniper) that ship proprietary products built on FreeBSD, yet still contribute back changes. And then look at companies like Google, which build their infrastructure on Linux but keep a lot of changes public. The GPL doesn't force them to give anything back unless they distribute the modified version, and they don't distribute the modified Linux that they run on their servers. It's only a legal risk if you are distributing the software, but given that 90% of all developers are working on in-house software that is never intended for distribution then that means that the GPL only ever forces the 10% of potential developers who are working on commodity off-the-shelf software to release code, and they are the ones who are least likely to touch the GPL in the first place.
Over the years, I've worked with companies that have maintained private forks of GPL'd projects, because they don't want the potential liability of distributing things under the GPL. When they take some of our BSDL code, however, they'll push back patches because there's no possible legal obligation arising from their doing so, and it's cheaper to have all of their changes upstream than maintain a private fork. I've also worked with companies that have done a clean-room reimplementation of a project rather than touch the GPL (in many cases, it's remained private, in some they've released it under a permissive license).
It's using a (heavily modified) FreeBSD kernel with the Linux compat layer, so it's not surprising. And the 1% speedup isn't the real win. The benefit is that you can make a very small VM image that can spool up new instances in about a second. It isn't that you can run a single instance 1% faster, it's that when you get load spikes you can start up 1000 new instances in between getting the SYN and sending the ACK...
You don't have 12 VMs. You have 12 kinds of VM. You have tens to thousands of instances of those VMs, depending on your load.
That's well and good, until you realize that a typical email server usually has an MTA (postfix, courier, sendmail, whatever), some sort of spam trap/filter (in addition to external ones), maybe a means to more efficiently handle distie lists, SASL auth (postfix typically handles that nowadays, but...), and probably some sort of webmail thingy. That's way more than "one app".
And in the deployment scenarios that this is intended for, each one of those would be running in a separate VM. If you have lots more incoming mail, you might spin up more spam filter instances dynamically. You'd probably only have a single persistent VM for the storage, but everything else would be scaled dynamically.