I won't comment on what you said about Matt and his work other then that I have seen work from him on AmigoaOS as well as in FreeBSD, and that I respect him as a knowledgable programmer and developer, abeit a bit stubborn.
The followign however deserves a comment I think.
> Now that it's crystal clear that this development model (read: 2 people know the code out of 2 hundred developers) is never going to work. They copied Sun's MP model, except Sun had far more than 2 guys working part time on the kernel. Thank you, Matt Dillon, for warning us about it.
SUN's mp model has been looked at since very early on in the 5.x branch (read the smp mailinglist from 3 years ago and you will fidn a lot about it for example), it is not something that suddenly popped up after Matt lost his commit bit or such.
SUN had to develop the model and the implementation. FreeBSD seems to want to build a better implementation of it. If they manage(d) or not I do not know, but what I do know is this: 1. They can learn from the mistakes SUN made. 2. They don't have to develop the model, just the implementation. 3. SUN didn't exactly get theirimplementation done all at once, and there is quite a bit of documentation on the model, their implementation, the pitfalls they encountered and on possible solutions.
Those 3 things will at least result in needing way less resources then SUN had to acomplish a potentially better implementation in the same or less time.
> Anedoctal evidence: all but one of the ports I tried to use work on 5.3 (the exception was a direct connect client). That include ALL that comprises a full workstation (Linux feature complete, so to speak).
Just as anecdotal..
ever got multimedia/mjpegtools to build on 5.x? (its about the only reason for me to keep compat4x support around on my fbsd 5 workstation)
Heh, was just thinking about this some more and another nice use of a scriptable bootloader in combination with initrd would be to have the bootloader list available initrd images and let the user select one, and then load the kernel with appropriate arguments. Yeah, you could type the appropriate commandline at the lilo prompt as well of course, but having a nice menu there is a lot friendlier in my opinion.
> Doesn't work for your contrived "check for binary, otherwise build source" example either. What are you getting at?
Well, I can build my own repository and check that, and if it isnt in there yet, build it and add it. The next machine in my network can do the same and will find the package and use it.
> I wasn't aware of that. I think you're pulling it out of your butt.
Think what you like, did you ever install Linux on such a machine?
> Yes, the linux versions I've seen use initrds, which is a much cleaner solution than probing from the boot loader.
That is a mattter of opinion. Loading a kernel in order to be able to load the proper kernel and modules does not sound clean to me.
> That's insane, I'll put the "can you enable ACPI" functionality into the kernel where it belongs, thanks.
Which works as long as your systemboard is either perfectly supported for acpi or blacklisted as not properly working. A bootscript is way easier to change then the kernel.
> Not really for debian, because the binaries are kept up to date.
It is funny how you give a good example of why you might want this just a few lines earlier, and then ignore it later.
> Err yes, that is trivial with apt. In fact, since the debian repositories are kept up to date, I can stick a.deb mirror or caching.deb proxy in front of my systems and they can all just pull from that.
Not when using local customization.
Anyway, you are not even able to follow your own arguments, so I will give up trying to argue with you.
> You're clutching at straws. First of all you said apt-get couldn't do all these things, now your down to "oh but I don't have to use multiple commands".
Yes, and I can also do it all manually, retrieving sourcecode, configuring it, building it and installing it. Following your logic, there is no need for apt-get either.
> If there was actually a good usage for checking binaries then reverting to source, I'm sure someone would write an option for apt to do it all in one go.
You cannot imagine the use, so believe it is not usefull.. You live in a very small closed off world it seems really.
> The fact is, it is a hack used because FreeBSD's repositories aren't kept up to date.
Eh, and how uptdoate are Woody and Sarge?
It is very usefull because I can have multiple machines build things and proffit from eachothers compiles. I can have my own repository, and have it automatically filled with new binary packages after building them from source and then install them on the rest of my machines etc.
Again, with a lot more work that can be done as well on Linux, but I rather spend my time using those machines.
What amazes me once again us how you denounce anything that you do not happen to use or know, and then refuse to look at things you do not know, and refuse to even try to consider the use of things that you did not use so far.
You were commenting on my comments being biassed, but I would say that at best that would be a case of pot and kettle.
> Err OK. I'll just put 64 bit kernels on 64 bit machines and 32 on 32, and not use a bloated bootloader.... hey you could also make a web browser for a boot loader... features don't always = good.
Well, you are aware that Linux on SPARC uses an alternative bootloader (SILO) for a few reasons, one of them being able to select the proper architecture dependent kernel? It seems they had a need there. The same thing applies to MIPS based hardware for example.
Also, ever seen a live CD that boots on x86 hardware and can make use of the hardware you have?
Again, that you do not use it isnt a reason to assume it has no use.
Being able to see if you can enable ACPI or not, setting boottime parameters and giving your kernel the appropriate commandline options when building a live cd etc etc.
portupgrade -r -R -P figures this out itself, all automatically, that was the point. Yeah, I can get the same thing done with multiple commands or even manually, and I do not even need apt-get for that.
> Keep digging.
You refuse to read up, yet go on making claims. I think learning a bit about logic would help you a lot.
>> Please read up on the -P argument to portinstall next time you encounter a freebsd machine.
> Well no, because I don't make it my business to make ludicrous and uninformed claims that I can't substantiate.
You still should because you are saying that apt-get -b is doing the same while it is not.
What it is not doing, and which is also what you did not manage to read in my post is first check on availability of the proper BINARY package, and if that doesnt exist yet, build it from source.
Also, apt-get -b doesnt handle dependencies, I need to build those seperately.
You are the one making claims without knowing what you are exactly talking about here. Please read up a bit before nmaking such claims.
> It seems like a cut and shut case to me. If I had the choice I'd wouldn't have untrusted users running in the host kernel.
I like to keep untrusted users off my machine, and out of my host kernel. By lack of being able to do that, I want tools to properly secure things. Mandatory access control is a very good means for that, and so is seperating user environments.
There have been issues where things in an UML environment would affect the host kernel, so while in theory it offers better seperation, it is not perfect either, and as I pointed out, FreeBSD offers MAC on top of the seperation of environments which can deal with such situations. Overall that is a better situation despite the theoretical advantage of UML. Please also go read the UML docs where it is mentioned quite a bit that it is not intended as a security tool.
I would like to see an UML like setup on FreeBSD tho, it has some very interesting possibilities.
> It talks fine with non Linux nfs3 servers. At one stage in Linux 2.5, it wouldn't talk to FreeBSD properly, but that is fixed in 2.6 now.
2.4 doesnt talk properly to FreeBSD nfs3, nor does it talk properly to a Solaris 8 server here, times out all the time and doesnt manage to recover the connection.
The same happens when it tries to talk to a Irix 6.5 based server.. The one thing it does talk well with is a linux server.
> What's wrong with that? I'd prefer to keep crud like that out of the boot loader.
If you have to probe hardware and select kernels in the boot loader then I can't help thinking you're doing something wrong.
The fact that you cannot imagine the need for something is moire telling for your lack of imagimation then anything else.
Selecting wether to boot a x86 kernel with or without 64bit extentions is just one possible situation where this is usefull.
> I don't like what you're saying because it is uninformed biased and in some cases incorrect, and you offer no facts to back it up.
Rather, you lack a lot of experience and seem to think that what you have seen so far is all there is in the world.
The original post asked for some advantages of FreeBSD, I answered those, and all you seem to be intend on doing is proving Linux superiority. Well, talk about bias.
If you want to upgrade things, you need portupgrade. Yeah, you may have to upgrade more if you used packages, but really, it does not matter in the end.
If you dont feel like upgrading with portupgrade, and reinstall, that is fine, jusrt that for portupgrade it really does not matter if you started with ports or packages.
As said, both register in the same place in exactly the same way. In virtually all cases, the result of installing a package or port of the same version of the same program is EXACTLY THE SAME.
whatever went wrong in your case is something else, and really has nothign whatsoever to do with you starting with one or the other.
> Linux 2.6 has a few features (nonlinear mappings are a big one) that can bring UML performance up very nicely.
Quite nice, and desirable. It will also need tools to manage jailed environments tho.
> It is also conceptually safer than a jail because it isn't running inside the host kernel.
In theory true. With standard MAC support in FreeBSD this is rather debatable with regards to real world situations however.
> You would hope so. I don't see how this is something to brag about though, Linux has nfs v4.
It still cannot talk properly to nfs3 servers tho unless they happen to run Linux. It is nice that Linux also supports nfs4, but wouldnt it be a good idea to also properly inplement a standard that is used a lot?
> See other thread.
Some distributions can do this reasonably well, others cant. Linux in general?
> Performance gain. Pffth no I don't think so.
In some cases there is a performance gain. This is the result of a difference between the VMs. The VM of Linux scales dznamically, while the one of FreeBSD does not. This gives the Linux VM an advantage for hardware with hotpluggable memory, but it gives the FreeBSD VM slightly less overhead. In specific cases that can result in FBSD having a performance advantage even when running a Linux binary.
> This intrigues me. Why do I want a scripting engine in my bootloader?
Because it for example allows you to write your own boot menu, allows probing hardware and load a kernel and link it with appropriate modules before actually booting that kernel, allows you to probe hardware and select the proper kernel for it etc etc. All things that are solvable using initrd on Linux as well, but not before having loaded a (minimal) real kernel.
> We're talking about advantages over Linux. Your claims are all obtuse, vague and lacking reasons and facts.
Seems more a case of you not liking what I am saying then anything else.
> Extremely useless? Your crappy old sparc has a floppy disk, doesn't it?
No it does not, and many machines that SUN offered in the last decade dont.
The same applies to SGI hardware for example-
> apt-get -b source
That automatically builds the retrieved source. It doesnt do what I described however.
Please read up on the -P argument to portinstall next time you encounter a freebsd machine.
> For someone saying how much you love documentation, I'm surprised you don't read it.
I am surprised how bad you are at reading posts.
> Umm OK so what's the small suggestion you have for me?
That maybe you assume things without knowing.
> Maybe. The difference is that I don't go spouting off about how Linux is so much better than xxx at those times when I don't know what I'm talking about.
Yes you do, see apt-get -b versus portinstall -P above for example.
Which is extremely useless seeing how: 1. many modern systems come without a floppy drive, and 2. most non x86 systems that are supported by Debian come without a floppy drive. Also, I found the installer, I was asking for clear information on the Debian site about where to find it. We were talking about documentation.
> apt-get is better at dependencies than FreeBSD, so I wouldn't pick on that point too hard.
Well, tell me where it is actually better at that, so far it has failed me way more often then the FBSD ports collection, and when going to google for it as well as listening to people around me, that experience seems to be common.
> But what do you mean "the dependency of a sparc smp kernel on initrd tools"? This seems like just a trivial omission in the sparc kernel package and nothing at all to do with apt-get.
The package mentions the dependency allright. apt-get fails to install it properly.
> Err... how about you come back when you learn to RTFM, eh? Troll.
You like screaming troll whenever you disagree eh? does not make it true what you are saying however.
How can I tell apt-get to see if a new version is available in binary format, and if it isnt yet, build it automatically from source and in both cases create a package that I can distribute to other machines? (I know I can install source packages with apt-get, that is NOT what I am talking about here)
> It seems to me that you are fairly misinformed about the matter though, so you'd be likely to say anything.
Yeah, I guess I am... let me give you a small suggestion tho, I make my living with maintaining servers running both platforms. Not being well informed about the possibilities costs me a lot of money, so I guess that I have reason to be well informed.
It does however seem to me that you are quite badly informed yourself with regards to things outside the Linux world.
> Since "it has a bright future ahead of it", can someone name a few of these killer features?
Let me try, the following is incomplete, but gives an idea I think.
- jails: being able to create multiple virtual environments without having to resort to performance hogs like UML or 3rd party tools. - nfs: nfs v3 actually works, nfs over tcp actually works. - maintainability: being able to maintain multiple machines easily while also being able to build everything from source with the options you require. - nullfs, portalfs, unionfs and the like instead of the -bind "hack" - abbility to support multiple ABIs in a clean way (this is how it is able to run Linux apps with little or no performance hit, and at times even with a performance gain) - Scriptable and flexible bootloader without having to resort to using an initrd like setup if you need some scripting for setting things up properly before running init (you still can if you want, but you do not have to) - better dependency checking and automatic loading for kernel modules - clean and consistent filesystem layout
> Are you familiar with the LSB? Oh, and how easy is it to move from FreeBSD to, say, OpenBSD? Troll.
The LSB is an attempt to address the issue, and a failed one for that matter. The fact that the LSB exists is confirmation of the problem that was pointed out in the grandparent.
I use Linux, OpenBSD, FreeBSD and Darwin all on a regular basis, and moving between the later 3 is a lot easier then moving between 2 linux distros.
Also, why would grandparent be a troll for pointing at the huge diversity between Linux distros? Instead of calling him a troll, maybe you should point out that thatcan in fact be a big advantage. For now you sound as if you are trying to deny it is there at all.
> I notice you didn't try to make a comparison to the major Linux distributions here, like SuSE or Debian. I'm actually rather surprised you didn't try to put FreeBSD side by side with some obscure Linux distribution with 10 developers.
Lets see.. Trying to install Debian.... what do I need to download to get a base install? Please point me at a place on the debian site that explains that clearly and actually results in something that works on supported platforms (notably, sparc). Do I have to download the first CD? or the zillion CD images they have? Oh, and why the hell does their netinstall cd image fail due to not having the cd driver required to load its own installer components? (again on SPARC hardware, standard SCSI cd reader)
SuSE does a decent job with regards to enduser docs tho, that I agree with.
> Yawn. emerge, apt-get, Debian pool, etc.
emerge is an attempt to duplicate the functionality of the BSD ports collection, no more and no less. It is in no way superior, and in fact, it lacks the cleanness of the ports collection with its Makefile based structure.
apt-get? please come back when it actually resolves the dependency of a sparc smp kernel on initrd tools properly during install (fails on Woody, Sarge)
Also, come back when it actually allows me to build things from source or install a package in an easy and automated way, allows me to generate distibutable packages automatically etc etc.
At any rate, emerge comes close, and is a nice tool as long as you keep to a single machine.
Maybe you should be a bit less religious and a bit more factual when you want to counter an argument.
What seems to me is that when you want to maintain a single computer, some linux distributions offer slight advantages over the BSD systems, most notably in hardware support. When you have to maintain a bunch of machines, they are simply no match whatsoever for either FreeBSD, NetBSD or OpenBSD.
Heh, while I agree that apt-get is very convinient... I have seen it fail completely on what was an easy to fix situation.
This was with both Woody and Sarge on a SPARC SMP machine. The debian installed failed to install a kernel due to a missing dependency, and as it turned out, a missing kernel package, but it never mentioned that.
Adding installation sources that contained that package and its dependency did not solve the issue, manually installing and configuring the dependency and then manually installing a kernel did.
Also, I have had apt-get install updates and completely break a configuration as a result.
Now, as said, they are convinient, but suffer from similar issues as the packages/ports with portupgrade on FreeBSD, while not giving the option to automatically build from source when wanted/needed, so calling it superior seems incorrect to me.
> So I went back to just building from ports, and on any machine at over 1Ghz ports tend to build fast enough for me (note: I don't use a GUI). The things that tend to take the longest are updating portdb after syncing the ports tree, and downloading the sources. If you have a build server do that, then the compile time on the other servers really isn't that long in comparison.
That indeed works well for most cases. Exceptions would be things like X, KDE, Gnome, Firefox, and similar stuff.
I wonder tho. I have been using a build server for a long time now, not just to build the ports, but also for building upgrades of the base system.
I point all other machines to it for packages, and that seems to be working rather well. What is somewhat important there tho is that you keep the ports tree in sync. All my other machines run a portupgrade -PP -r -R with the packages source pointed at the build server (/usr/local/etc/pkgtools.conf).
There are a few ports that will not work with this, most notably lame (binary distribution forbidden)
I have no idea what went wrong in your case, but I would be interested to find out. The abbility to run a build server is not too relevant I think in your case due to what you said, but when dealing with the bigger packages I mentioned, it is a real timesaver.
> By keeping to just ports on your system, you only have to resolve the needs of one mechanism. And that pretty much works. Since I took that approach, my upgrades have been headache free.
Now lets get something very clear here.
When you install a package, it gets registered in/var/db/pkg
The exact same thing happens when you install a port.
When you use portupgrade, it will look (using pkg_info!!!!! that should really ring a bell there) in/var/db/pkg to see what packages/ports you have installed and in which version.
IT DOES NOT MATTER FOR THAT IF YOU USED A PORT OR A PACKAGE (sorry for shouting)
What does matter is using portupgrade correctly so it will resolve dependencies in both directions, ie, ALWAYS use -r -R
I just upgraded a 4.10 system that had everything installed using packages, and I used portupgrade and let it built the ports for them.
This resulted in one problem, which was extremely well documented in/usr/ports/UPDATING, the problem was KDE, I had to manually remove some components and install the new versions. This is very exceptional, and again, was well documented.
You can ask portupgrade to use packages for installing as well as ports )see the -P flag) and you can also instruct portupgrade to create packages from compiled ports with the -p flag. The later is an extremely usefull feature when you have multiple machines that need the same packages, compile once, install as often as you need.
Saying that ports and packages dont mix is not true in most cases. It is true in a few cases tho. For example, the firefox package will not include the development tools needed for compiling the mplayer plugin from a port, that will only work if you built firefox as a port. This again is an exception, and I consider it a problem of the firefox package.
That said, if you install both as package, and then use portupgrade to upgrade them (and use -r -R !!) the system will figure out that the plugin depends of firefox and build firefox first.
> If you don't agree, fine, suit yourself. Spend hours futzing with builds. I'd rather be USING the system or be off doing something more enjoyable with my time.
You could also spend a little more time reading the documentation. Most of what you suggest is simply not true. Ports and packages use the exact same system for registering themselves, and so can be mixed and still be upgraded with as much or little trouble as when you only used ports (or packages)
A very important commandline to remember: portupgrade -r -R -p -a
Sorry if I sound annoyed here, but yes, it annoys me when people who claim to have used the system for a long time, still did miss the fact that portupgrade explicitly supports packages and ports for installing and upgrading, and then make wrong claims about it.
Slashdot Mirror
> actually that's not QUITE true.. well yet anyways.
Interestingly enough, it IS what a kernel built from approx 1 week old sourcecode claims to be.
I won't comment on what you said about Matt and his work other then that I have seen work from him on AmigoaOS as well as in FreeBSD, and that I respect him as a knowledgable programmer and developer, abeit a bit stubborn.
The followign however deserves a comment I think.
> Now that it's crystal clear that this development model (read: 2 people know the code out of 2 hundred developers) is never going to work. They copied Sun's MP model, except Sun had far more than 2 guys working part time on the kernel. Thank you, Matt Dillon, for warning us about it.
SUN's mp model has been looked at since very early on in the 5.x branch (read the smp mailinglist from 3 years ago and you will fidn a lot about it for example), it is not something that suddenly popped up after Matt lost his commit bit or such.
SUN had to develop the model and the implementation. FreeBSD seems to want to build a better implementation of it. If they manage(d) or not I do not know, but what I do know is this:
1. They can learn from the mistakes SUN made.
2. They don't have to develop the model, just the implementation.
3. SUN didn't exactly get theirimplementation done all at once, and there is quite a bit of documentation on the model, their implementation, the pitfalls they encountered and on possible solutions.
Those 3 things will at least result in needing way less resources then SUN had to acomplish a potentially better implementation in the same or less time.
> Anedoctal evidence: all but one of the ports I tried to use work on 5.3 (the exception was a direct connect client). That include ALL that comprises a full workstation (Linux feature complete, so to speak).
Just as anecdotal..
ever got multimedia/mjpegtools to build on 5.x?
(its about the only reason for me to keep compat4x support around on my fbsd 5 workstation)
Most of the ports tree does work quite well tho.
> I don't know. Matrox still seem to be in the market, despite the specs for even their high-end cards being out in the open.
Hmm, I happen to have a Matrox P650 DH.... I have yet to notice their openness with regards to this card...
Heh, was just thinking about this some more and another nice use of a scriptable bootloader in combination with initrd would be to have the bootloader list available initrd images and let the user select one, and then load the kernel with appropriate arguments. Yeah, you could type the appropriate commandline at the lilo prompt as well of course, but having a nice menu there is a lot friendlier in my opinion.
> Doesn't work for your contrived "check for binary, otherwise build source" example either. What are you getting at?
Well, I can build my own repository and check that, and if it isnt in there yet, build it and add it. The next machine in my network can do the same and will find the package and use it.
> Err no, you don't load the kernel to load another kernel. Where did you get that idea?
> You load the kernel, and it loads its own modules from the initrd.
You can go either way. if the kernel you loaded initially is ok, then there is no reason to load a 2nd one indeed.
> Err, so how to you propose the bootscript knows whether to turn on ACPI support in the kernel? Think man, think!
It doesnt but it seems you missed the last bit of the text you were quoting here:
Let me qoute it again:
> A bootscript is way easier to change then the kernel.
You can easily change it yourself, the bootscript could give you an easy option to disable it pre-boot etc.
> I wasn't aware of that. I think you're pulling it out of your butt.
Think what you like, did you ever install Linux on such a machine?
> Yes, the linux versions I've seen use initrds, which is a much cleaner solution than probing from the boot loader.
That is a mattter of opinion. Loading a kernel in order to be able to load the proper kernel and modules does not sound clean to me.
> That's insane, I'll put the "can you enable ACPI" functionality into the kernel where it belongs, thanks.
Which works as long as your systemboard is either perfectly supported for acpi or blacklisted as not properly working. A bootscript is way easier to change then the kernel.
> Not really for debian, because the binaries are kept up to date.
.deb mirror or caching .deb proxy in front of my systems and they can all just pull from that.
It is funny how you give a good example of why you might want this just a few lines earlier, and then ignore it later.
> Err yes, that is trivial with apt. In fact, since the debian repositories are kept up to date, I can stick a
Not when using local customization.
Anyway, you are not even able to follow your own arguments, so I will give up trying to argue with you.
> You're clutching at straws. First of all you said apt-get couldn't do all these things, now your down to "oh but I don't have to use multiple commands".
Yes, and I can also do it all manually, retrieving sourcecode, configuring it, building it and installing it. Following your logic, there is no need for apt-get either.
> If there was actually a good usage for checking binaries then reverting to source, I'm sure someone would write an option for apt to do it all in one go.
You cannot imagine the use, so believe it is not usefull.. You live in a very small closed off world it seems really.
> The fact is, it is a hack used because FreeBSD's repositories aren't kept up to date.
Eh, and how uptdoate are Woody and Sarge?
It is very usefull because I can have multiple machines build things and proffit from eachothers compiles. I can have my own repository, and have it automatically filled with new binary packages after building them from source and then install them on the rest of my machines etc.
Again, with a lot more work that can be done as well on Linux, but I rather spend my time using those machines.
What amazes me once again us how you denounce anything that you do not happen to use or know, and then refuse to look at things you do not know, and refuse to even try to consider the use of things that you did not use so far.
You were commenting on my comments being biassed, but I would say that at best that would be a case of pot and kettle.
> Err OK. I'll just put 64 bit kernels on 64 bit machines and 32 on 32, and not use a bloated bootloader.... hey you could also make a web browser for a boot loader... features don't always = good.
Well, you are aware that Linux on SPARC uses an alternative bootloader (SILO) for a few reasons, one of them being able to select the proper architecture dependent kernel? It seems they had a need there. The same thing applies to MIPS based hardware for example.
Also, ever seen a live CD that boots on x86 hardware and can make use of the hardware you have?
Again, that you do not use it isnt a reason to assume it has no use.
Being able to see if you can enable ACPI or not, setting boottime parameters and giving your kernel the appropriate commandline options when building a live cd etc etc.
portupgrade -r -R -P figures this out itself, all automatically, that was the point. Yeah, I can get the same thing done with multiple commands or even manually, and I do not even need apt-get for that.
> Keep digging.
You refuse to read up, yet go on making claims.
I think learning a bit about logic would help you a lot.
>> Please read up on the -P argument to portinstall next time you encounter a freebsd machine.
> Well no, because I don't make it my business to make ludicrous and uninformed claims that I can't substantiate.
You still should because you are saying that apt-get -b is doing the same while it is not.
What it is not doing, and which is also what you did not manage to read in my post is first check on availability of the proper BINARY package, and if that doesnt exist yet, build it from source.
Also, apt-get -b doesnt handle dependencies, I need to build those seperately.
You are the one making claims without knowing what you are exactly talking about here. Please read up a bit before nmaking such claims.
> It seems like a cut and shut case to me. If I had the choice I'd wouldn't have untrusted users running in the host kernel.
I like to keep untrusted users off my machine, and out of my host kernel. By lack of being able to do that, I want tools to properly secure things.
Mandatory access control is a very good means for that, and so is seperating user environments.
There have been issues where things in an UML environment would affect the host kernel, so while in theory it offers better seperation, it is not perfect either, and as I pointed out, FreeBSD offers MAC on top of the seperation of environments which can deal with such situations. Overall that is a better situation despite the theoretical advantage of UML.
Please also go read the UML docs where it is mentioned quite a bit that it is not intended as a security tool.
I would like to see an UML like setup on FreeBSD tho, it has some very interesting possibilities.
> It talks fine with non Linux nfs3 servers. At one stage in Linux 2.5, it wouldn't talk to FreeBSD properly, but that is fixed in 2.6 now.
2.4 doesnt talk properly to FreeBSD nfs3, nor does it talk properly to a Solaris 8 server here, times out all the time and doesnt manage to recover the connection.
The same happens when it tries to talk to a Irix 6.5 based server.. The one thing it does talk well with is a linux server.
> What's wrong with that? I'd prefer to keep crud like that out of the boot loader.
If you have to probe hardware and select kernels in the boot loader then I can't help thinking you're doing something wrong.
The fact that you cannot imagine the need for something is moire telling for your lack of imagimation then anything else.
Selecting wether to boot a x86 kernel with or without 64bit extentions is just one possible situation where this is usefull.
> I don't like what you're saying because it is uninformed biased and in some cases incorrect, and you offer no facts to back it up.
Rather, you lack a lot of experience and seem to think that what you have seen so far is all there is in the world.
The original post asked for some advantages of FreeBSD, I answered those, and all you seem to be intend on doing is proving Linux superiority. Well, talk about bias.
If you want to upgrade things, you need portupgrade.
Yeah, you may have to upgrade more if you used packages, but really, it does not matter in the end.
If you dont feel like upgrading with portupgrade, and reinstall, that is fine, jusrt that for portupgrade it really does not matter if you started with ports or packages.
As said, both register in the same place in exactly the same way. In virtually all cases, the result of installing a package or port of the same version of the same program is EXACTLY THE SAME.
whatever went wrong in your case is something else, and really has nothign whatsoever to do with you starting with one or the other.
> Linux 2.6 has a few features (nonlinear mappings are a big one) that can bring UML performance up very nicely.
Quite nice, and desirable. It will also need tools to manage jailed environments tho.
> It is also conceptually safer than a jail because it isn't running inside the host kernel.
In theory true. With standard MAC support in FreeBSD this is rather debatable with regards to real world situations however.
> You would hope so. I don't see how this is something to brag about though, Linux has nfs v4.
It still cannot talk properly to nfs3 servers tho unless they happen to run Linux.
It is nice that Linux also supports nfs4, but wouldnt it be a good idea to also properly inplement a standard that is used a lot?
> See other thread.
Some distributions can do this reasonably well, others cant. Linux in general?
> Performance gain. Pffth no I don't think so.
In some cases there is a performance gain. This is the result of a difference between the VMs. The VM of Linux scales dznamically, while the one of FreeBSD does not. This gives the Linux VM an advantage for hardware with hotpluggable memory, but it gives the FreeBSD VM slightly less overhead. In specific cases that can result in FBSD having a performance advantage even when running a Linux binary.
> This intrigues me. Why do I want a scripting engine in my bootloader?
Because it for example allows you to write your own boot menu, allows probing hardware and load a kernel and link it with appropriate modules before actually booting that kernel, allows you to probe hardware and select the proper kernel for it etc etc. All things that are solvable using initrd on Linux as well, but not before having loaded a (minimal) real kernel.
> We're talking about advantages over Linux. Your claims are all obtuse, vague and lacking reasons and facts.
Seems more a case of you not liking what I am saying then anything else.
> Extremely useless? Your crappy old sparc has a floppy disk, doesn't it?
No it does not, and many machines that SUN offered in the last decade dont.
The same applies to SGI hardware for example-
> apt-get -b source
That automatically builds the retrieved source. It doesnt do what I described however.
Please read up on the -P argument to portinstall next time you encounter a freebsd machine.
> For someone saying how much you love documentation, I'm surprised you don't read it.
I am surprised how bad you are at reading posts.
> Umm OK so what's the small suggestion you have for me?
That maybe you assume things without knowing.
> Maybe. The difference is that I don't go spouting off about how Linux is so much better than xxx at those times when I don't know what I'm talking about.
Yes you do, see apt-get -b versus portinstall -P above for example.
> Getting Debian -> mirrors -> network installation -> floppy disks.
Which is extremely useless seeing how: 1. many modern systems come without a floppy drive, and 2. most non x86 systems that are supported by Debian come without a floppy drive. Also, I found the installer, I was asking for clear information on the Debian site about where to find it. We were talking about documentation.
> apt-get is better at dependencies than FreeBSD, so I wouldn't pick on that point too hard.
Well, tell me where it is actually better at that, so far it has failed me way more often then the FBSD ports collection, and when going to google for it as well as listening to people around me, that experience seems to be common.
> But what do you mean "the dependency of a sparc smp kernel on initrd tools"? This seems like just a trivial omission in the sparc kernel package and nothing at all to do with apt-get.
The package mentions the dependency allright. apt-get fails to install it properly.
> Err... how about you come back when you learn to RTFM, eh? Troll.
You like screaming troll whenever you disagree eh?
does not make it true what you are saying however.
How can I tell apt-get to see if a new version is available in binary format, and if it isnt yet, build it automatically from source and in both cases create a package that I can distribute to other machines? (I know I can install source packages with apt-get, that is NOT what I am talking about here)
> It seems to me that you are fairly misinformed about the matter though, so you'd be likely to say anything.
Yeah, I guess I am... let me give you a small suggestion tho, I make my living with maintaining servers running both platforms. Not being well informed about the possibilities costs me a lot of money, so I guess that I have reason to be well informed.
It does however seem to me that you are quite badly informed yourself with regards to things outside the Linux world.
> Since "it has a bright future ahead of it", can someone name a few of these killer features?
Let me try, the following is incomplete, but gives an idea I think.
- jails: being able to create multiple virtual environments without having to resort to performance hogs like UML or 3rd party tools.
- nfs: nfs v3 actually works, nfs over tcp actually works.
- maintainability: being able to maintain multiple machines easily while also being able to build everything from source with the options you require.
- nullfs, portalfs, unionfs and the like instead of the -bind "hack"
- abbility to support multiple ABIs in a clean way (this is how it is able to run Linux apps with little or no performance hit, and at times even with a performance gain)
- Scriptable and flexible bootloader without having to resort to using an initrd like setup if you need some scripting for setting things up properly before running init (you still can if you want, but you do not have to)
- better dependency checking and automatic loading for kernel modules
- clean and consistent filesystem layout
> Are you familiar with the LSB? Oh, and how easy is it to move from FreeBSD to, say, OpenBSD? Troll.
The LSB is an attempt to address the issue, and a failed one for that matter. The fact that the LSB exists is confirmation of the problem that was pointed out in the grandparent.
I use Linux, OpenBSD, FreeBSD and Darwin all on a regular basis, and moving between the later 3 is a lot easier then moving between 2 linux distros.
Also, why would grandparent be a troll for pointing at the huge diversity between Linux distros? Instead of calling him a troll, maybe you should point out that thatcan in fact be a big advantage. For now you sound as if you are trying to deny it is there at all.
> I notice you didn't try to make a comparison to the major Linux distributions here, like SuSE or Debian. I'm actually rather surprised you didn't try to put FreeBSD side by side with some obscure Linux distribution with 10 developers.
Lets see.. Trying to install Debian.... what do I need to download to get a base install? Please point me at a place on the debian site that explains that clearly and actually results in something that works on supported platforms (notably, sparc). Do I have to download the first CD? or the zillion CD images they have? Oh, and why the hell does their netinstall cd image fail due to not having the cd driver required to load its own installer components? (again on SPARC hardware, standard SCSI cd reader)
SuSE does a decent job with regards to enduser docs tho, that I agree with.
> Yawn. emerge, apt-get, Debian pool, etc.
emerge is an attempt to duplicate the functionality of the BSD ports collection, no more and no less. It is in no way superior, and in fact, it lacks the cleanness of the ports collection with its Makefile based structure.
apt-get? please come back when it actually resolves the dependency of a sparc smp kernel on initrd tools properly during install (fails on Woody, Sarge)
Also, come back when it actually allows me to build things from source or install a package in an easy and automated way, allows me to generate distibutable packages automatically etc etc.
At any rate, emerge comes close, and is a nice tool as long as you keep to a single machine.
Maybe you should be a bit less religious and a bit more factual when you want to counter an argument.
What seems to me is that when you want to maintain a single computer, some linux distributions offer slight advantages over the BSD systems, most notably in hardware support. When you have to maintain a bunch of machines, they are simply no match whatsoever for either FreeBSD, NetBSD or OpenBSD.
Well... on a 5.3 system here, it does have a /etc/rc.d directory.
What it does not have is the symlink mess indeed.
Heh, while I agree that apt-get is very convinient... I have seen it fail completely on what was an easy to fix situation.
This was with both Woody and Sarge on a SPARC SMP machine. The debian installed failed to install a kernel due to a missing dependency, and as it turned out, a missing kernel package, but it never mentioned that.
Adding installation sources that contained that package and its dependency did not solve the issue, manually installing and configuring the dependency and then manually installing a kernel did.
Also, I have had apt-get install updates and completely break a configuration as a result.
Now, as said, they are convinient, but suffer from similar issues as the packages/ports with portupgrade on FreeBSD, while not giving the option to automatically build from source when wanted/needed, so calling it superior seems incorrect to me.
> So I went back to just building from ports, and on any machine at over 1Ghz ports tend to build fast enough for me (note: I don't use a GUI). The things that tend to take the longest are updating portdb after syncing the ports tree, and downloading the sources. If you have a build server do that, then the compile time on the other servers really isn't that long in comparison.
That indeed works well for most cases. Exceptions would be things like X, KDE, Gnome, Firefox, and similar stuff.
I wonder tho. I have been using a build server for a long time now, not just to build the ports, but also for building upgrades of the base system.
I point all other machines to it for packages, and that seems to be working rather well. What is somewhat important there tho is that you keep the ports tree in sync. All my other machines run a portupgrade -PP -r -R with the packages source pointed at the build server (/usr/local/etc/pkgtools.conf).
There are a few ports that will not work with this, most notably lame (binary distribution forbidden)
I have no idea what went wrong in your case, but I would be interested to find out. The abbility to run a build server is not too relevant I think in your case due to what you said, but when dealing with the bigger packages I mentioned, it is a real timesaver.
> By keeping to just ports on your system, you only have to resolve the needs of one mechanism. And that pretty much works. Since I took that approach, my upgrades have been headache free.
/var/db/pkg
/var/db/pkg to see what packages/ports you have installed and in which version.
/usr/ports/UPDATING, the problem was KDE, I had to manually remove some components and install the new versions. This is very exceptional, and again, was well documented.
Now lets get something very clear here.
When you install a package, it gets registered in
The exact same thing happens when you install a port.
When you use portupgrade, it will look (using pkg_info!!!!! that should really ring a bell there) in
IT DOES NOT MATTER FOR THAT IF YOU USED A PORT OR A PACKAGE (sorry for shouting)
What does matter is using portupgrade correctly so it will resolve dependencies in both directions, ie, ALWAYS use -r -R
I just upgraded a 4.10 system that had everything installed using packages, and I used portupgrade and let it built the ports for them.
This resulted in one problem, which was extremely well documented in
You can ask portupgrade to use packages for installing as well as ports )see the -P flag) and you can also instruct portupgrade to create packages from compiled ports with the -p flag.
The later is an extremely usefull feature when you have multiple machines that need the same packages, compile once, install as often as you need.
Saying that ports and packages dont mix is not true in most cases. It is true in a few cases tho. For example, the firefox package will not include the development tools needed for compiling the mplayer plugin from a port, that will only work if you built firefox as a port. This again is an exception, and I consider it a problem of the firefox package.
That said, if you install both as package, and then use portupgrade to upgrade them (and use -r -R !!) the system will figure out that the plugin depends of firefox and build firefox first.
> If you don't agree, fine, suit yourself. Spend hours futzing with builds. I'd rather be USING the system or be off doing something more enjoyable with my time.
You could also spend a little more time reading the documentation. Most of what you suggest is simply not true. Ports and packages use the exact same system for registering themselves, and so can be mixed and still be upgraded with as much or little trouble as when you only used ports (or packages)
A very important commandline to remember:
portupgrade -r -R -p -a
Sorry if I sound annoyed here, but yes, it annoys me when people who claim to have used the system for a long time, still did miss the fact that portupgrade explicitly supports packages and ports for installing and upgrading, and then make wrong claims about it.
Hmm.. replied to the wrong post there, sorry.