Let us try to separate the security matters.
A protocol can be insecure - say if it provides no reliable means of authentication, or if it transmits all information in clear text. Implementations of a secure protocol can be insecure - that is, buggy -, and implementations of insecure protocols can do their best not to add any insecurity.
BSD is not dead, nor is it dying.
The r-tools are insecure protocols, since they transfer sensible information in clear text. I am not for enabling the daemons by default installs.
But I don't think they should be removed.
The clients should definately not be removed, in my opinion, I do not see any insecurity in having an rlogin client installed.
A system will not be much more secure than its admin is capable. Security has always been a compromise.
I believe in security, I appreciate OpenBSD's security code auditing teams, yet OpenBSD's claim "Four years without a remote root security hole in the default install!" does not impress me too much. If the default install is with everything disabled, or configured in some rather restricted way, it is not much of worth to most. People talk all the time about network security, disabling services and daemons, etc. Let us remember the more common type of security problems still, local. Most systems serve users. Local security is just as important, if not more. And not all holes immediately give superuser access to the exploiter, yet they are dangerous. Would it have been "4 years without an exploitable security problem in the OpenBSD code base", this would mean quite more already.
So I think telnet, rlogin, rsh, rexec and ftp should be left in. telnetd, rlogind, rshd, rexecd, and ftpd should also be left in, just disabled by default in inetd, administrators will enable those they need as they know what they are doing.
The code of all those should be audited just like the rest of the distribution. Data being transmitted as plain text is not a security hole in the system. It is known to the admin, just as it is known that passwords can be guessed brute-force.
In an internal academic/corporate network, usually some hosts are trusted, and some users are. Each organization has its security policy, describing how to decide what is trusted. If an host is trusted, the route from it is just as trusted. No encryption will help here. Sometimes rhosts based authentication bypassing is useful.
Encryption won't solve everything. It is a bad illusion for anyone that if the communication is encrypted, it can suddenly be all 100% trusted and safe. A well administered site ran by competent admins and with a good security policy, I would trust much more than a site where ssh and encryption is trusted for everything.
Also, as always, there is a point of interoperability, and compatibility. You cannot switch all your organization, definately not all the environment around it, to different protocols and utilities that easily, and with the Internet attached, it gets even more difficult.
If you think that all utilities/work methods can be secured just by replacing them like this, it isn't so easy.
I am pro advancement, and I think changing things, switching to more secure protocols/systems, is all a good idea, but at its time, as the site's administrators consider it... It cannot be done at once, and should not be done by the maintainers of the distribution.
As for Perl on FreeBSD, I'm very much for it. Most of the BSD systems I use are FreeBSD, then BSDi BSD/OS... Saving a few tenths of megabytes in the distribution, just as simplifying the build and installation process is a good step, Perl is nowhere as standard for a network as the r-tools are, and the system's core scripts/tools shouldn't depend on it. Where it is wanted, install it from the ports tree, or just build it from plain sources...
It might be good idea if the r-tools could be just a backward compatibility part of the ssh stuff... So say, ftp, unless given a specific flag, will by default do sftp, and resort to old style ftp only if that failes, and rsh will be ssh, which will also support the rsh/rlogin/etc. protocols...
Actually, I would say I feel the recent 2.4 kernels are more stable then the 2.2 ones.
Does anyone have any point of fact, or reason for claiming that the 2.4 branch is less stable? I mean, the first few were... But the late ones seem pretty fine to me.
Of course you could point out a few unsuccessful ones, like 2.4.9 with VM performance problems, 2.4.13 - I think - not even compiling with the parallel port driver, a filesystem corruption bug in 2.4.15-final... But those bugs were pinpointed in a few hours after the release... I wouldn't install a kernel right after it releases, but with 2.4, in the long run, the kernels are quite stable.
So right, sometimes the maintainers are drunk while releasing... But when they're sober, it's fine...
It depends upon how you define freedom. If freedom means never having to ask the author for permission, then no, the GPL is not free.
I don't define freedom as never having to ask the author for permission. I define freedom as being free to distribute, modify, use, study, or enhance my information.
Freedom doesn't mean you can do everything you wish to do, without any limitations. Freedom needs to have reasonable limitations. Like free countries restricting the citizen's freedom to murder others, in order to preserve others' freedom - if you're murdering, you're taking someone else's freedoms away. So therefore here your freedom is restricted.
But according to the rules of the GPL, a license freer than the GPL is just as bad as one that is more restrictive.
No. But a licenses less restrictive than the GPL, might in longer terms lead to derivatives with licenses more restrictive than the GPL.
But a question: If the GPL is free despite its restrictions, since the end developers agrees to those restrictions, then why aren't proprietary licenses free as well? Don't users of VC++ also voluntarily give up their freedoms when they agree not to distribute code linked to the MFC libraries? Oh...wait...you're allowed to distribute...without restriction your code developed using VC++ and MFC... Damn. I'll have to think of another analogy.
No, in fact, Microsoft's newer licenses for some of their.NET development products, actually forbit you from writing free yet copylefted software with them. Not because of incompatibility with the copyleft, but it just states in the licenses that you may not write copylefted software with those products...
I'd say not much.../proc/cpuinfo, as far as I know, gives you the speed the CPU is working at - that is, if a 900MHz CPU is overclocked to 1.4GHz,/proc/cpuinfo will give you "cpu MHz : 1400"...
KDE/Gnome/Netscape etc also crash a whole lot more than Explorer.
I don't use KDE or GNOME as desktop environments (CTWM/Enlightenment for me), but I do use some KDE and GNOME applications. And I don't use Netscape as my brower, but mostly Konqueror/Galeon and Lynx sometimes. And most applications I use under X, be them KDE/GNOME apps or others like Emacs, crash far less than Windows 2000/Microsoft Internet Explorer for me.
Linux gets stability at the expensive of not being flexible.
At the expense of not being flexible? Hmm... In my opinion, Unix/Linux, is far more flexible than Windows or Mac OS or whatever. I can automate almost everything I want with shell scripts, I can set up things the way I want, have decent application API's...
Windows supports 100X more hardware than Linux - that's the only reason why windows (NT) can get unstable.
As for hardware support, yeah, Windows does have some (but not 100 times, not even 2 times) more hardware support than Linux on Intel PC's, but that's mostly because more hardware manufacturers write their drivers for Windows, and then give it to Microsoft. Where things are involved that the OS typically has natively, Linux has better hardware support. On the Intel PC's it supports optimizations for all kinds of CPU's, relatively good drivers for all standard interfaces like IDE/SCSI/ATA/PCI/ISA/AGP, etc. You wouldn't run Windows 2000 on a SPARC/m68k/MIPS system, would you? Oh, and when Itanium starts shipping...
And I don't see how more hardware support, when implemented properly and on a properly written kernel, will cause the system to crash.
So, stability - Linux has it better IMO. Flexibility - Clearly any Unix has it better than Windows/Mac OS. Hardware support - yeah, Windows has some advantage here in the PC market, but see my remark, and personally, I don't have any hardware unsupported by Linux, most such Hardware is just crap (winmodems, for example).
Now as far as bloatation goes... Well, I run Linux on systems Windows can't dream to run on (would you run Windows 2000 on a 80486 66MHz with 16MB of RAM and a 240MB HD, for example? Linux functions great as a server on such a machine), and I have a machine with a Pentium MMX 200MHz and 64MB of RAM, on which Linux runs great, and Windows 2000 runs... but you really feel its bloatation. Now some would say that's a stupid argument, because such systems aren't sold these days anymore... To which I'll answer that's right, but even on a very strong system, I'd prefer the resources to go for other things than OS bloatation...
There are some areas where Windows might fit better, but those aren't stability/flexibility/performance...
Video games, for example... aren't Linux's best target (and probably won't be), and you care less if your game of Quake or whatever crashes every some time, than if your server does... But probably if it wouldn't be for market share, some other system/platform would take on them rather than Windows.
How many times has X or Gnome crashed on you today?
I don't use GNOME as my environment, see above. X hasn't crashed on me today, or yesterday, or in the last month, for that matter.
I haven't tried the 0.9.2/0.9.3 Mozilla releases yet, but the ones I tried were heavy as hell. How much has 0.9.3 improved with regard to load time/lightweight-ness?
So it's worth giving a try for those who had stability problems with it in previous releases. Is it also worth giving a try also those who were disappointed by Mozilla's bloatation in previous releases?
Hmm... I looked at the previous article on this subject ("Microsoft EULA stokes crusades"), where it gives a link to the EULA, but that link seems to be broken. Has anyone got any idea where I could see the fine print of this license?
(Or maybe do I need to sign another license contract to gain access to the text of this license?)
SIG: An application running across the network didn't close properly - Windows will now shut down.
Slashdot Mirror
Let us try to separate the security matters.
A protocol can be insecure - say if it provides no reliable means of authentication, or if it transmits all information in clear text.
Implementations of a secure protocol can be insecure - that is, buggy -, and implementations of insecure protocols can do their best not to add any insecurity.
BSD is not dead, nor is it dying.
The r-tools are insecure protocols, since they transfer sensible information in clear text. I am not for enabling the daemons by default installs.
But I don't think they should be removed.
The clients should definately not be removed, in my opinion, I do not see any insecurity in having an rlogin client installed.
A system will not be much more secure than its admin is capable. Security has always been a compromise.
I believe in security, I appreciate OpenBSD's security code auditing teams, yet OpenBSD's claim "Four years without a remote root security hole in the default install!" does not impress me too much. If the default install is with everything disabled, or configured in some rather restricted way, it is not much of worth to most. People talk all the time about network security, disabling services and daemons, etc. Let us remember the more common type of security problems still, local. Most systems serve users. Local security is just as important, if not more. And not all holes immediately give superuser access to the exploiter, yet they are dangerous. Would it have been "4 years without an exploitable security problem in the OpenBSD code base", this would mean quite more already.
So I think telnet, rlogin, rsh, rexec and ftp should be left in. telnetd, rlogind, rshd, rexecd, and ftpd should also be left in, just disabled by default in inetd, administrators will enable those they need as they know what they are doing.
The code of all those should be audited just like the rest of the distribution. Data being transmitted as plain text is not a security hole in the system. It is known to the admin, just as it is known that passwords can be guessed brute-force.
In an internal academic/corporate network, usually some hosts are trusted, and some users are. Each organization has its security policy, describing how to decide what is trusted. If an host is trusted, the route from it is just as trusted. No encryption will help here. Sometimes rhosts based authentication bypassing is useful.
Encryption won't solve everything. It is a bad illusion for anyone that if the communication is encrypted, it can suddenly be all 100% trusted and safe. A well administered site ran by competent admins and with a good security policy, I would trust much more than a site where ssh and encryption is trusted for everything.
Also, as always, there is a point of interoperability, and compatibility. You cannot switch all your organization, definately not all the environment around it, to different protocols and utilities that easily, and with the Internet attached, it gets even more difficult.
If you think that all utilities/work methods can be secured just by replacing them like this, it isn't so easy.
I am pro advancement, and I think changing things, switching to more secure protocols/systems, is all a good idea, but at its time, as the site's administrators consider it... It cannot be done at once, and should not be done by the maintainers of the distribution.
As for Perl on FreeBSD, I'm very much for it. Most of the BSD systems I use are FreeBSD, then BSDi BSD/OS... Saving a few tenths of megabytes in the distribution, just as simplifying the build and installation process is a good step, Perl is nowhere as standard for a network as the r-tools are, and the system's core scripts/tools shouldn't depend on it. Where it is wanted, install it from the ports tree, or just build it from plain sources...
It might be good idea if the r-tools could be just a backward compatibility part of the ssh stuff... So say, ftp, unless given a specific flag, will by default do sftp, and resort to old style ftp only if that failes, and rsh will be ssh, which will also support the rsh/rlogin/etc. protocols...
All that, though, is just my 2^-2 cent...
Uh... well, I never encountered that... Are you sure that box isn't faulty?
Actually, I would say I feel the recent 2.4 kernels are more stable then the 2.2 ones.
Does anyone have any point of fact, or reason for claiming that the 2.4 branch is less stable? I mean, the first few were... But the late ones seem pretty fine to me.
Of course you could point out a few unsuccessful ones, like 2.4.9 with VM performance problems, 2.4.13 - I think - not even compiling with the parallel port driver, a filesystem corruption bug in 2.4.15-final... But those bugs were pinpointed in a few hours after the release... I wouldn't install a kernel right after it releases, but with 2.4, in the long run, the kernels are quite stable.
So right, sometimes the maintainers are drunk while releasing... But when they're sober, it's fine...
I don't define freedom as never having to ask the author for permission. I define freedom as being free to distribute, modify, use, study, or enhance my information.
Freedom doesn't mean you can do everything you wish to do, without any limitations. Freedom needs to have reasonable limitations. Like free countries restricting the citizen's freedom to murder others, in order to preserve others' freedom - if you're murdering, you're taking someone else's freedoms away. So therefore here your freedom is restricted.
No. But a licenses less restrictive than the GPL, might in longer terms lead to derivatives with licenses more restrictive than the GPL.
No, in fact, Microsoft's newer licenses for some of their .NET development products, actually forbit you from writing free yet copylefted software with them. Not because of incompatibility with the copyleft, but it just states in the licenses that you may not write copylefted software with those products...
Anyway, for what it might interest, I recently (a month or more ago) wrote an "article" with my opinion on the GPL vs. BSD license wars - http://www.cs.huji.ac.il/~alsbergt/freedom/gplbsd. html.
And by restricting your freedom to any software you want what will it ensure ?
Not much. But by restricting companies' freedom to sell you non-free software, you are helping more software be free.
I'd say not much... /proc/cpuinfo, as far as I know, gives you the speed the CPU is working at - that is, if a 900MHz CPU is overclocked to 1.4GHz, /proc/cpuinfo will give you "cpu MHz : 1400"...
KDE/Gnome/Netscape etc also crash a whole lot more than Explorer.
I don't use KDE or GNOME as desktop environments (CTWM/Enlightenment for me), but I do use some KDE and GNOME applications. And I don't use Netscape as my brower, but mostly Konqueror/Galeon and Lynx sometimes. And most applications I use under X, be them KDE/GNOME apps or others like Emacs, crash far less than Windows 2000/Microsoft Internet Explorer for me.
Linux gets stability at the expensive of not being flexible.
At the expense of not being flexible? Hmm... In my opinion, Unix/Linux, is far more flexible than Windows or Mac OS or whatever. I can automate almost everything I want with shell scripts, I can set up things the way I want, have decent application API's...
Windows supports 100X more hardware than Linux - that's the only reason why windows (NT) can get unstable.
As for hardware support, yeah, Windows does have some (but not 100 times, not even 2 times) more hardware support than Linux on Intel PC's, but that's mostly because more hardware manufacturers write their drivers for Windows, and then give it to Microsoft. Where things are involved that the OS typically has natively, Linux has better hardware support. On the Intel PC's it supports optimizations for all kinds of CPU's, relatively good drivers for all standard interfaces like IDE/SCSI/ATA/PCI/ISA/AGP, etc. You wouldn't run Windows 2000 on a SPARC/m68k/MIPS system, would you? Oh, and when Itanium starts shipping...And I don't see how more hardware support, when implemented properly and on a properly written kernel, will cause the system to crash.
So, stability - Linux has it better IMO. Flexibility - Clearly any Unix has it better than Windows/Mac OS. Hardware support - yeah, Windows has some advantage here in the PC market, but see my remark, and personally, I don't have any hardware unsupported by Linux, most such Hardware is just crap (winmodems, for example).
Now as far as bloatation goes... Well, I run Linux on systems Windows can't dream to run on (would you run Windows 2000 on a 80486 66MHz with 16MB of RAM and a 240MB HD, for example? Linux functions great as a server on such a machine), and I have a machine with a Pentium MMX 200MHz and 64MB of RAM, on which Linux runs great, and Windows 2000 runs... but you really feel its bloatation. Now some would say that's a stupid argument, because such systems aren't sold these days anymore... To which I'll answer that's right, but even on a very strong system, I'd prefer the resources to go for other things than OS bloatation...
There are some areas where Windows might fit better, but those aren't stability/flexibility/performance...Video games, for example... aren't Linux's best target (and probably won't be), and you care less if your game of Quake or whatever crashes every some time, than if your server does... But probably if it wouldn't be for market share, some other system/platform would take on them rather than Windows.
How many times has X or Gnome crashed on you today?
I don't use GNOME as my environment, see above. X hasn't crashed on me today, or yesterday, or in the last month, for that matter.
I haven't tried the 0.9.2/0.9.3 Mozilla releases yet, but the ones I tried were heavy as hell. How much has 0.9.3 improved with regard to load time/lightweight-ness?
So it's worth giving a try for those who had stability problems with it in previous releases. Is it also worth giving a try also those who were disappointed by Mozilla's bloatation in previous releases?
Hmm... I looked at the previous article on this subject ("Microsoft EULA stokes crusades"), where it gives a link to the EULA, but that link seems to be broken. Has anyone got any idea where I could see the fine print of this license?
(Or maybe do I need to sign another license contract to gain access to the text of this license?)
SIG:
An application running across the network didn't close properly - Windows will now shut down.