One example: I deal with healthcare claims. We keep everything normalized on insertion, but we also create some redundant, denormalized tables (data warehousing). Almost every query needs the same basic claim information, but I'm doing it in a query with one or two joins instead of 10.
That sounds like just using a form of materialized views, which, while the implementation (in an RDBMS that doesn't implement them internally) may involve using triggers and denormalized "base" (in terms of the RDBMS, not the usage) tables, isn't really outside of the kind of basic database usage or anything novel. I'm somewhat surprised that, if you had more than incidental formal coverage of RDBMS's that materialized views weren't covered, and so would be something "outside" of what you learned about databases in school.
Only if by "business-friendly" you mean "easy for businesses to take while giving nothing in return".
PostgreSQL itself -- which is financially supported largely by businesses making money off it, particularly EnterpriseDB -- and SQLite -- likewise supported by a bunch of businesses using it to make money -- are both proof that, even if this might be true in theory from a certain viewpoint, its not necessarily how things work out in practice. The reason is pretty obvious, a licensing scheme (which a dedication to the public domain like SQLite's amounts to just as much as PostgreSQL's use of BSD-style license does) that enables businesses to use it in their own closed products also gives the same businesses an incentive to see the open source product thrive, remain as compatible as possible with the implementation in their closed products, and have an active user and development community, since all of that keeps the businesses costs down. Which gives the businesses a strong financial incentive to give something back -- which the businesses profiting from PostgreSQL and SQLite do, both financially and terms of code committed back to the open project.
What exactly is the difference between today's "cloud computing" and yesterday's "internet-based services?"
"Cloud computing" is a catch-all name for technologies for building systems where the underlying physical servers are abstracted and compute resources can be dynamically provisioned.
One common application of this technology is providing hosting for internet-based services.
The relation between the two is about the same as the relation between, say, "internal combustion engines" and "mail delivery services".
Cloud computing is trusting Someone Else to take care of your data.
No, its not.
Paying someone for hosting your data is trusting someone else to take care of your data, which you can do with or without cloud computing (hosting services were popular well before cloud computing.)
Cloud computing is abstracting away the physical servers in doing logical server partitioning. You can do it completely on hardware you control in your own datacenter (Ubuntu Server, from 9.04, comes with a stack of software for cloud computing, and there is other software available, as well.) You may choose a hosted cloud, just as you can choose a hosted traditional server, that someone else owns and manages, but that isn't essential to cloud computing any more than it is to traditional server computing.
With Cloud Computing, those who modify FOSS software do not have to redistribute the code, because they are only providing a service and not a functional program.
There is no general requirement to redistribute code with modified FOSS software anyway. That's a feature specific to particular licenses (particularly, the GPL.)
But some cloud technologists insist data center failures are not cloud failures. Is this distinction meaningful?
Of course its meaningful. If you have a local server that you own, and you choose not to back it up, and it fails with a complete loss of data, that isn't primarily a problem with owning a local server, or with the particular server operating system (though there may be factors associated with either of those that contribute to the crash), its a problem with you choosing not to back up data.
If you have a single traditional server that you pay for access to, but is owned and managed by someone else with your data, and the same thing happens because you didn't assure (e.g., via contract) that the server would be backed up, again, the problem is with your failure.
If you have a cloud using one or more local physical servers that you manjage (e.g., using the cloud software included with Ubuntu Server), and the same thing happens, its not a problem with either cloud technology in general or the particular cloud technology you used, again, its a problem with your choice not to back it up.
If you instead pay for the use of someone else's cloud to host your virtual server instances than either you should be backing them up (if you manage the virtual servers, even though the vendor will be managing the physical servers and the cloud software) or you should assure that the vendor managing the virtual servers is backing them up (if a vendor, either the cloud vendor or someone else, is doing that for you.) If the servers aren't backed up, its your fault, and not the (general or specific) cloud technologies fault.
Or does the cloud movement bear the burden of fuzzy definitions in assessing its shortcomings as well as its promise?
There's no fuzzy definition involved here. The problem is quite simply one of failing to plan for recovery in the case of failure. This is a need that is independent of whether your logical servers are identical to your physical servers or whether they are decoupled as is the case in cloud technology, and likewise independent of whether your physical servers are owned by you and located in your data center or owned by someoneone else and located in their data center (or any mix and match of ownership and location), and further independent of whether you manage your logical servers personally (or with your regular employees) or contract out for the management of them.
This is not a failure of cloud technology, it is a failure of the particular parties managing this particular implementation to do something to which the the use or not of cloud technologies is completely irrelevant.
It is (like every patent described on Slashdot) described poorly.
The patent is not a business-model patent for time-based licensing, its a technology patent for a specific scheme of enforcing time-based licensing rules.
The way its described in TFS there would certainly be massive prior art. I'm less sure about the particular scheme they're actually trying to patent.
Though, from the description in TFA, regardless of prior art, the scheme seems painfully obvious, so I wouldn't be surprised if existing time-based licenses use this enforcement scheme already.
Right. GNU is an operating system. It contains many things, including a kernel (Hurd) which is not the kernel which is at the heart of any Linux distribution (the Linux kernel.)
Now, because some of the components of GNU are open source and useful, some of them -- including lots of other stuff not from GNU maintained by people other than Linus Torvalds -- are often packaged together with the Linux kernel to make a complete OS distribution. Usually, such a distribution has a name (like "Ubuntu" or "Fedora") and often the distributor tags on "Linux" because identifying it as such helps people understand what kind of operating system it is.
Certain people want those distros to be called "GNU/Linux" because they include GNU components, but rarely argue that distributions that include components other than the Linux kernel besides GNU components should also have those other components honored alongside GNU in every discussion.
I disapprove of the iPhone for a variety of reasons, but the public likes what it likes and we don't need to go into the causes.
Actually, if we are talking about what is likely to be successful in the future, rather than what is successful right now, we do need to have some understanding of the causes of why the public likes what they like. Simply stating that "X is popular now, which means the public likes it and we don't need to examine why, and it will always, therefore, remain the most popular" doesn't really cut it.
I bought an iPhone because it seemed to be the best mobile device for my interests at the time I bought it. I also bought it under the firm belief (which has only been reinforced since) that by the time I bought my text smartphone, the iPhone probably wouldn't be where I was going, and that something like Android probably would. Even if underlying desires never changed (which they do), how well different products meet them can and does change.
But Google isn't, and isn't going to be, making Android devices to sell to consumers. Lots of phone vendors (and some non-phone vendors -- e.g., the reported B&N e-Reader) are and plan to do that.
Microsoft is just one company.
And Microsoft doesn't make Windows (whether you are talking the traditional OS or the movile one) devices to sell to consumers, at least not most of them; lots of hardware vendors do that.
Just because some handset makers are betting on the future of Android, doesn't mean their bets are panning out.
No it doesn't necessarily mean that. However, the fact that many vendors has consequences for Android; it means, among other things, that its not tied to the success of any one particular hardware vendors efforts. Plus it means that its quite likely that more different strategies will be tried with it by hardware vendors, which gives it more chances that one of them will hit it out of the park.
Oh yeah.. and their bets can pan out without their OS overtaking the iPhone OS.
Yes, they could.
Both this and the preceding point seem to confuse an analysts prediction of what is most likely to occur (against which there may be many valid criticisms) with a statement that that is the only thing which is logically possible.
They can claim they were not 'aware' of any wrongdoing, and that of course will be irrelevant in the eyes of the law.
Ignorance of the law may not be an excuse, generally, but most crimes do have a required mental state which often includes (but is not limited to) awareness of material facts related to the wrongful conduct.
Linux is definitely not an operating system, it's just a common term to refer to Linux-based operating systems (because the average person doesn't care).
Actually, I think its a common term to refer to operating systems that use the Linux kernel collectively, because more specific designations (either like "Ubuntu" or like "GNU/Linux") don't generally work for that purpose, though sometimes some of them may be appropriate fro some subset of Linux-based operating systems.
For instance, if I release software that is designed to run on a Linux based operating system with specific identified dependencies, that does not rely on features of a particular distribution or tools or libraries other than those in the listed dependencies, it makes more sense to describe it as being for Linux, with the specific required dependencies, than to say it is for "GNU/Linux" (since, insofar as it requires anything from GNU, that's already covered by the listed dependencies), or for "Ubuntu" (since it doesn't require anything specific to Ubuntu) or for anything else.
Possibly the "automatic unneeded package pruning". It could be dangerous if your custom apps don't specify their dependencies correctly (say, they rely on something that had been automatically installed by one of their other dependencies).
I'm pretty sure both automatically installing dependencies and automatically pruning those no longer needed can be disabled when using apt via the command line tools, though perhaps not through all graphical front-ends. (I've never had to avoid either, but I'm pretty sure I've seen the options to do so.)
What you decide on for the inexpensive Linux server at home?
I was struck by (not severely, but enough to delay non-essentials) reduced income which has delayed that decision; I'm still leaning toward one of the "nettop" oriented Atoms (by the time I get around to it now, probably one of the new D-series ones, since I understand the 230/330 are goint to be phased out when they are introduced).
I was recently looking at doing something like that and ended up using my old Dell laptop (E1505), which has an original core duo (*not* 64 bit, either).
That sounds like a good choice: I'd rather keep something existing and repurpose it, but unfortunately my only operational but not otherwise committed computer is a a fairly old laptop that has some issues that make unattractive for use in a situation where it would be on for long periods of time. So I am kind of left with building fresh.
The problem is, the DMCA does not allow you to dispute the takedown notice until after the "infringing" material has been removed.
This is not true. The DMCA sets no limits on when you can dispute a takedown notice. It just doesn't require the service provider to notify the user until after (though "promptly" after) the material has been taken down, in order to remain in the safe harbor against liability to the user. Provided that it didn't interfer with the providers ability to "expeditiously" disable access to the material, a provider could remain within the safe harbor provision while notifying users before disabling access, particularly if they happened to be able to notify them in real time.
Since the DMCA allows electronic signatures on coutnernotice, if they had an online, standard counternotice form as well, it might even be possible for them to provide a very brief window in which it was possible to file the counternotice before the access was disabled without falling outside of the requirements of either safe harbor provision.
OTOH, providers are concerned about being sued by media companies, with whom they have no contracts limiting their liabilities, and not so much by their users, with whom they usually have contracts which are set up to restrict liability. So they are much more concerned with the safe harbor with respect to complaining potential copyright holders than anything else with regard to the DMCA takedown provisions.
My ignorance. I've only looked at the netbook ones. Wasn't aware that there were 64 bit Atom processors, actually.:)
To be fair, I was in the opposite position, having only looked previously at the 230/330 thinking about using one of those for an inexpensive Linux server at home; I wasn't aware that the N/Z models weren't 64-bit, too. I started writing GP with "Actually, the Intel Atom processors are 64-bit processors", but then decided to do some checking before I posted it.
And there is a 32 bit version because not everyone runs 64 bit processors. Say, for example, the Intel Atom.
Specifically current Intel Atom "Diamondville" N- and "Silverthorne" Z-series processors intended for netbooks and UMPCs, other Atoms (current "Diamondville" 230/330, and the upcoming [Q1, 2010] "Pineview" D- (replaces "Diamondville" 230/330) and "Pineview" N- (replaces the current "Diamondville" N) series Atoms are all 64-bit.
I'm looking forward to languages that integrate completely with an IDE, and leave simple character representation (ASCII e.a.) behind.
There are plenty of existing programming environments where the programmer doesn't interact with code as a linear string of text; including in systems that use executable diagrams (often things like BPMN), and, by far the most common example, spreadsheets.
1. No, this doesn't have anything to do with Google voice, as Google Voice isn't VOIP.
While its true that Google Voice isn't VoIP, Apple's official statement on rejecting Google Voice indicated that part of the reason is that it might be VoIP.
The allies I refer to are folks like Linus, Eric Raymond, Tim O'Reilly and everyone else that advocates the same ideas, but does not take marching orders from him.
AFAICT, those people don't advocate the same ideas as RMS. Raymond himself discusses the FSF as a distinct faction with a different ideology than his within the broader hacker community.
The main idea that Linus Torvalds seems to advocate is making software that works. While GNU, Stallman, and the GPL probably wouldn't be as important as they are without Torvalds and Linux (particularly, had Linux not exploded while BSD went through some legal birth pangs), Torvalds and Stallman aren't really advocates of the same philosophy, they are, inasmuch as Torvalds is an advocate of any philosophy, advocates of different philosophies that happen to occasionally coincide in terms of the actions they suggest (and, at other times, to be almost directly opposed.)
I bet they will use Mono to ease the transition. If they've already got a huge codebase written for.NET, wouldn't it be insane to throw it away?
The problem appears to be, in part, latency induced by the number of layers above the bare metal that are involved, so I'm not sure Mono would get much improvement. They apparently threw away the existing COBOL-based system in favor of a complete reimplementation for.NET back in 2005, so if they did that again it wouldn't be entirely unprecedented.
From what I understand, it was the app that sucked. Why is this then a stinging indictment of the platform?
Because Microsoft used the app and its supposed superiority in the area it was deployed as a major case study in the strength of the Microsoft programming and platform components used in the implementation: the products called out in their case study include the.NET Framework, Windows Server, SQL Server, Visual Studio.NET, Microsoft Operations Manager, ASP.NET, and Visual C#.NET (I may have missed some.) A quote: "In a highly competitive environment, the London Stock Exchange is gaining a considerable cost advantage over its competitors by using the.NET Framework and Visual C#.NET." (source: Microsoft.)
If it says something about the platform when you are getting the sale (because it outperforms the preceding implementation), then it also says something about the platform when the Exchange looks to replace you with something that outperforms your implementation.
Slashdot Mirror
That sounds like just using a form of materialized views, which, while the implementation (in an RDBMS that doesn't implement them internally) may involve using triggers and denormalized "base" (in terms of the RDBMS, not the usage) tables, isn't really outside of the kind of basic database usage or anything novel. I'm somewhat surprised that, if you had more than incidental formal coverage of RDBMS's that materialized views weren't covered, and so would be something "outside" of what you learned about databases in school.
Many forms of entertainment require willing suspension of disbelief.
PostgreSQL itself -- which is financially supported largely by businesses making money off it, particularly EnterpriseDB -- and SQLite -- likewise supported by a bunch of businesses using it to make money -- are both proof that, even if this might be true in theory from a certain viewpoint, its not necessarily how things work out in practice. The reason is pretty obvious, a licensing scheme (which a dedication to the public domain like SQLite's amounts to just as much as PostgreSQL's use of BSD-style license does) that enables businesses to use it in their own closed products also gives the same businesses an incentive to see the open source product thrive, remain as compatible as possible with the implementation in their closed products, and have an active user and development community, since all of that keeps the businesses costs down. Which gives the businesses a strong financial incentive to give something back -- which the businesses profiting from PostgreSQL and SQLite do, both financially and terms of code committed back to the open project.
"Cloud computing" is a catch-all name for technologies for building systems where the underlying physical servers are abstracted and compute resources can be dynamically provisioned.
One common application of this technology is providing hosting for internet-based services.
The relation between the two is about the same as the relation between, say, "internal combustion engines" and "mail delivery services".
No, its not.
Paying someone for hosting your data is trusting someone else to take care of your data, which you can do with or without cloud computing (hosting services were popular well before cloud computing.)
Cloud computing is abstracting away the physical servers in doing logical server partitioning. You can do it completely on hardware you control in your own datacenter (Ubuntu Server, from 9.04, comes with a stack of software for cloud computing, and there is other software available, as well.) You may choose a hosted cloud, just as you can choose a hosted traditional server, that someone else owns and manages, but that isn't essential to cloud computing any more than it is to traditional server computing.
There is no general requirement to redistribute code with modified FOSS software anyway. That's a feature specific to particular licenses (particularly, the GPL.)
Of course its meaningful. If you have a local server that you own, and you choose not to back it up, and it fails with a complete loss of data, that isn't primarily a problem with owning a local server, or with the particular server operating system (though there may be factors associated with either of those that contribute to the crash), its a problem with you choosing not to back up data.
If you have a single traditional server that you pay for access to, but is owned and managed by someone else with your data, and the same thing happens because you didn't assure (e.g., via contract) that the server would be backed up, again, the problem is with your failure.
If you have a cloud using one or more local physical servers that you manjage (e.g., using the cloud software included with Ubuntu Server), and the same thing happens, its not a problem with either cloud technology in general or the particular cloud technology you used, again, its a problem with your choice not to back it up.
If you instead pay for the use of someone else's cloud to host your virtual server instances than either you should be backing them up (if you manage the virtual servers, even though the vendor will be managing the physical servers and the cloud software) or you should assure that the vendor managing the virtual servers is backing them up (if a vendor, either the cloud vendor or someone else, is doing that for you.) If the servers aren't backed up, its your fault, and not the (general or specific) cloud technologies fault.
There's no fuzzy definition involved here. The problem is quite simply one of failing to plan for recovery in the case of failure. This is a need that is independent of whether your logical servers are identical to your physical servers or whether they are decoupled as is the case in cloud technology, and likewise independent of whether your physical servers are owned by you and located in your data center or owned by someoneone else and located in their data center (or any mix and match of ownership and location), and further independent of whether you manage your logical servers personally (or with your regular employees) or contract out for the management of them.
This is not a failure of cloud technology, it is a failure of the particular parties managing this particular implementation to do something to which the the use or not of cloud technologies is completely irrelevant.
It is (like every patent described on Slashdot) described poorly.
The patent is not a business-model patent for time-based licensing, its a technology patent for a specific scheme of enforcing time-based licensing rules.
The way its described in TFS there would certainly be massive prior art. I'm less sure about the particular scheme they're actually trying to patent.
Though, from the description in TFA, regardless of prior art, the scheme seems painfully obvious, so I wouldn't be surprised if existing time-based licenses use this enforcement scheme already.
Right. GNU is an operating system. It contains many things, including a kernel (Hurd) which is not the kernel which is at the heart of any Linux distribution (the Linux kernel.)
Now, because some of the components of GNU are open source and useful, some of them -- including lots of other stuff not from GNU maintained by people other than Linus Torvalds -- are often packaged together with the Linux kernel to make a complete OS distribution. Usually, such a distribution has a name (like "Ubuntu" or "Fedora") and often the distributor tags on "Linux" because identifying it as such helps people understand what kind of operating system it is.
Certain people want those distros to be called "GNU/Linux" because they include GNU components, but rarely argue that distributions that include components other than the Linux kernel besides GNU components should also have those other components honored alongside GNU in every discussion.
Well, if Android overtakes the the mobile version of OSX for smartphones and similar non-phone devices, it is more like the year of the Linux palmtop.
Actually, if we are talking about what is likely to be successful in the future, rather than what is successful right now, we do need to have some understanding of the causes of why the public likes what they like. Simply stating that "X is popular now, which means the public likes it and we don't need to examine why, and it will always, therefore, remain the most popular" doesn't really cut it.
I bought an iPhone because it seemed to be the best mobile device for my interests at the time I bought it. I also bought it under the firm belief (which has only been reinforced since) that by the time I bought my text smartphone, the iPhone probably wouldn't be where I was going, and that something like Android probably would. Even if underlying desires never changed (which they do), how well different products meet them can and does change.
But Google isn't, and isn't going to be, making Android devices to sell to consumers. Lots of phone vendors (and some non-phone vendors -- e.g., the reported B&N e-Reader) are and plan to do that.
And Microsoft doesn't make Windows (whether you are talking the traditional OS or the movile one) devices to sell to consumers, at least not most of them; lots of hardware vendors do that.
No it doesn't necessarily mean that. However, the fact that many vendors has consequences for Android; it means, among other things, that its not tied to the success of any one particular hardware vendors efforts. Plus it means that its quite likely that more different strategies will be tried with it by hardware vendors, which gives it more chances that one of them will hit it out of the park.
Yes, they could.
Both this and the preceding point seem to confuse an analysts prediction of what is most likely to occur (against which there may be many valid criticisms) with a statement that that is the only thing which is logically possible.
Ignorance of the law may not be an excuse, generally, but most crimes do have a required mental state which often includes (but is not limited to) awareness of material facts related to the wrongful conduct.
Yes, because the completely different political BS around F/OSS doesn't usually stop you from being able to legally use the software.
Actually, I think its a common term to refer to operating systems that use the Linux kernel collectively, because more specific designations (either like "Ubuntu" or like "GNU/Linux") don't generally work for that purpose, though sometimes some of them may be appropriate fro some subset of Linux-based operating systems.
For instance, if I release software that is designed to run on a Linux based operating system with specific identified dependencies, that does not rely on features of a particular distribution or tools or libraries other than those in the listed dependencies, it makes more sense to describe it as being for Linux, with the specific required dependencies, than to say it is for "GNU/Linux" (since, insofar as it requires anything from GNU, that's already covered by the listed dependencies), or for "Ubuntu" (since it doesn't require anything specific to Ubuntu) or for anything else.
I'm pretty sure both automatically installing dependencies and automatically pruning those no longer needed can be disabled when using apt via the command line tools, though perhaps not through all graphical front-ends. (I've never had to avoid either, but I'm pretty sure I've seen the options to do so.)
I was struck by (not severely, but enough to delay non-essentials) reduced income which has delayed that decision; I'm still leaning toward one of the "nettop" oriented Atoms (by the time I get around to it now, probably one of the new D-series ones, since I understand the 230/330 are goint to be phased out when they are introduced).
That sounds like a good choice: I'd rather keep something existing and repurpose it, but unfortunately my only operational but not otherwise committed computer is a a fairly old laptop that has some issues that make unattractive for use in a situation where it would be on for long periods of time. So I am kind of left with building fresh.
This is not true. The DMCA sets no limits on when you can dispute a takedown notice. It just doesn't require the service provider to notify the user until after (though "promptly" after) the material has been taken down, in order to remain in the safe harbor against liability to the user. Provided that it didn't interfer with the providers ability to "expeditiously" disable access to the material, a provider could remain within the safe harbor provision while notifying users before disabling access, particularly if they happened to be able to notify them in real time.
Since the DMCA allows electronic signatures on coutnernotice, if they had an online, standard counternotice form as well, it might even be possible for them to provide a very brief window in which it was possible to file the counternotice before the access was disabled without falling outside of the requirements of either safe harbor provision.
OTOH, providers are concerned about being sued by media companies, with whom they have no contracts limiting their liabilities, and not so much by their users, with whom they usually have contracts which are set up to restrict liability. So they are much more concerned with the safe harbor with respect to complaining potential copyright holders than anything else with regard to the DMCA takedown provisions.
To be fair, I was in the opposite position, having only looked previously at the 230/330 thinking about using one of those for an inexpensive Linux server at home; I wasn't aware that the N/Z models weren't 64-bit, too. I started writing GP with "Actually, the Intel Atom processors are 64-bit processors", but then decided to do some checking before I posted it.
Specifically current Intel Atom "Diamondville" N- and "Silverthorne" Z-series processors intended for netbooks and UMPCs, other Atoms (current "Diamondville" 230/330, and the upcoming [Q1, 2010] "Pineview" D- (replaces "Diamondville" 230/330) and "Pineview" N- (replaces the current "Diamondville" N) series Atoms are all 64-bit.
There are plenty of existing programming environments where the programmer doesn't interact with code as a linear string of text; including in systems that use executable diagrams (often things like BPMN), and, by far the most common example, spreadsheets.
While its true that Google Voice isn't VoIP, Apple's official statement on rejecting Google Voice indicated that part of the reason is that it might be VoIP.
AFAICT, those people don't advocate the same ideas as RMS. Raymond himself discusses the FSF as a distinct faction with a different ideology than his within the broader hacker community.
The main idea that Linus Torvalds seems to advocate is making software that works. While GNU, Stallman, and the GPL probably wouldn't be as important as they are without Torvalds and Linux (particularly, had Linux not exploded while BSD went through some legal birth pangs), Torvalds and Stallman aren't really advocates of the same philosophy, they are, inasmuch as Torvalds is an advocate of any philosophy, advocates of different philosophies that happen to occasionally coincide in terms of the actions they suggest (and, at other times, to be almost directly opposed.)
The problem appears to be, in part, latency induced by the number of layers above the bare metal that are involved, so I'm not sure Mono would get much improvement. They apparently threw away the existing COBOL-based system in favor of a complete reimplementation for .NET back in 2005, so if they did that again it wouldn't be entirely unprecedented.
Because Microsoft used the app and its supposed superiority in the area it was deployed as a major case study in the strength of the Microsoft programming and platform components used in the implementation: the products called out in their case study include the .NET Framework, Windows Server, SQL Server, Visual Studio .NET, Microsoft Operations Manager, ASP.NET, and Visual C# .NET (I may have missed some.) A quote: "In a highly competitive environment, the London Stock Exchange is gaining a considerable cost advantage over its competitors by using the .NET Framework and Visual C# .NET." (source: Microsoft.)
If it says something about the platform when you are getting the sale (because it outperforms the preceding implementation), then it also says something about the platform when the Exchange looks to replace you with something that outperforms your implementation.