In case you wish to do a Binary upgrade instead of a "by source" upgrade as explained elsewhere in this thread (and in the handbook)... what You basically do is:
- grab the boot-disks (kern.flp and mfsroot.flp)
- boot from those... and select the Upgrade option
Even Linux-kernels come out in different "trees/branches" of development.
You have the old 2.0-kernels You have the newer 2.2-kernels and You have the 2.3-series of kernels
If we leave out the FreeBSD-5.x and the linux 2.4-branch... We can make some sort of parallel like the following:
2.0-kernels/FreeBSD-2.2.x ------------------------- Both are reasonably functional and stable just not really supported any longer. People are advised to switch over to the newer "branches"... For Linux that means 2.2-kernels... for FreeBSD that means the 3.x-branch
2.2-kernels/FreeBSD-3.x ----------------------- Both are currently considdered to be the mainstream branches of both development trees. Expected to be quite stable and are known to catch occasional minor/average changes in their internals...
2.3-kernels/FreeBSD-4.x ----------------------- These two trees are the "Playground" of the developers... Things get broken (accidentilly Or on purpose) way more often when compared to their more stable-branches... But they also get a lot more average/major changes in their internals. These branches are where all the really interesting stuff happens.
Now taking linux-2.4-kernels and the FreeBSD-5.x-branch into account. I assume as soon as linux-2.4 kernels will be released the 2.2-kernel branch will take on the role of the 2.0-kernel-branch.
With that assumption.. the following shift will basically happen:
- FreeBSD-2.2.x will be the linux-2.0-kernels - FreeBSD-3.x will be like linux-2.2-kernels - FreeBSD-4.x will be like linux-2.4-kernels - FreeBSD-5.x will be like linux-2.5-kernels*
* assuming 2.4 will released anytime soon and the 2.5-kernel tree will be started.
I hope this parallel will basically explain how FreeBSD's Release Engineering works... i know the parallel is probably not water-proof... but i think it comes close. Feel free to ask any question.
Fun thing is on FreeBSD you could have those same 19 kernels sitting in your system... being able to boot all 19 of them... and STILL not needing to fiddle with any config-file/binary tool to allow you to boot them like LILO
Releasing a public Beta before the actual Release isn't actually what one would call an "Innovation" FreeBSD has been doing that for quite a while already with the 3.x-RC's and up to 4.0-RC3 before 4.0 went RELEASE.
You stated that SSH1 clients cannot connect to SSH2-servers.... Well i think I can burst this bubble, as the way the FreeBSD-ports system installs SSH happens to work around this problem just fine.
FreeBSD's ports-system has SSH1 as a dependency for SSH2. When installing SSH2 it therfor automatically installs SSH1 as well... renaming the binaries to ssh*.old or something similair.
Now the fun part.
When I create an ssh-connection to any server on default ssh2 is used to make that connection. If however ssh2 detects it's connecting to an ssh1-server... it will (just like you said) revert back to the ssh1-protocol.
When an ssh1-client however connects to my system, which is running the ssh2-server, my ssh2-server detects an ssh1-client is connecting and activates the ssh1-server to handle that specific request, completely transparently.
This means that by simply installing the FreeBSD's ssh-ports. I do not have to manually fiddle with ssh1/ssh2 to connect to servers... and others do not have to manually fiddel with ssh1/ssh2 to see which one they should use to connect to my system. As all is handled internally automagically for you.
I would say if the FreeBSD ports can do this. So should any other OS be able to do the same thing.
Slashdot Mirror
FreeBSD All the Way ....
... NetBSD/pmax has to do there :-))
Except for my DECstation 5000/33
Oh i agree there ... but if you don't have the resources to do the actual compile .. (or the time) ... the binary update is a reasonable alternative
In case you wish to do a Binary upgrade instead of a "by source" upgrade as explained elsewhere in this thread (and in the handbook) ... what You basically do is:
... and select the Upgrade option
- grab the boot-disks (kern.flp and mfsroot.flp)
- boot from those
shopt is a bash BUILTIN command.
... is to add almost entirely at the top this line:
The PROPER solution to this problem
SHELL=/usr/local/bin/bash
(or wherever your bash resides)
that will make make use the shell provided.
Like NetBSD/sparc e.g.
And then find Yourself that they (as usual) have No FreeBSD version of it
I posted this Exact some Anouncement Twice and it got Rejected BOTH times .....
Even Linux-kernels come out in different "trees/branches" of development.
... We can make some sort of parallel like the following:
... For Linux that means 2.2-kernels ... for FreeBSD that means the 3.x-branch
...
... Things get broken (accidentilly Or on purpose) way more often when compared to their more stable-branches ... But they also get a lot more average/major changes in their internals.
.. the following shift will basically happen:
... i know the parallel is probably not water-proof ... but i think it comes close. Feel free to ask any question.
You have the old 2.0-kernels
You have the newer 2.2-kernels
and You have the 2.3-series of kernels
If we leave out the FreeBSD-5.x and the linux 2.4-branch
2.0-kernels/FreeBSD-2.2.x
-------------------------
Both are reasonably functional and stable just not really supported any longer. People are advised to switch over to the newer "branches"
2.2-kernels/FreeBSD-3.x
-----------------------
Both are currently considdered to be the mainstream branches of both development trees. Expected to be quite stable and are known to catch occasional minor/average changes in their internals
2.3-kernels/FreeBSD-4.x
-----------------------
These two trees are the "Playground" of the developers
These branches are where all the really interesting stuff happens.
Now taking linux-2.4-kernels and the FreeBSD-5.x-branch into account. I assume as soon as linux-2.4 kernels will be released the 2.2-kernel branch will take on the role of the 2.0-kernel-branch.
With that assumption
- FreeBSD-2.2.x will be the linux-2.0-kernels
- FreeBSD-3.x will be like linux-2.2-kernels
- FreeBSD-4.x will be like linux-2.4-kernels
- FreeBSD-5.x will be like linux-2.5-kernels*
* assuming 2.4 will released anytime soon and the 2.5-kernel tree will be started.
I hope this parallel will basically explain how FreeBSD's Release Engineering works
I created that statistics page myself ... it's Rather BSD-specific
Version Number Hype
Slackware Goes 7.1
You Upgraded Yet?
Topic Says it all ... just watch your Master "Dock-Icon" around christmas ;-))
Fun thing is on FreeBSD you could have those same 19 kernels sitting in your system ... being able to boot all 19 of them ... and STILL not needing to fiddle with any config-file/binary tool to allow you to boot them like LILO
it's called "kernel" not "kernal" ....
Releasing a public Beta before the actual Release isn't actually what one would call an "Innovation" FreeBSD has been doing that for quite a while already with the 3.x-RC's and up to 4.0-RC3 before 4.0 went RELEASE.
FreeBSD-5.0-CURRENT here :-))
SICK
Ooops .... ... i seemed to have missed some of the earlier discussion ...
Appologies on my behalf
looking back at it I indeed was entirely out of line
Of course (Free)BSD can do SMP ....
... please be at least man enough to put your name on it as well
Why shouldn't it be able to ?
Next time you want to start flame-war topics like these
You stated that SSH1 clients cannot connect to SSH2-servers ....
... renaming the binaries to ssh*.old or something similair.
... it will (just like you said) revert back to the ssh1-protocol.
... and others do not have to manually fiddel with ssh1/ssh2 to see which one they should use to connect to my system.
Well i think I can burst this bubble, as the way the FreeBSD-ports system installs SSH happens to work around this problem just fine.
FreeBSD's ports-system has SSH1 as a dependency for SSH2. When installing SSH2 it therfor automatically installs SSH1 as well
Now the fun part.
When I create an ssh-connection to any server on default ssh2 is used to make that connection.
If however ssh2 detects it's connecting to an ssh1-server
When an ssh1-client however connects to my system, which is running the ssh2-server, my ssh2-server detects an ssh1-client is connecting and activates the ssh1-server to handle that specific request, completely transparently.
This means that by simply installing the FreeBSD's ssh-ports. I do not have to manually fiddle with ssh1/ssh2 to connect to servers
As all is handled internally automagically for you.
I would say if the FreeBSD ports can do this. So should any other OS be able to do the same thing.
Let's drop the announcements of "My Daily New Linux Kernel(s)" to Freshmeat only as well then ok ?
As long as not all features are in that the developpers Want to have in ... there will be no 1.0
should be
. windowmaker.org/pub
ftp://shadowmere.student.utwente.nl/Mirrors/ftp
It's nice of you all to mention my system as an alternartive download location ...
;-)
but next time point to my Full ftp.windowmaker.org mirror instead of my own little personal WindowMaker-section
Feels good to see a BSD-related "success"-story again ... ;-))
.. to Live in the Shadow of the Penguin ...
It's hard for the Daemon
and would this actually be my first chance to have an actual first post !?