Watch this sort of announcement very, very carefully. Microsoft loves to describe Linux as a 'UNIX variant'. In both its basic kernel and its accumulated software bundles, it's as valid as calling Windows XP "DOS". (For those new to Microsoft history, XP is actually a Windows NT descendant, which is in many ways descended from VMS and many of its fundamentals stolen by David Cutler from DEC, where David wrote much of VMS and was hired to work on NT.)
Oh, my. Have you tried cross-porting Apache or some some of the extended sets of Perl module chains or Java based applications with their amazingly bad installers lately, and porting them to a legacy or one of the weirder UNIX variants lately? I can only bless with every breath the people who have usually already done it for me. Why, why, why does every new Perl module author insist on re-inventing the wheel to write their own installer? And why do so many new software component authors through out ant, Make, or autoconf and insist on writing their own standard-violating installer tool? (Yes, Sun, I'm talking to you with your little "rpm.bin" widgets, which actually unpack an RPM and a bunch of documentation you didn't ask for with no indication that the name of the.rpm has _nothing_ to do with the actual name of the software it installs.)
Thank you _very_ much for chiming in. Your objections seem.... oh, dear, how can I put this without insulting you as a developer of a game I've enjoyed.
I can't. Stop whinging. You're raising philosophical objections to commercial software, and they're contradicted by the excellent example of companies like RedHat. Instead, stay focus on what is specific to these developers' behavior: failure to make clear that the source is under a free license, and where to get the source easily.
Disk encryption is handy, for traveling with a USB device, protecting a laptop from a corporate "partner" when you connect to a network to do a presentation, or avoiding having the Chinese or US federal agencies illegally scan your laptop data without a warrant.
As much as we might love you for bringing a pretty cool old game to the very user-friendly Iphone, and being thoughtful about GPL in doing so, I'd like to see the correspondence with the original author or authors about this. I'm finding it difficult to believe that programmers as skilled and creative as these were could be so foolish as to believe that merely charging for the Iphone application, _as long as the source code is available_ under GPL, is a problem.
In fact, by making the less open projects on Iphones look like muddleware (which most cell phone apps are), in provide some very good GPL publicity.
Oh, my. Let's first distinguish between 'open source' and 'free software'. CentOS is almost entirely 'free software', it's mostly GPL.
Second. What "third party"? There's an organization in place: they need to mature a little bit and set up some non-profit organization safeguards, to avoid exactly this surprise, like all non-profits that move from one leader's insightful project to a going concern. I hadn't realized they hadn't already done this. And the structure that RedHat, as a for-profit company, uses is amazingly diferent than what Apache with its major independent development team uses, and what CentOS needs as a freeware package of RedHat's software.
Handing it off to a third-party oversight group is asking for CentOS to die, and force the old Whitebox project or another like it to take up the reighns. I don't want that: CentOS has earned itself a name for good support, faster turnaround than RedHat on some issues (due to being able to upgrade packages over in the centosplus branch as needed, or to include features such as NTFS support that might cause legal issues if RedHat did it), and frankly provides a much better 'yum' support environment than RedHat's licensed 'yum-rhn-plugin' utility provides and which overrides basic yum tuning features.
I'm curious to see what comes out of this, out of self-interest for projects that I develop on CentOS and deploy on RHEL because funding for test setups is scarce.
RedHat skating? Sir or madam, RedHat is driving the Zamboni that makes the ice smooth, selling people skates, repairing ramps to the ice, cleaning up the litter left by others on the rink, and generally being incredibly good neighbors in the open source community. They are buying new technologies and paying the developers to _write_ the free software they publish, and paying people to integrate and quality test the software.
You know when CentOS releases are going out of support: when RedHat abandons their upstreams, plus at least six months. (The centosplus side repository is very useful this way.)
Is it better for cities to rely on such stupid pieces of low-bidder refuse for tools like parking meters and US passports? (http://blogs.zdnet.com/storage/?p=540) Most RFID implementations simply are not secure: they're typically no more reliable than a barcode, which is also easily spoofed.
And sadly, it's the fault of both the technology (which remains limited by budget marketing to very simply devices) and by inabilities to agree on updates to their encryption and authentication techologies (look up 'new encryption standards for RFID' on Google for references). The infighting among the vendors is horrible, and is delaying improved technologies.
No, he's not. He wants to see Alan's git repository, or a recent upload of it, with the last set of patches on it. That's not necessarily in the public repositories at www.kernel.org, although I'll bet there's a published location for it. I've not needed to play with pre-release code for years now, but things have changed, and the switch to git for source control for code management means it may not have been committed to what is the public master repository, or it may be in a git branch, which can be a bit trickier to find and review.
I'm really impressed with git, by the way. After CVS, subversion's improvements but still flawed attempt to fix CVS, and working with Perfore and Bitkeeper and other source control systems with corporate partners, I'm happy to use git. But it does have a learning curve.
With that all said, I'm afraid that Linus was right on this: this commit should be rolled back until it can be fixed with the various userland cases, because chasing it down is taking so long and so much time with the flaw incompletely addressed. It's a problem with big projects: reasonable ideas get blocked until weird, client-land border cases can get addressed, and the result slows progress a lot on both performance and security issues.
Please remember that most "private" networks aren't. They have laptop or VPN access to potentially compromised hosts, which may insert attacks from behind your typical firewalls. I've had considerable difficulty explaining this to management who have, effectively, been lied to for years by their own staff who refuse to accept responsibility for the existing insecure mess, and who are uninterested in the unglamorous and unpopular work of fixing it.
Because you may have a stack of other pending updates, particularly kernels, and this has been the first "gotta switch" update in quite some time for those core servers? Also because without the occasional reboot under scheduled maintenance, it's hard to be sure your machines will come up in a disaster. (I've had some gross screwups in init scripts and kernels cause that.)
WINE is far less resource intensive, and typically runs far faster, than fully virtualized simulation software, especially because it leaves out the basically rewritten-VMS kernel and memory management of the Windows kernel in favor of Linux's own pretty zippy kernel. And the cost of buying and running a million actual Windows boxes to avoid the performance penalties of virtualization is simply infeasible.
Killing one person to save another or for other reasons is, in fact, shoving one people's set of morals down another person's throat. Or rather, across the throat with a sharp blade, or a dull rope. The idea that no morals should ever block medical treatment is as impossible as the idea that everyone should be free to do whatever they want: physics, available resources, and the conflicts between different people's desires always limit such things.
Look, I've not said that stem cell research is unreasonable or improper. In general, I've no problem with it: they're tissue samples. But let's drop this sophomoric concept that morals do not apply to medicine: medicine is a field where morals are vital for providing it and for supporting it.
Good. Your moral code won't bother me at all as I raid your bank account for money, and your body for organs, for anyone I care to heal.
Morals are _always_ tied to medical treatment, or you're just having fun doing research and can't be bothered to check your results or avoid killing your patients.
I'm genuinely surprised if your datacenter network isolation is as good as you describe. I've seen such setups specified, even written into contract, and then seen idiots plugging random personal laptops into the secured corpirate subnets simply to get work done. (TFTP setups to update ocre switches are a prime example where I've noticed technicians installing personal hardware.)
It's not technologically "hard" to secure your network. But it takes sophisticated upstream switches to avoid ARP poisoning, and someone with a clue to configure it, and such resources are often pretty expensive. I'm just not seeing it in use: "authorized" personnel with VPN access are some of the worst potential vectors into such a secured network.
Yes. For such a facility, physical access is restricted. Do you have a VPN into that environment? Then it's vulnerable to use and abuse by the VPN members, and I've unfortunately just this week explained the facts of life about this to a manager at a partner company who wanted his unpatched, unsecured personal laptop to have access to his company's internal servers "so he can look at things". If I were his IT guy, I'd have been compelled to satisfy his request, because he helps sign the checks. But I'm afraid that sort of thing is typical.
The New Zealand paper is actually interesting. And it, not unreasonably, tries to extend the definition of "instinct" to include learned behaviors, behaviors that may be propagated for reasons that make complete evolutionary sense but are transmitted by learning, not by genetics. Unfortunately, when it went to silliness like "Therefore, if it be the case that the insect possesses the power of inheriting memories", it went to the same silly place as believing that animals can inherit traits surgically grafted onto their parents. (This is sometimes called Lamarckianism.) The idea has been widely discredited by experiment, and it's not necessary to support the existing data.
And that is an unusual definition. If you're going to use that non-genetic definition, mention it. And one of the big, big issues with such "instinctive" behaviors is that they are fairly easily overridden. Skinner demonstrated that baby ducks, for instance, can be trained to teat other objects as their mothers if they "imprint" on them.
Greed, unfortunately, is a different story. Not because it's not taught, or extremely well established in human culture, but because it arises as a very obvious "evolutionary" tactic for organisms. It's an emergent behavior of complex systems, described by the "Tragedy of the Commons" and by Robert Malthus' work on food supplies versus population. There's nothing "primitive" about it: it's fundamental to systems that compete, like thermodynamics and feedback. Your point that "we humans are stuck" with greed is like saying we're stuck with eating food: getting to a place where greed is not a major factor is conceivable, but unlikely.
Can greed be limited and managed? To some extent, certainly. But calling it "primitive", as you did repeatedly, is like calling the number "3" primitive. It's a very strange claim.
Slashdot Mirror
Watch this sort of announcement very, very carefully. Microsoft loves to describe Linux as a 'UNIX variant'. In both its basic kernel and its accumulated software bundles, it's as valid as calling Windows XP "DOS". (For those new to Microsoft history, XP is actually a Windows NT descendant, which is in many ways descended from VMS and many of its fundamentals stolen by David Cutler from DEC, where David wrote much of VMS and was hired to work on NT.)
Oh, my. Have you tried cross-porting Apache or some some of the extended sets of Perl module chains or Java based applications with their amazingly bad installers lately, and porting them to a legacy or one of the weirder UNIX variants lately? I can only bless with every breath the people who have usually already done it for me. Why, why, why does every new Perl module author insist on re-inventing the wheel to write their own installer? And why do so many new software component authors through out ant, Make, or autoconf and insist on writing their own standard-violating installer tool? (Yes, Sun, I'm talking to you with your little "rpm.bin" widgets, which actually unpack an RPM and a bunch of documentation you didn't ask for with no indication that the name of the .rpm has _nothing_ to do with the actual name of the software it installs.)
Thank you _very_ much for chiming in. Your objections seem.... oh, dear, how can I put this without insulting you as a developer of a game I've enjoyed.
I can't. Stop whinging. You're raising philosophical objections to commercial software, and they're contradicted by the excellent example of companies like RedHat. Instead, stay focus on what is specific to these developers' behavior: failure to make clear that the source is under a free license, and where to get the source easily.
Disk encryption is handy, for traveling with a USB device, protecting a laptop from a corporate "partner" when you connect to a network to do a presentation, or avoiding having the Chinese or US federal agencies illegally scan your laptop data without a warrant.
As much as we might love you for bringing a pretty cool old game to the very user-friendly Iphone, and being thoughtful about GPL in doing so, I'd like to see the correspondence with the original author or authors about this. I'm finding it difficult to believe that programmers as skilled and creative as these were could be so foolish as to believe that merely charging for the Iphone application, _as long as the source code is available_ under GPL, is a problem.
In fact, by making the less open projects on Iphones look like muddleware (which most cell phone apps are), in provide some very good GPL publicity.
Oh, my. Let's first distinguish between 'open source' and 'free software'. CentOS is almost entirely 'free software', it's mostly GPL.
Second. What "third party"? There's an organization in place: they need to mature a little bit and set up some non-profit organization safeguards, to avoid exactly this surprise, like all non-profits that move from one leader's insightful project to a going concern. I hadn't realized they hadn't already done this. And the structure that RedHat, as a for-profit company, uses is amazingly diferent than what Apache with its major independent development team uses, and what CentOS needs as a freeware package of RedHat's software.
Handing it off to a third-party oversight group is asking for CentOS to die, and force the old Whitebox project or another like it to take up the reighns. I don't want that: CentOS has earned itself a name for good support, faster turnaround than RedHat on some issues (due to being able to upgrade packages over in the centosplus branch as needed, or to include features such as NTFS support that might cause legal issues if RedHat did it), and frankly provides a much better 'yum' support environment than RedHat's licensed 'yum-rhn-plugin' utility provides and which overrides basic yum tuning features.
I'm curious to see what comes out of this, out of self-interest for projects that I develop on CentOS and deploy on RHEL because funding for test setups is scarce.
Really. Imagine all those people who'd get upset if Steve Jobs disappeared off the radar to get his liver replaced.
RedHat skating? Sir or madam, RedHat is driving the Zamboni that makes the ice smooth, selling people skates, repairing ramps to the ice, cleaning up the litter left by others on the rink, and generally being incredibly good neighbors in the open source community. They are buying new technologies and paying the developers to _write_ the free software they publish, and paying people to integrate and quality test the software.
Consider yourself corrected.
You know when CentOS releases are going out of support: when RedHat abandons their upstreams, plus at least six months. (The centosplus side repository is very useful this way.)
Is it better for cities to rely on such stupid pieces of low-bidder refuse for tools like parking meters and US passports? (http://blogs.zdnet.com/storage/?p=540) Most RFID implementations simply are not secure: they're typically no more reliable than a barcode, which is also easily spoofed.
And sadly, it's the fault of both the technology (which remains limited by budget marketing to very simply devices) and by inabilities to agree on updates to their encryption and authentication techologies (look up 'new encryption standards for RFID' on Google for references). The infighting among the vendors is horrible, and is delaying improved technologies.
You meant "spewed Java everywhere", didn't you?
_Which_ BSD? OpenBSD has Theo at its helm. If you think Linux gets cranky, oh dear, you've got some fun experience ahead of you.
No, he's not. He wants to see Alan's git repository, or a recent upload of it, with the last set of patches on it. That's not necessarily in the public repositories at www.kernel.org, although I'll bet there's a published location for it. I've not needed to play with pre-release code for years now, but things have changed, and the switch to git for source control for code management means it may not have been committed to what is the public master repository, or it may be in a git branch, which can be a bit trickier to find and review.
I'm really impressed with git, by the way. After CVS, subversion's improvements but still flawed attempt to fix CVS, and working with Perfore and Bitkeeper and other source control systems with corporate partners, I'm happy to use git. But it does have a learning curve.
With that all said, I'm afraid that Linus was right on this: this commit should be rolled back until it can be fixed with the various userland cases, because chasing it down is taking so long and so much time with the flaw incompletely addressed. It's a problem with big projects: reasonable ideas get blocked until weird, client-land border cases can get addressed, and the result slows progress a lot on both performance and security issues.
Please remember that most "private" networks aren't. They have laptop or VPN access to potentially compromised hosts, which may insert attacks from behind your typical firewalls. I've had considerable difficulty explaining this to management who have, effectively, been lied to for years by their own staff who refuse to accept responsibility for the existing insecure mess, and who are uninterested in the unglamorous and unpopular work of fixing it.
Because you may have a stack of other pending updates, particularly kernels, and this has been the first "gotta switch" update in quite some time for those core servers? Also because without the occasional reboot under scheduled maintenance, it's hard to be sure your machines will come up in a disaster. (I've had some gross screwups in init scripts and kernels cause that.)
Lease time on one of the larger botnets?
WINE is far less resource intensive, and typically runs far faster, than fully virtualized simulation software, especially because it leaves out the basically rewritten-VMS kernel and memory management of the Windows kernel in favor of Linux's own pretty zippy kernel. And the cost of buying and running a million actual Windows boxes to avoid the performance penalties of virtualization is simply infeasible.
I believe you meant to say "getting all Symantec". It's much funnier that way, and takes advantage of your partial spelling of 'semantic'.
When I was 20, _knotholes_ were attractive. Let's be honest about what most of us at that age would have been happy to spend a pleasant hour with.
Killing one person to save another or for other reasons is, in fact, shoving one people's set of morals down another person's throat. Or rather, across the throat with a sharp blade, or a dull rope. The idea that no morals should ever block medical treatment is as impossible as the idea that everyone should be free to do whatever they want: physics, available resources, and the conflicts between different people's desires always limit such things.
Look, I've not said that stem cell research is unreasonable or improper. In general, I've no problem with it: they're tissue samples. But let's drop this sophomoric concept that morals do not apply to medicine: medicine is a field where morals are vital for providing it and for supporting it.
Good. Your moral code won't bother me at all as I raid your bank account for money, and your body for organs, for anyone I care to heal.
Morals are _always_ tied to medical treatment, or you're just having fun doing research and can't be bothered to check your results or avoid killing your patients.
I'm genuinely surprised if your datacenter network isolation is as good as you describe. I've seen such setups specified, even written into contract, and then seen idiots plugging random personal laptops into the secured corpirate subnets simply to get work done. (TFTP setups to update ocre switches are a prime example where I've noticed technicians installing personal hardware.)
It's not technologically "hard" to secure your network. But it takes sophisticated upstream switches to avoid ARP poisoning, and someone with a clue to configure it, and such resources are often pretty expensive. I'm just not seeing it in use: "authorized" personnel with VPN access are some of the worst potential vectors into such a secured network.
Yes. For such a facility, physical access is restricted. Do you have a VPN into that environment? Then it's vulnerable to use and abuse by the VPN members, and I've unfortunately just this week explained the facts of life about this to a manager at a partner company who wanted his unpatched, unsecured personal laptop to have access to his company's internal servers "so he can look at things". If I were his IT guy, I'd have been compelled to satisfy his request, because he helps sign the checks. But I'm afraid that sort of thing is typical.
The New Zealand paper is actually interesting. And it, not unreasonably, tries to extend the definition of "instinct" to include learned behaviors, behaviors that may be propagated for reasons that make complete evolutionary sense but are transmitted by learning, not by genetics. Unfortunately, when it went to silliness like "Therefore, if it be the case that the insect possesses the power of inheriting memories", it went to the same silly place as believing that animals can inherit traits surgically grafted onto their parents. (This is sometimes called Lamarckianism.) The idea has been widely discredited by experiment, and it's not necessary to support the existing data.
And that is an unusual definition. If you're going to use that non-genetic definition, mention it. And one of the big, big issues with such "instinctive" behaviors is that they are fairly easily overridden. Skinner demonstrated that baby ducks, for instance, can be trained to teat other objects as their mothers if they "imprint" on them.
Greed, unfortunately, is a different story. Not because it's not taught, or extremely well established in human culture, but because it arises as a very obvious "evolutionary" tactic for organisms. It's an emergent behavior of complex systems, described by the "Tragedy of the Commons" and by Robert Malthus' work on food supplies versus population. There's nothing "primitive" about it: it's fundamental to systems that compete, like thermodynamics and feedback. Your point that "we humans are stuck" with greed is like saying we're stuck with eating food: getting to a place where greed is not a major factor is conceivable, but unlikely.
Can greed be limited and managed? To some extent, certainly. But calling it "primitive", as you did repeatedly, is like calling the number "3" primitive. It's a very strange claim.
Oh, yes. Thank you.