I have no idea why you say "Couldn't agree less" when eliminating most if not all IRC services is exactly what I meant. Open relay mail servers are relentlessly exposed, hounded, and blocked by most email servers.
But by the way, do not begin to pretend that most installations of Jabber are any better administered than most installations of IRC. Plain text passwords stored on the server is just an amazingly bad idea: it's almost as stupid as Subversion keeping your user passwords in plain taext in your home directory.
My goodness, you are mixing up things. Chimps are not carnivores. They're omnivores. And lots of people will eat omnivores: bears and possums come to mind from US hunting, and I've eaten both. There's a real infection problemm with carnivorous primates, I admit, but it's probably less of a factor than the difficulty hunting them.
I'm afraid you're considering the infection problem to be a Bad Idea with capital letters. It's a significant risk, with small letters. Issues like AIDS are relatively new: hunger and poverty are old and familiar risks.
His blinders on linguistics are even worse (it was his original field). The idea that all humans speak the same fundamental language, programmed into their neurology, matches his political beliefs. And it's as unnessary as a theory, and as demonstrably wrong.
Really? What do you call the Iran-Iraq war of the 1980's? The one where Iranian children were carrying suicide bombs up to Iraqis? Where do you think the Iranians learned how to fight a guerrilla war against a technologically superior enemy, a craft they're now funding and teaching to occupied Iraq?
Israel is dangerous, but Iran and nuclear weapons scares me more because they have no aim. The Israelis at least hit what they're aiming at. (As they've demonstrated against Iranian nuclear power plants.)
People have been eating bush meat since our species evolved with incisors and canines. It's *not* eating bush meat that's a bit odd, over the evolutionary time scale. And it's hardly just chimps: it's anything you can find and kill to eat in the bush. It's a real problem for endangered species: when human population growth shrinks their habitates and numbers, and then those hungry humans hunt them to feed starving children because the fertilizer prices went up or the civil war has destroyed jobs and burned crops, it's very hard to tell people not to feed their children.
Oh, it's not just corporate needs. Take a look at Dan Bernstein's licenses, or confusing COPYRIGHT based lack thereof. The source is open, but you can't fork it, you can't repackage it in a way he doesn't like, and you can't call it the same name if you modify it in a way he doesn't like.
Bernstein's work is often brilliant, but it's seriously hindered by his inability to play nice with existing standards. This includes his weird kind-of-sort-of-not-really software licensing.
Not only are you right, but even when the perpetrators are hunted down, nothing happens to them. Take a look at the Morris Worm and the David Lamachia case for good examples of how perpetrators escape punishment. (Morris's father was the head of the NSA: LaMacchia was an MIT student and MIT's lawyers did a great job of stonewalling the prosecution to avoid a student being convicted, and apparently encouraged the prosecution to file charges trying to set an unlikely precedent, making people who host warez responsible for them even if they don't get paid.)
I'm afraid that most software tools are not inherently better than those in 1997: most attackers, and even most successful attacks, are by script kiddies with tools. Even skilled crackers like Mitnick consistently make foolish mistakes. (In Mitnick's case, it was leaving messages mocking his victims and getting the FBI really, really mad at him,, angry enough to actually prosecute.) There are plenty of vaunted crackers who make other amazingly stupid mistakes, both programming and social.
The IRC-bot creators seem to be among the worst of the script kiddies. Frankly, IRC should go the way of open relays. Too much of the traffic is illegitimate to justify allowing it through any firewalls or any ISP provided system. It should be blocked even before non-ISP-server bound SMTP, simply for damage control.
I can't access the article right now: please tell me it was cracked because a script kiddie read is Subversion passwords from an NFS home directory or an passphrase-free SSH key. Please?
Oh, I'm very familiar with the CentOS/RedHat distinctions. It's far more than one package of difference: especially for the port of RHEL 5, CentOS eliminated that insane separation among Server/VT/Cluster/my-refrigerator-butter-drawer/et c. that confuses software package management on the installation media.
Unfortunately, some of the repositories have interesting conflict issues. A kernel from Centosplus that supports NTFS by default will be overwritten by the the RHEL kernel, even if you set the Centosplus repository as preferred, because the RHEL repository plugin for yum isn't actually yum based. It's up2date based, and it seems to ignore all the yum directives except possibly the "--exclude" options of yum.conf. This seriously breaks software repository management.
Yum is actually. RedHat's embrasure of Yum is cluttered by their desire to not let clients download the update repository. This traps people into the need for the "yum-rhn-plugin", which ignores all the priority and preferred source settings of other yum repositories and puts the RedHat sourced.
This kind of DRM based craziness is one of the most compelling reasons to use CentOS, along with CentOS willingness to include NTFS drivers and more up-to-date software in their "centosplus" repositories. It's a shame, really: I'd happily get RedHat kernel and software support with licenses if they didn't waste my time this way.
If you can't bother to do security right, don't bother writing a protocol. I'm serious: I've seen way, way too many versions of "exciting new protocols!" such as jabber clients where the author added some cool feature and then left everything as porous as a sieve by default. The result is that people like me have to clean up the mess, and then people wonder why it takes us so long to do things when they can just set one up at home in 10 minutes.
If you can't be bothered to store keys properly, you should at the very minimum not make it the default configuration for your SVN, HTTP, and HTTPS access technologies. It should require at the very minimum an extra command line flag marked something like "--insecure".
* Virtualization is becoming supported in the main-line kernel. This is big news, since it makes running dual or triple operating systems on one box far easier, especially running that Windows operating system to use the Outlook calendar or play games.
* Network storage. Making the same software and storage available to run the operating system itself, via NFS-boot or iSCSI, makes a big change in physical architecture and major system deployments.
* Multiple cores. Scaliing up to handle big computational projects is a big deal, for both industrial computing and for gaming.
Linus doesn't have to invent any more major new technologies: he's doing plenty of good work, and organizing other people to do it. That makes him a *saint* in the technology world. The only person more fundamental is Richard Stallman, and Linus is a lot easier to interview.
>> So instead of having two or three years between stable releases, we now have two or three months. Which means that the vendor kernels are much closer to the development kernels, and avoids a lot of the problems we used to have. Everybody is happier.
Oh. Oh, my. Pleae, please tell me this is going to be true. I am so very tired of under-experienced kernel developers who get a fetish about a particular kernel, turn it into an entangled and never documented proprietary mess, then force other people to backport things from the next major kernel release. I'm also very tired of the profound pain of major kernel upgrades.
Keep the upgrades small and frequent: small changes mean small mistakes, even if it breaks major OS vendor models of "the kernel we released with version 2.0 is the kernel we still support for it seven years later".
It can happen, but usually because you've tripped over a threshold. Loading up Java, for example, or taking a *little* bit more RAM and starting to swap can make a huge performance difference. And an optimized implementation of a heavily used function can make a big diffreence in specific applications: take a look at the old Squid "select" problems, as described at http://www.usenix.org/publications/login/1999-2/sq uid.html.
No, I'm afraid you really don't end up with the same product. Having that apprentice in the kitchen mix up the eggs and chop the onions for you saves time, and lets you spend your time making sure the omelette doesn't burn. Having to do all that OS building from scratch adds a lot of uncertainty, and the likelihood that some subtle difference (such as an updated perl module or slightly updated glibc) will seriously alter your environment.
It's fun, it's a great learning experience, and it's great for flexibility. But when I want 100 OS's in my racks in 2 hours, I use a kickstart or ather pre-built OS with auto-installer, so I don't have to tweak the Gentoo "secret sauce" to re-integrate things.
Quite right. I swear, pot is cheap again, because the article reads like the political beliefs of the stoned kids from my college dorms.
I can just picture them now, half-covered in pizza stains, "D-o-o-o-d! If we just, like, just, all put our money in a big pot and only took what we needed, like, dude, we'd all have enough to be, like, rich! And that goldfish has, like, amazing colors!"
Thank you, you saved me the trouble of looking up these dates. Experience can help you appreciate where these things actually started and why they've evolved in certain ways.
For goodness's sake, try to compile Linux without the GNU versions of make, gzip, and gcc.
Slashdot Mirror
I have no idea why you say "Couldn't agree less" when eliminating most if not all IRC services is exactly what I meant. Open relay mail servers are relentlessly exposed, hounded, and blocked by most email servers.
But by the way, do not begin to pretend that most installations of Jabber are any better administered than most installations of IRC. Plain text passwords stored on the server is just an amazingly bad idea: it's almost as stupid as Subversion keeping your user passwords in plain taext in your home directory.
It could be inter-species fornication: take a look at the "woman humped to death by camel" story at http://clipmarks.com/clipmark/AFECFC7A-8BC4-4619-9 7EE-9EBCBD660B01/.
My goodness, you are mixing up things. Chimps are not carnivores. They're omnivores. And lots of people will eat omnivores: bears and possums come to mind from US hunting, and I've eaten both. There's a real infection problemm with carnivorous primates, I admit, but it's probably less of a factor than the difficulty hunting them.
I'm afraid you're considering the infection problem to be a Bad Idea with capital letters. It's a significant risk, with small letters. Issues like AIDS are relatively new: hunger and poverty are old and familiar risks.
His blinders on linguistics are even worse (it was his original field). The idea that all humans speak the same fundamental language, programmed into their neurology, matches his political beliefs. And it's as unnessary as a theory, and as demonstrably wrong.
Really? What do you call the Iran-Iraq war of the 1980's? The one where Iranian children were carrying suicide bombs up to Iraqis? Where do you think the Iranians learned how to fight a guerrilla war against a technologically superior enemy, a craft they're now funding and teaching to occupied Iraq?
Israel is dangerous, but Iran and nuclear weapons scares me more because they have no aim. The Israelis at least hit what they're aiming at. (As they've demonstrated against Iranian nuclear power plants.)
People have been eating bush meat since our species evolved with incisors and canines. It's *not* eating bush meat that's a bit odd, over the evolutionary time scale. And it's hardly just chimps: it's anything you can find and kill to eat in the bush. It's a real problem for endangered species: when human population growth shrinks their habitates and numbers, and then those hungry humans hunt them to feed starving children because the fertilizer prices went up or the civil war has destroyed jobs and burned crops, it's very hard to tell people not to feed their children.
That way, they'll only watch porn all night and never actually lay a hand on anything female.
Oh, it's not just corporate needs. Take a look at Dan Bernstein's licenses, or confusing COPYRIGHT based lack thereof. The source is open, but you can't fork it, you can't repackage it in a way he doesn't like, and you can't call it the same name if you modify it in a way he doesn't like.
Bernstein's work is often brilliant, but it's seriously hindered by his inability to play nice with existing standards. This includes his weird kind-of-sort-of-not-really software licensing.
Not only are you right, but even when the perpetrators are hunted down, nothing happens to them. Take a look at the Morris Worm and the David Lamachia case for good examples of how perpetrators escape punishment. (Morris's father was the head of the NSA: LaMacchia was an MIT student and MIT's lawyers did a great job of stonewalling the prosecution to avoid a student being convicted, and apparently encouraged the prosecution to file charges trying to set an unlikely precedent, making people who host warez responsible for them even if they don't get paid.)
I'm afraid that most software tools are not inherently better than those in 1997: most attackers, and even most successful attacks, are by script kiddies with tools. Even skilled crackers like Mitnick consistently make foolish mistakes. (In Mitnick's case, it was leaving messages mocking his victims and getting the FBI really, really mad at him,, angry enough to actually prosecute.) There are plenty of vaunted crackers who make other amazingly stupid mistakes, both programming and social.
The IRC-bot creators seem to be among the worst of the script kiddies. Frankly, IRC should go the way of open relays. Too much of the traffic is illegitimate to justify allowing it through any firewalls or any ISP provided system. It should be blocked even before non-ISP-server bound SMTP, simply for damage control.
I can't access the article right now: please tell me it was cracked because a script kiddie read is Subversion passwords from an NFS home directory or an passphrase-free SSH key. Please?
You're right. You should find and punish the person or group who forced that software to be installed on your machine.
Ohh. I thought you had accidentally copied a newbie-written Perl file to to .bash_history. That explains why it looked so coherent!
Oh, I'm very familiar with the CentOS/RedHat distinctions. It's far more than one package of difference: especially for the port of RHEL 5, CentOS eliminated that insane separation among Server/VT/Cluster/my-refrigerator-butter-drawer/et c. that confuses software package management on the installation media.
Unfortunately, some of the repositories have interesting conflict issues. A kernel from Centosplus that supports NTFS by default will be overwritten by the the RHEL kernel, even if you set the Centosplus repository as preferred, because the RHEL repository plugin for yum isn't actually yum based. It's up2date based, and it seems to ignore all the yum directives except possibly the "--exclude" options of yum.conf. This seriously breaks software repository management.
Yum is actually. RedHat's embrasure of Yum is cluttered by their desire to not let clients download the update repository. This traps people into the need for the "yum-rhn-plugin", which ignores all the priority and preferred source settings of other yum repositories and puts the RedHat sourced.
This kind of DRM based craziness is one of the most compelling reasons to use CentOS, along with CentOS willingness to include NTFS drivers and more up-to-date software in their "centosplus" repositories. It's a shame, really: I'd happily get RedHat kernel and software support with licenses if they didn't waste my time this way.
If you can't bother to do security right, don't bother writing a protocol. I'm serious: I've seen way, way too many versions of "exciting new protocols!" such as jabber clients where the author added some cool feature and then left everything as porous as a sieve by default. The result is that people like me have to clean up the mess, and then people wonder why it takes us so long to do things when they can just set one up at home in 10 minutes.
If you can't be bothered to store keys properly, you should at the very minimum not make it the default configuration for your SVN, HTTP, and HTTPS access technologies. It should require at the very minimum an extra command line flag marked something like "--insecure".
Well. I see several big changes:
* Virtualization is becoming supported in the main-line kernel. This is big news, since it makes running dual or triple operating systems on one box far easier, especially running that Windows operating system to use the Outlook calendar or play games.
* Network storage. Making the same software and storage available to run the operating system itself, via NFS-boot or iSCSI, makes a big change in physical architecture and major system deployments.
* Multiple cores. Scaliing up to handle big computational projects is a big deal, for both industrial computing and for gaming.
Linus doesn't have to invent any more major new technologies: he's doing plenty of good work, and organizing other people to do it. That makes him a *saint* in the technology world. The only person more fundamental is Richard Stallman, and Linus is a lot easier to interview.
You know, if I wanted to read that much material, I'd download your source and compile you myself. And this is what the binary would look like.
* It is too faster!
* You're a wimp for not building it yourself.
See how much faster it is to just grab the binary? It doesn't have all the granularity of control, but it saves people a lot of work.
This really caught my eye in the article:
>> So instead of having two or three years between stable releases, we now have two or three months. Which means that the vendor kernels are much closer to the development kernels, and avoids a lot of the problems we used to have. Everybody is happier.
Oh. Oh, my. Pleae, please tell me this is going to be true. I am so very tired of under-experienced kernel developers who get a fetish about a particular kernel, turn it into an entangled and never documented proprietary mess, then force other people to backport things from the next major kernel release. I'm also very tired of the profound pain of major kernel upgrades.
Keep the upgrades small and frequent: small changes mean small mistakes, even if it breaks major OS vendor models of "the kernel we released with version 2.0 is the kernel we still support for it seven years later".
It can happen, but usually because you've tripped over a threshold. Loading up Java, for example, or taking a *little* bit more RAM and starting to swap can make a huge performance difference. And an optimized implementation of a heavily used function can make a big diffreence in specific applications: take a look at the old Squid "select" problems, as described at http://www.usenix.org/publications/login/1999-2/sq uid.html.
No, I'm afraid you really don't end up with the same product. Having that apprentice in the kitchen mix up the eggs and chop the onions for you saves time, and lets you spend your time making sure the omelette doesn't burn. Having to do all that OS building from scratch adds a lot of uncertainty, and the likelihood that some subtle difference (such as an updated perl module or slightly updated glibc) will seriously alter your environment.
It's fun, it's a great learning experience, and it's great for flexibility. But when I want 100 OS's in my racks in 2 hours, I use a kickstart or ather pre-built OS with auto-installer, so I don't have to tweak the Gentoo "secret sauce" to re-integrate things.
It's even more traditional to go directly to "troll the readers" when there's not going to be any more SCO news for a while.
Who bombd the LAPD?
Quite right. I swear, pot is cheap again, because the article reads like the political beliefs of the stoned kids from my college dorms.
I can just picture them now, half-covered in pizza stains, "D-o-o-o-d! If we just, like, just, all put our money in a big pot and only took what we needed, like, dude, we'd all have enough to be, like, rich! And that goldfish has, like, amazing colors!"
Thank you, you saved me the trouble of looking up these dates. Experience can help you appreciate where these things actually started and why they've evolved in certain ways.
For goodness's sake, try to compile Linux without the GNU versions of make, gzip, and gcc.