Did you miss the part of my comment about Debian remaining compatible from release to release? Are you claiming Debian don't already do that? Do you understand the implications that has on the necessity of testing applications against each Debian system release?
I'm astonished that Debian does this, since it clearly implies much extra work in testing an updated package (No wonder that Debian releases so seldom) That is why I misread your comment concerning compatability from release to release. On OpenBSD you may keep your already installed packages when upgrading, but no port is backported to an older release (unless it's critical for some reason).
So for OpenBSD this means that they have working installer, you can compile your own kernel on your own box and most of the basic tools exist (emphasis mine.)
It's requirement for a supported arch that not only the kernel, but userland (including thirdparty applications like perl, Apache httpd, BIND, Sendmail, gcc toolchain and more) must also be built natively: cross-compiling is not sufficient to claim support, unlike some other OS that shall be unnamed. Some archs, like vax, is limited by hardware, while others are not fully supported due to lack of documentation/hardware/resources.
In general, if an arch is supported, it is supported well.
All the ports are there in source, and they may work for you, but really, who knows?
Ports are tested on all platforms, but some ports are not supported on some platforms either due to hardware limitations or bugs in the application.
A supported arch in Debian parlance, on the other hand, means that there is a working installer, you can coompile your own kernel on your own box..
OpenBSD has higher standards than just to be able to compile a kernel natively: Userland must also be built natively and it must be a useable OS.
... and virtually every debian package can be auto-built and available in binary form.
Now, this is silly. Of course OpenBSD offers pre-compiled ports (ie packages) for every arch where it makes sense. Obviously, on vax, for instance, there will be a limited supply of applications that may run on such a platform. However, there are quite a few packages available (not cross-compiled):
ftp://ftp.openbsd.org/pub/OpenBSD/3.8/packages/vax
The idea isn't to skip testing, the idea is to decouple the release schedule of the OS from the release schedule of the applications.
So not only should the package maintainers test for OS release X, but also for several other releases as well. In addition there will be updated packages that needs testing. Nice idea, if you are willing to pay the (mostly) unpaid package maintainers to do this. Do you?
The only one I have any experience with is FreeBSD, and I can say for a fact that I would never dream of using an X.0 release of FreeBSD. Since I've started following their progress, it's always taken till at least X.4 before a major version was stable enough to consider for serious use.
OpenBSD has a different release policy (i.e. a release every six months) that works very well. The 3.9 release is coming 1th of May, but the release in November will have version 4.0. Of course, someone had to ask if 4.0 will be stable. Theo de Raadt answered thus:
>Yep, the developers magically do more in the 6 months preceding 4.0 >than the 6 months preceding any other release. That's definately how >it works.
We've been holding back about 50% of our work for each of the previous 4 releases, and now we are going to throw all those very large things into what will become 4.0. It is going to be a fantastic catastrophy, exactly like what all of you ".0 release" people expect.
I have been saying this for a long time. Basically to sum it up. Linux (and netbsd) ARE ready for the desktop.
I have been hearing this for a long time. Basically to sum it up: I don't understand this issue about "desktop readiness". What matters is that the applications you need are available and that drivers exist for your hardware.
Theo should consider himself lucky that RedHat didn't decide to put some of it's many talented and professional coders to work under a GNU licensed fork of SSH and cut off his revenue stream. Ethically and Legally there's nothing to prevent them (or anyone else) from doing just that.
If Redhat touched that code, do you think it will continue to be secure? And why would Redhat want to fork OpenSSH in the first place?
In theory, any software that runs on OpenBSD has to be audited for security, and any changes can be submitted upstream.
Ports (thirdparty software not in base system) is not audited that deeply quite simply because it would be too resource demanding. Note that the OpenBSD base system contains a lot of software.
They ignore that the driving principle in open source development is quality software, so everyone who works with it is always looking to find the flaws and remove them.
We would like to think so, however, the driving principle of many open source projects is
more features:
Revision 1.75.2.1 / (download) - annotate - [select for diffs] , Wed Jul 21 16:20:07 2004 UTC (20 months, 1 week ago) by robert Branch: OPENBSD_3_4 Changes since 1.75: +2 -1 lines Diff to previous 1.75 (colored) next main 1.76 (colored)
Mark it as BROKEN:
Right during 3.5, it had more than a dozen remote holes being fixed, that we shipped with. Weeks later things have not improved, and there continue to be problems reported to bugtraq, and respective band-aids - but it is clear the ethereal team does not care about security, as new protocols get added, and nothing gets done about the many more holes that exist.
You Slashdotters may make fun of marketing people, but I think Walter just showed you how YOU need to make your pitch for your favorite open source project at your company.
Like spinning netfilter (over 100 000 lines of code) as something great when there is a much better packet filter, like
pf?
How long until the solution to all of the problems is "Reboot the computer"?
Only if you use Microsoft Windows;-) However, a planned rebooting is a good thing to do after you've made configuration changes, just to make sure that the machine will boot after a power outage. Shit happens.
The password being in the log is a TINY problem compared with what Windows has.
The password written in the install log is tantamount to write the root password since that user has unrestricted sudo privileges (i.e. "sudo su"). If this kind of errors are made in Ubuntu, one wonders what other security issues Ubuntu has.
You can currently install Linux on a computer with a direct internet connection without problems. You can't do that with Windows. Patching it fully takes hours after installation and the average time before you get infected with something is about 30 minutes -- do the math. I actually tried that with a friend. Gave up after 3 tries, and ended up bringing it to my home so that I could install it behind my Linux firewall.
It is always prudent to install Windows on a machine behind a firewall, and let it continue to run behind a firewall. For home users, a cheap DSL router will function as a simple firewall and will protect you during installation as well. If a real firewall is needed/wanted, then install OpenBSD on a machine and use
pf
What? What? Don't know what *nix you're running, but Linux and BSD distros all come secure.
You mean like Ubuntu that writes the administrator password in the install log and it took several months before this was discovered?
The hard part is setting up your network hardware, but after that, you're safe. This is exactly the sort of thing you're talking about, so you've basically proved yourself wrong.
It's only hard to setup your "network hardware" if you run Linux. Of course, you are less safe after you configure your NIC, but less so if you run *BSD.
Vista being so long coming also means that BIOS is still in the Vista plan, which means the hardware will CHANGE AGAIN in about a year to eliminate the old BIOS that's been around for decades.
Of course this will not happen anytime soon. Microsoft is in the business of selling software, so a midrange PC bought today will run Vista just fine.
Of course a corporation is should do anything it possible can to increase the value of options and stocks that the management owns! Who cares that some non-white, non-US, barely human ignorant smallish, dare I write "human", is sacrificed for the common good i.e. my stock options? Anything else is violation of free market principles and should be met the harshest possible sanctions, as long as it enriches me and the Republicans. Another tax break would be nice as well; I do make alot of donations after all, and I have a high RIO demand!
Because that would involve personal responsibility, and this day in age it's far too easier to just sue someone claiming they didn't do enough to stop you from hurting yourself.
Now you sound like a spokesman for a company selling shoddy and dangerous products attempting to put the blame on their customers. Safe products are more expensive to design and produce.
Tell him to turn it down already. Its been said before, but using technology to solve the symptoms (very high volume) instead of fixing the problem (not enforcing the idea that loud = dangerous) is a pretty bad, if not useless, idea.
You probably think that safety lock mechanism on guns is pretty bad idea too, eh? Of course one may use technology to make use of an appliance safer.
The Apache license allows for non or commercial distribution of Apache or a direct derivetive (with attribution), but I don't see any other products or projcts based on the Apache codebase (I know there are some) that are nearly as popular as Apache itself. Can you answer why this is?
Which license do you mean? The newest one that made OpenBSD fork httpd? Now why does that remind me of XFree86 and Xorg?
Offtopic, but can someone tell me how "0xfe.blogspot.com" is a valid domain?
According to RFC 1034:
<label>::= <letter> [ [ <ldh-str> ] <let-dig> ]
Please read what is written a few lines above: "The following syntax will result in fewer problems with many
applications that use domain names (e.g., mail, TELNET)."
I have some code to fix if "someone@0xfe.blogspot.com" could be a valid address...
Slashdot Mirror
You are wrong in that belief. OpenVPN uses OpenSSL.
Yeah, but that is no problem for Linux: NDA and binary blobs are always welcome, indeed, the users demands it.
I'm astonished that Debian does this, since it clearly implies much extra work in testing an updated package (No wonder that Debian releases so seldom) That is why I misread your comment concerning compatability from release to release. On OpenBSD you may keep your already installed packages when upgrading, but no port is backported to an older release (unless it's critical for some reason).
It's requirement for a supported arch that not only the kernel, but userland (including thirdparty applications like perl, Apache httpd, BIND, Sendmail, gcc toolchain and more) must also be built natively: cross-compiling is not sufficient to claim support, unlike some other OS that shall be unnamed. Some archs, like vax, is limited by hardware, while others are not fully supported due to lack of documentation/hardware/resources.
In general, if an arch is supported, it is supported well.
Ports are tested on all platforms, but some ports are not supported on some platforms either due to hardware limitations or bugs in the application.
OpenBSD has higher standards than just to be able to compile a kernel natively: Userland must also be built natively and it must be a useable OS.
Now, this is silly. Of course OpenBSD offers pre-compiled ports (ie packages) for every arch where it makes sense. Obviously, on vax, for instance, there will be a limited supply of applications that may run on such a platform. However, there are quite a few packages available (not cross-compiled): ftp://ftp.openbsd.org/pub/OpenBSD/3.8/packages/vax
So not only should the package maintainers test for OS release X, but also for several other releases as well. In addition there will be updated packages that needs testing. Nice idea, if you are willing to pay the (mostly) unpaid package maintainers to do this. Do you?
OpenBSD has a different release policy (i.e. a release every six months) that works very well. The 3.9 release is coming 1th of May, but the release in November will have version 4.0. Of course, someone had to ask if 4.0 will be stable. Theo de Raadt answered thus:
It is just a matter of duplicating all the packets that traverses a router. Properly done you will not notice this.
I have been hearing this for a long time. Basically to sum it up: I don't understand this issue about "desktop readiness". What matters is that the applications you need are available and that drivers exist for your hardware.
If Redhat touched that code, do you think it will continue to be secure? And why would Redhat want to fork OpenSSH in the first place?
Yet another moronic comment! Anybody is free to fork OpenSSH: go read the license!
Ports (thirdparty software not in base system) is not audited that deeply quite simply because it would be too resource demanding. Note that the OpenBSD base system contains a lot of software.
Even better: Use OpenBSD and don't install crappy applications.
We would like to think so, however, the driving principle of many open source projects is more features:
For Christ sake, only those into S&M like the iptables syntax. Use something decent
Like spinning netfilter (over 100 000 lines of code) as something great when there is a much better packet filter, like pf?
Only if you use Microsoft Windows ;-) However, a planned rebooting is a good thing to do after you've made configuration changes, just to make sure that the machine will boot after a power outage. Shit happens.
The password written in the install log is tantamount to write the root password since that user has unrestricted sudo privileges (i.e. "sudo su"). If this kind of errors are made in Ubuntu, one wonders what other security issues Ubuntu has.
It is always prudent to install Windows on a machine behind a firewall, and let it continue to run behind a firewall. For home users, a cheap DSL router will function as a simple firewall and will protect you during installation as well. If a real firewall is needed/wanted, then install OpenBSD on a machine and use pf
You mean like Ubuntu that writes the administrator password in the install log and it took several months before this was discovered?
The hard part is setting up your network hardware, but after that, you're safe. This is exactly the sort of thing you're talking about, so you've basically proved yourself wrong.
It's only hard to setup your "network hardware" if you run Linux. Of course, you are less safe after you configure your NIC, but less so if you run *BSD.
Of course this will not happen anytime soon. Microsoft is in the business of selling software, so a midrange PC bought today will run Vista just fine.
Of course a corporation is should do anything it possible can to increase the value of options and stocks that the management owns! Who cares that some non-white, non-US, barely human ignorant smallish, dare I write "human", is sacrificed for the common good i.e. my stock options? Anything else is violation of free market principles and should be met the harshest possible sanctions, as long as it enriches me and the Republicans. Another tax break would be nice as well; I do make alot of donations after all, and I have a high RIO demand!
Now you sound like a spokesman for a company selling shoddy and dangerous products attempting to put the blame on their customers. Safe products are more expensive to design and produce.
You probably think that safety lock mechanism on guns is pretty bad idea too, eh? Of course one may use technology to make use of an appliance safer.
Which license do you mean? The newest one that made OpenBSD fork httpd? Now why does that remind me of XFree86 and Xorg?
Most open source projects are NOT public domain since they retain the copyright of the authors.
According to RFC 1034:
Please read what is written a few lines above: "The following syntax will result in fewer problems with many applications that use domain names (e.g., mail, TELNET)."
I have some code to fix if "someone@0xfe.blogspot.com" could be a valid address...
Time to fix some code then ;-)