Serious government corruption work in this style involves the revolving door. You get a job for a company you regulated while in office, making that job be how you get paid for the preferential treatment you gave them. Then, after a few years collecting, you move back into the government. Lather, rinse, repeat.
In the US, the people playing games with non-profits are amateurs compared to the revolving door crowd in the financial and defense industries.
I'd be quite happy if Android vendors did any sort of backport to older devices, even a hobbled one with the latest features stripped out. Apple's platform has plenty of issues around running on older hardware, sure. Their record for continuously pushing out security updates to devices that are a few years old is, on average, way ahead of everything but the Nexus Android phones though. The way vendors abandon old hardware in Android land is building a frighteningly large installed base of badly secured phones out there. One component to the cheaper Android phones is that they're putting $0 into worrying about any long-term security issues on that hardware, and I worry about how that will bite everyone in the ass one day.
Without the disclaimer, the comments here would have an even heavier dose of "you suck, learn how to do your job" abuse. That a non-profit organization might not want to pay for in-house technical staff capable of doing this makes more sense to some people.
Even when I download Linux packages in C, it's often the case that I can't compile them, because I'm missing some obscure library that the original developer just assumed I had.
But when you're using a packaged Linux distribution like RedHat, Debian, or SuSE, all of this information is part of the package metadata in the source code packages. On Debian for example, if you request: apt-get buld-dep xxx
You'll get all of the packages needed to build package xxx. The same package metadata also contains the other things you were worried about like compiler information too Having the source package metadata is why it's feasible to recreate the packages that came with many Linux distributions with only a bit of drift from the original. If you have a source RPM/DEB package, you just ask for it to be built and all of the requirements/compiler stuff is taken care of for you.
That's the point - a good tool shouldn't needlessly push you towards a particular workflow, which is what the staging area does. Yes, that's by default, but it means the default adds non-essential steps and complexity.
All tools push you toward a particular workflow. You're making the same mistake as the person I replied to, where you judge the software by how well it fits your personal workflow preference. If you think this adds complexity you don't want, turn it off and move on; your problem is solved. git cannot change the defaults here to suit everyone. Whatever they pick is going to be a problem for some people, so Linus just picked the one he likes, someone added the alternative, and everyone moved on. And that's the only good way to proceed. All a program like git can do is provide options that meet all the popular workflow choices and then return to getting work done.
Whether you prefer to include all modifications in a commit is a workflow driven decision. I like the way git's default pushes me to review each change once before it goes in. Going through a round of "git status" and reviewing what's staged is a good coding practice when many people are going to consume what you commit. And that's exactly the situation git's defaults are setup to support--an environment where mistakes are going to be consumed by a lot of people.
You seem to feel that your way is the One True Workflow, and everyone who does it some other way is doing it wrong. That's fine, and you should create an environment to make that happen. But you're claiming the default "can't be justified" because you, personally, don't like it. You don't get to claim the UI is bad simply because it's not yours, especially when the behavior you want is actually part of that UI.
Companies that throw submissions upstream and then fork if they're not all accepted are not very useful to me. RedHat has one set of rules about what sorts of changes they're willing to accept in a stable release, the Linux kernel developers have another. Oracle is content to fork both and make changes, with their own policy for what is and isn't acceptable. Some of the ignored submissions are due to those policy differences, others ignored because Oracle wasn't willing to work within the community development process. Oracle doesn't considering aligning its work with other development communities to be as important as pushing them out in their own version; they'd rather brag about how they have the better answer.
In general I frown on projects that fork healthy code rather than working out how to integrate their changes into the upstream development model. No one company can develop code so great that it's worth abandoning the mainstream Linux kernel development for them, but Oracle believes they are such a company. I'm not impressed; I'll take every kernel developer in the world that worries about upstream integration instead.
The whole point of this article is that RedHat is putting effort into this switch. Individual users may not see it, but this mess is causing headaches for people who maintain and distribute open source software stacks. And incompatibilities for users are coming one day too, as soon as the feature set starts drifting between MySQL and MariaDB.
In any large organization, guaranteeing that something you do will not get distributed outside of its original domain adds a compliance cost. The idea that compliance with a license is overhead that really does cost something has already been beaten into larger organization's heads by the terms of commercial software like Microsoft's, where audits and possible violations are a real cost of doing business.
Companies familiar with open source licenses know that if they touch GPL code but keep it private, they're on the hook for continuing the comply with the related license terms. Who can say if five years from now, today's internal application will move outside its original boundaries? Having restrictive license terms paperwork that has to follow the application around forever is exactly the kind of crap governments adopting open source software are trying to get rid of.
If you just use something with a BSD or MIT license from day one, you don't even have to worry about it. All of the paperwork and license review CYA compliance audit costs are up-front.
Open source doesn't remove the damage here, it just contains it. Look at how much effort is being wasted by people who are switching from MySQL to MariaDB now. All of that overhead is damage to an open source community that could have been working on other things with that time. If you're smart, instead you'll switch to a truly open database, one that doesn't have a company requiring copyright assignment involved at all.
MySQL was a reasonable choice back when PostgreSQL didn't have Windows support and people needed that to do development. Now there's really no good reason to put efforts into a MySQL->MariaDB change, not when there are viable free alternatives and MariaDB has the same fundamental problem that destroyed MySQL. The right answer for an open source community is to route completely past MySQL and its ugly dual-licensed code altogether, use this transition point to migrate off there altogether.
Which part of that is supposed to make people feel comfortable that MariaDB will still be around in a few years, after Monty gets an offer to buy that company? "Insanity is repeating the same mistakes and expecting different results"
MySQL filled a niche for web application development, but not very much else. The large banks are all using old-school commercial databases: Oracle, DB2, Sybase, SQL Server. Government applications prefer PostgreSQL because of its permissive license. If they want to customize the source code for a project that isn't pubic, they can do that without having to worry about GPL compliance.
The main thing Oracle Linux does is run a newer kernel version than the RHEL kernel. RHEL6 for example is based on 2.6.32, while Oracle's Unbreakable Enterprise Kernel R.2 (pdf) was running 3.0.16 when they last updated things.
Grabbing the newer kernel lets Oracle win direct performance shootouts against RedHat. They can get away with it because the only applications they're testing on it is Oracle, so if the upstream kernel breaks other things they don't care. RedHat cares about all of their supported software, so they have a lot more QA issues to deal with. Note that this little trick is also how Oracle has gotten around caring that RedHat made it harder to see what individual patches they apply to the upstream kernel in their release. They aren't using that version of kernel at all, so whatever RedHat is doing to customer their 2.6.32 branch they're ignoring.
Of course, if you're willing to do this, you can easily grab a newer Linux kernel from kernel.org yourself on regular RHEL, too. The game Oracle is playing with "Unbreakable Linux" is all marketing hype.
I wasn't claiming that the enthusiast side of the market is impacting CPU design. An AC who didn't understand the comment they were replying to said that.
There are two separate questions here that are easy to mix up. First, do people experimenting with overclocking provide value to the rest of the hardware market? That seems true. There are useful trends that have come out of the overclocking crowd in the last ten years, ones that then trickled into the mainstream. They have mainly involved cases and fans, and water cooling is an obvious example. That this happens validates overclocking hacks for CPUs can provide something useful to the rest of the world, that they're not just wasting time.
Intel does pay a little bit of attention to the enthusiast market and what's popular there. That is the target market for these unlocked multiplier chips after all. And they provide basic CPU fans with their processors. Intel's retail box fans have improved a lot over the years, to be much more competitive with the ethusiast ones. There it's not so clear that Intel was following the lead of the overclockers at any point though. If your bar is "do overclockers help Intel and AMD make better chips", that data exists but it's weak.
Features like water cooling for CPUs started as bleeding edge overclocking craziness, and now I can get a ready to go kit at my local computer store. That's the sort of thing overclockers are helping with. Intel and AMD don't spent that much time playing with fans and chassis hardware.
Some people feel they can criticize overclockers for not having a life, while they are busy doing Important Work posting to Slashdot.
I can normally overclock systems where I benefit from higher CPU performance to get at least a 10% boost on tasks I wait for, compiling large programs is the most common one. Memory errors are more likely when overclocked. The last one I ran into was a very intermittent but repeatable crash, it happened when I had 8 threads running all the time for >16 hours. But if you're not running a server class machine with ECC, uncorrectable memory errors are going to pop up regardless. Most of the time I see overclocking issues are no worse than crashes from things like driver bugs.
I did my first write heavy deployment of PostgreSQL on Intel DC S3700 drives about a month ago, with each one of them replacing two Intel 710 drives. The write performance is at least doubled--the server is more than keeping up even with half the number of drives--and in some cases they easily look as much as 4X faster than the 710s. I've been able to get the 710 drives to degrade to pretty miserable read performance on mixed read/write workloads too, as low as 20MB/s, but the DC S7300 drives don't seem to fall down that way either. I'm replacing older Intel drives that are struggling with DC S7300 models now as fast as I can get them.
My advice to you is to go buy the machine with the most cores and most ram and be happy with it
I did, and that machine wasn't a Mac. And from the looks of where they're going now, it never will be again. The Mac Pro towers have always been expensive and some upgrades like RAM were priced weirdly. But in general they came with the feel of having the best type of system you could reasonably buy in that form factor. This is no longer the case. The smallest system I'd consider a real workstation now would have 24 cores and >=64GB of RAM, and that's today. By that measure Apple's new desktop is obsolete before it's even shipping, and it will look completely ridiculous if they go years between refreshes again.
You can get AFP support for shares from FreeNAS, and from a few commercial NAS boxes: Netgear ReadyNAS, QNAP, and Synology. I use the ReadyNAS when I'm looking for something cheap, and the Synology if I'm looking for better features like encryption. I'm listening to music streaming off of a ReadyNAS AFP volume as I write this.
Claiming that the EFF is some sort of enforcer working for large companies to beat up small ones is an idea that can only have come from heavy use of hallucinogenic drugs. Which ones does your team take?
Slashdot Mirror
Serious government corruption work in this style involves the revolving door. You get a job for a company you regulated while in office, making that job be how you get paid for the preferential treatment you gave them. Then, after a few years collecting, you move back into the government. Lather, rinse, repeat.
In the US, the people playing games with non-profits are amateurs compared to the revolving door crowd in the financial and defense industries.
I'd be quite happy if Android vendors did any sort of backport to older devices, even a hobbled one with the latest features stripped out. Apple's platform has plenty of issues around running on older hardware, sure. Their record for continuously pushing out security updates to devices that are a few years old is, on average, way ahead of everything but the Nexus Android phones though. The way vendors abandon old hardware in Android land is building a frighteningly large installed base of badly secured phones out there. One component to the cheaper Android phones is that they're putting $0 into worrying about any long-term security issues on that hardware, and I worry about how that will bite everyone in the ass one day.
Without the disclaimer, the comments here would have an even heavier dose of "you suck, learn how to do your job" abuse. That a non-profit organization might not want to pay for in-house technical staff capable of doing this makes more sense to some people.
Perl had a good sized install base and a healthy community, and then they tried this with Perl 6.0. Can't imagine it would go any better for PHP.
Even when I download Linux packages in C, it's often the case that I can't compile them, because I'm missing some obscure library that the original developer just assumed I had.
But when you're using a packaged Linux distribution like RedHat, Debian, or SuSE, all of this information is part of the package metadata in the source code packages. On Debian for example, if you request:
apt-get buld-dep xxx
You'll get all of the packages needed to build package xxx. The same package metadata also contains the other things you were worried about like compiler information too Having the source package metadata is why it's feasible to recreate the packages that came with many Linux distributions with only a bit of drift from the original. If you have a source RPM/DEB package, you just ask for it to be built and all of the requirements/compiler stuff is taken care of for you.
Here's a fun one: search for PHP mysql_query code and glory at all of the input sanitizing they do.
That's the point - a good tool shouldn't needlessly push you towards a particular workflow, which is what the staging area does. Yes, that's by default, but it means the default adds non-essential steps and complexity.
All tools push you toward a particular workflow. You're making the same mistake as the person I replied to, where you judge the software by how well it fits your personal workflow preference. If you think this adds complexity you don't want, turn it off and move on; your problem is solved. git cannot change the defaults here to suit everyone. Whatever they pick is going to be a problem for some people, so Linus just picked the one he likes, someone added the alternative, and everyone moved on. And that's the only good way to proceed. All a program like git can do is provide options that meet all the popular workflow choices and then return to getting work done.
Lucas doesn't need version control for his Star Wars changes. Once he's got the new one, he throws all of the old versions away.
Whether you prefer to include all modifications in a commit is a workflow driven decision. I like the way git's default pushes me to review each change once before it goes in. Going through a round of "git status" and reviewing what's staged is a good coding practice when many people are going to consume what you commit. And that's exactly the situation git's defaults are setup to support--an environment where mistakes are going to be consumed by a lot of people.
You seem to feel that your way is the One True Workflow, and everyone who does it some other way is doing it wrong. That's fine, and you should create an environment to make that happen. But you're claiming the default "can't be justified" because you, personally, don't like it. You don't get to claim the UI is bad simply because it's not yours, especially when the behavior you want is actually part of that UI.
Government projects are spun off into contractors or other commercial entities all the time.
Companies that throw submissions upstream and then fork if they're not all accepted are not very useful to me. RedHat has one set of rules about what sorts of changes they're willing to accept in a stable release, the Linux kernel developers have another. Oracle is content to fork both and make changes, with their own policy for what is and isn't acceptable. Some of the ignored submissions are due to those policy differences, others ignored because Oracle wasn't willing to work within the community development process. Oracle doesn't considering aligning its work with other development communities to be as important as pushing them out in their own version; they'd rather brag about how they have the better answer.
In general I frown on projects that fork healthy code rather than working out how to integrate their changes into the upstream development model. No one company can develop code so great that it's worth abandoning the mainstream Linux kernel development for them, but Oracle believes they are such a company. I'm not impressed; I'll take every kernel developer in the world that worries about upstream integration instead.
The whole point of this article is that RedHat is putting effort into this switch. Individual users may not see it, but this mess is causing headaches for people who maintain and distribute open source software stacks. And incompatibilities for users are coming one day too, as soon as the feature set starts drifting between MySQL and MariaDB.
In any large organization, guaranteeing that something you do will not get distributed outside of its original domain adds a compliance cost. The idea that compliance with a license is overhead that really does cost something has already been beaten into larger organization's heads by the terms of commercial software like Microsoft's, where audits and possible violations are a real cost of doing business.
Companies familiar with open source licenses know that if they touch GPL code but keep it private, they're on the hook for continuing the comply with the related license terms. Who can say if five years from now, today's internal application will move outside its original boundaries? Having restrictive license terms paperwork that has to follow the application around forever is exactly the kind of crap governments adopting open source software are trying to get rid of.
If you just use something with a BSD or MIT license from day one, you don't even have to worry about it. All of the paperwork and license review CYA compliance audit costs are up-front.
Open source doesn't remove the damage here, it just contains it. Look at how much effort is being wasted by people who are switching from MySQL to MariaDB now. All of that overhead is damage to an open source community that could have been working on other things with that time. If you're smart, instead you'll switch to a truly open database, one that doesn't have a company requiring copyright assignment involved at all.
MySQL was a reasonable choice back when PostgreSQL didn't have Windows support and people needed that to do development. Now there's really no good reason to put efforts into a MySQL->MariaDB change, not when there are viable free alternatives and MariaDB has the same fundamental problem that destroyed MySQL. The right answer for an open source community is to route completely past MySQL and its ugly dual-licensed code altogether, use this transition point to migrate off there altogether.
Which part of that is supposed to make people feel comfortable that MariaDB will still be around in a few years, after Monty gets an offer to buy that company? "Insanity is repeating the same mistakes and expecting different results"
MySQL filled a niche for web application development, but not very much else. The large banks are all using old-school commercial databases: Oracle, DB2, Sybase, SQL Server. Government applications prefer PostgreSQL because of its permissive license. If they want to customize the source code for a project that isn't pubic, they can do that without having to worry about GPL compliance.
The main thing Oracle Linux does is run a newer kernel version than the RHEL kernel. RHEL6 for example is based on 2.6.32, while Oracle's Unbreakable Enterprise Kernel R.2 (pdf) was running 3.0.16 when they last updated things.
Grabbing the newer kernel lets Oracle win direct performance shootouts against RedHat. They can get away with it because the only applications they're testing on it is Oracle, so if the upstream kernel breaks other things they don't care. RedHat cares about all of their supported software, so they have a lot more QA issues to deal with. Note that this little trick is also how Oracle has gotten around caring that RedHat made it harder to see what individual patches they apply to the upstream kernel in their release. They aren't using that version of kernel at all, so whatever RedHat is doing to customer their 2.6.32 branch they're ignoring.
Of course, if you're willing to do this, you can easily grab a newer Linux kernel from kernel.org yourself on regular RHEL, too. The game Oracle is playing with "Unbreakable Linux" is all marketing hype.
I wasn't claiming that the enthusiast side of the market is impacting CPU design. An AC who didn't understand the comment they were replying to said that.
There are two separate questions here that are easy to mix up. First, do people experimenting with overclocking provide value to the rest of the hardware market? That seems true. There are useful trends that have come out of the overclocking crowd in the last ten years, ones that then trickled into the mainstream. They have mainly involved cases and fans, and water cooling is an obvious example. That this happens validates overclocking hacks for CPUs can provide something useful to the rest of the world, that they're not just wasting time.
Intel does pay a little bit of attention to the enthusiast market and what's popular there. That is the target market for these unlocked multiplier chips after all. And they provide basic CPU fans with their processors. Intel's retail box fans have improved a lot over the years, to be much more competitive with the ethusiast ones. There it's not so clear that Intel was following the lead of the overclockers at any point though. If your bar is "do overclockers help Intel and AMD make better chips", that data exists but it's weak.
Features like water cooling for CPUs started as bleeding edge overclocking craziness, and now I can get a ready to go kit at my local computer store. That's the sort of thing overclockers are helping with. Intel and AMD don't spent that much time playing with fans and chassis hardware.
What's with this attitude on this article?
Some people feel they can criticize overclockers for not having a life, while they are busy doing Important Work posting to Slashdot.
I can normally overclock systems where I benefit from higher CPU performance to get at least a 10% boost on tasks I wait for, compiling large programs is the most common one. Memory errors are more likely when overclocked. The last one I ran into was a very intermittent but repeatable crash, it happened when I had 8 threads running all the time for >16 hours. But if you're not running a server class machine with ECC, uncorrectable memory errors are going to pop up regardless. Most of the time I see overclocking issues are no worse than crashes from things like driver bugs.
I did my first write heavy deployment of PostgreSQL on Intel DC S3700 drives about a month ago, with each one of them replacing two Intel 710 drives. The write performance is at least doubled--the server is more than keeping up even with half the number of drives--and in some cases they easily look as much as 4X faster than the 710s. I've been able to get the 710 drives to degrade to pretty miserable read performance on mixed read/write workloads too, as low as 20MB/s, but the DC S7300 drives don't seem to fall down that way either. I'm replacing older Intel drives that are struggling with DC S7300 models now as fast as I can get them.
In Soviet Russia, HBO shares you!
My advice to you is to go buy the machine with the most cores and most ram and be happy with it
I did, and that machine wasn't a Mac. And from the looks of where they're going now, it never will be again. The Mac Pro towers have always been expensive and some upgrades like RAM were priced weirdly. But in general they came with the feel of having the best type of system you could reasonably buy in that form factor. This is no longer the case. The smallest system I'd consider a real workstation now would have 24 cores and >=64GB of RAM, and that's today. By that measure Apple's new desktop is obsolete before it's even shipping, and it will look completely ridiculous if they go years between refreshes again.
You can get AFP support for shares from FreeNAS, and from a few commercial NAS boxes: Netgear ReadyNAS, QNAP, and Synology. I use the ReadyNAS when I'm looking for something cheap, and the Synology if I'm looking for better features like encryption. I'm listening to music streaming off of a ReadyNAS AFP volume as I write this.
Claiming that the EFF is some sort of enforcer working for large companies to beat up small ones is an idea that can only have come from heavy use of hallucinogenic drugs. Which ones does your team take?