Meanwhile, you claim that it 'is genetic' while ignoring that by that definition, this person SHOULD be an alcoholic, but somehow miracuously isnt?
The point is - just because you have a predisposition to being an addict, etc. - doesn't mean you HAVE to be one, anymore than being deaf, blind, etc. means you need to have other people take care of you or similar analogies.
Also - this issue was underway in ~late december / early january and if you check the dragonfly kernel list from that time, it specifically notes this does *not* affect all opterons/amd64's what-have-you .
After this issue was found, the offending code was coded around to prevent the crash issue, and the bug discussed with AMD, leading to this news article
Yes! I totally agree. Clearly the 2000 some odd monks living on mount athos that do nothing but pray, live simply, and offer hospitality to guests should die! What pigs! We would all be better off without these terrible people!
http://en.wikipedia.org/wiki/Mount_Athos
so - rationale for wars is bs, but suggesting millions of people drop dead on the spot is not? and you're not a hipocrite?
Clearly you are the king of egypt, for you rule over the mighty De Nile
From my take as a user and dev - dragonfly is targeted towards people that care about these features.
I use DragonFly on my key desktops / laptop / etc. Works just fine. Yes, some rough edges in places, but nothing I cant fix or live with - and some very smooth spots that aren't there elsewhere (like the features you mention). Having vkernels / jails / hammer allows for some excellent system managment features which can help sw development / testing / etc, plus the small group allows for a less disorienting community - it kind of 'feels' like using research unix or something in a computer lab.
plus, being interested in systems dev and having the small but not too bad rough edges and a simple and unified build system (latter common to all bsd-derived systems) allows me to easily add mini features which is great for getting involved in os development and deepening my knowledge of the 'guts' of how a system works
plus it's historically unix derived, which deepends knowledge of historical systems and 'why things are the way they are' immensely
the changlog contains many 'why you should care' type of things, and also a link to many 'what is the point' types of pages -
so - sounds to me like you are complaining about your own laziness
r.e. 'distros' - 99% of linux 'distros' are just repackaging of the same software using the same tools with a different default set of packages to stroke some teenyboppers ego - nothing new that you couldn't do with another by running a few yums or apt-gets
this is novel software, that you can 'only get here', and contains some advanced features that you cant get running another system - so thats why you should care.
and if that's not interesting to you - go find another site that doesn't contain 'news for nerds'
And how many of those m68k / mips / arm / etc. sub architectures that you so smoothly dismissed run on Linux?
they are separate 'ports' for a reason in netbsd . Personally, I'd think the important factor in 'counting' these is 'platforms' supported rather than CPU's
also r.e portability: can you cross compile one from another, or even from another os simply from a checkout of the codebase without manually bootstrapping a toolchain?
r.e 'hack' - last I checked the linux code is much less modular w/r/t cpu platforms with more being duplicated in the subplatform code which is why I think this has a reputation for being 'hackish' - though I'm absolutely not knowledgable on linux portability.
anyhow - not trying to start a flamewar - more free OS's on more hardware is better all around no doubt
Quite simply - because someone ported it to FreeBSD first. Doesn't at all 'prove' the portability question -
FreeBSD: 6 architectures - with support for alpha having been *dropped* NetBSD: 8x 'tier 1 architectures' and 49 'tier 2' architectures -> 57 architectures. Its like freaking Heinz Ketchup -
57 varieties - goes on anything!
As for:
" FBSD plus OpenSSH be a good substitute for OBSD should one want both the stability and performance of FBSD as well as the wide peripheral support? "
OpenSSH runs on just about any unix-like os - so this is kind of a moot point. The security features of OpenBSD are much more than ssh with things like stack-smashing protection, randomized address loading, code audits, etc.
OpenBSD also has very good hardware support - between all the bsd-derived system this is really a matter of what particular hardware you want to run - often the first driver for hardware 'x' is added to one of the systems first (wherever whichever dev has that hardware and wants to make it work), and is then ported elsewhere. Quite a few of those drivers have first been added in OpenBSD, as well as NetBSD or FreeBSD, etc. For example, my eeepc901 laptop's wireless driver only works on OpenBSD last I checked but I'm planning on porting this driver to DragonFly so I can use it there.
For: "Also, are the performance lags in OBSD a result of their strict security policies, or something totally independent of that? "
While I'm not an openbsd dev and don't speak for the project -
OpenBSD is focused on "Our efforts emphasize portability, standardization, correctness, proactive security and integrated cryptography. "
So, unlike popular conception, the focus is not just security, but all of the above, equally. A big focus is stability and making sure code changes are rock solid before committing, so things like SMP / threading, etc. have been less of a focus as the team doesn't want to make as radical changes which have the potential to negatively affect the above things - plus alot of the supported architectures weren't SMP architectures to begin with so the effort was not as important.
However, it will still run reasonably quick on most hardware, and there is SMP support nowadays, so for most tasks it will be fine. The extremely high stability and very high quality of releases / ease of binary maintenance would often be a good tradeoff for the performance in many scenarios. And high-end routing / firewalling (pfsync + carp, openospfd, openbgpd, etc) features make it the best choice for quite a few applications.
Both NetBSD's pkgsrc and OpenBSD's ports are also quite extensive with most important things being available.
IpV6 support, while different between the systems, is generally quite good.
Capisicum is a different kind of 'security' than what OpenBSD is focused on - more about fine grained multi user configuration of various roles, logging, etc. for high security corporate / govt type scenarios where you want auditing and a high level of specific process control (think SELinux), whereas OpenBSD's security focus has been more on 'can this program be exploited' / 'how to block a exploitable program from being sucessfully exploited' / 'has this code / protocol been audited for security holes' / 'lets priveledge separate this priveledged process in the system', 'lets replace this historically security lax daemon with another clean rewrite' etc. All related to security - but different aspects.
Personally I use DragonFlyBSD on my desktops primarily, with a linux box or two around to run things over X windows that I haven't gotten around to porting to DragonFly yet / for porting new stuff from, run OpenBSD on my routers, and have a NetBSD box for noodling with and testing netbsd compatibility for patches to pkgsrc (which DragonFly uses primarily but is maintained by the NetBSD team)
Try them all! Use them all! learn / read / etc. It will at expand your knowledge of system design and possibilities.
" For instance, PC-BSD too is a FreeBSD derivative, fine-tuned for use as a desktop, w/ a choice of user interfaces, a new PBI packaging system, USB3 support and so on. So I can see a desktop BSD user prefering PC-BSD to FreeBSD. What sort of BSD users would want to use DragonFly over FreeBSD? Ones that have SMP systems? "
This is not an 'apples to apples' comparison - PC-BSD is basically a FreeBSD 'distribution' - FreeBSD base OS rebuilt with added user-friendly features that you mention - a FreeBSD binary will run on PC-BSD and vice-versa - and as I understand it you can update the base PC-BSD system by pulling FreeBSD source and rebuilding/reinstalling as the PC-BSD stuff is 'added on' - you can still use FreeBSD ports with PC-BSD, etc.
DragonFlyBSD is a FreeBSD fork - so a totally different OS, with common heritage. DragonFlyBSD is no longer directly binary compatible with FreeBSD (without using the binary emulation layer for old FreeBSD 4 binaries), and the kernel architecture has diverged quite a bit w/r/t threading, various device driver api's, networking etc being quite different (but still close enough that code can be ported back and forth without too much trouble). People (myself included) who would prefer DragonFlyBSD share the same philosophy w/r/t the design of the system and related goals. Purpose wise the two are quite similar - general purpose for desktop/server on mainly/exclusively x86/x86-64 platform - but my personal take and alot of the community is that DragonFly has taken the 'right approach' to 'next gen' features such as SMP, etc, and focusing on clean internals for these features has left things more flexible for future work. The 'fruits' of this effort can be seen in similar performance for the initial lock-free SMP in the last release compared to FreeBSD despite a much much smaller amount of developer time - with more performance improvments likely as the changes leading to 3.0 are tuned further.
I got into DragonFlyBSD because at the time (~2006) I was quite interested in OS internals / design, and the SMP work design goals seemed to 'seem right' as compared to the FreeBSD5+ approach - the small DragonFly community made it easy to get involved and seems much more 'cosy', so I stuck with it, esp. because at the time the VKernel work was just taking shape which was very exiting to have a BSD derived OS with native, BSD licensed full system virtualization (if not hardware assisted) - which is still unique among the BSD derivatives.
there's cost e.g. in lost revenue, but really, they just blast them off using the remaining fuel to a higher orbit.. so that is not too expensive to do. Not much else is done with them, they are just moved out of the geo[syncrhonous|stationary] orbit slots to eventually disentigrate on reentry when their orbit gets too out of whack.
if a company is too sloppy about this, I suppose the ITU will not give them any new orbital slots, which would keep them out of business.. so yes, there are incentives.
don't get me wrong, I love my local free hotspots, but I wonder if these whiny coffeeshops are paying for a 'business grade' internet connection licenced for bandwidth sharing...
Slashdot Mirror
Yes, but she speaks polish. have you ever heard polish?
Meanwhile, you claim that it 'is genetic' while ignoring that by that definition, this person SHOULD be an alcoholic, but somehow miracuously isnt?
The point is - just because you have a predisposition to being an addict, etc. - doesn't mean you HAVE to be one, anymore than being deaf, blind, etc. means you need to have other people take care of you or similar analogies.
oh please
WAAH INTERNET BULLIES MADE MEH KILL MESELF
all of the capitals in this post are intentional so mr slashdot filter can please go away thank you.
or 'western rationalist athiest / agnostic'
how does his nickname alter the argument?
More details available here:
http://permalink.gmane.org/gmane.os.dragonfly-bsd.kernel/14523
Also - this issue was underway in ~late december / early january and if you check
the dragonfly kernel list from that time, it specifically notes this does *not* affect all
opterons/amd64's what-have-you .
Latest info from the thread on the DragonFly kernel dev list -
http://permalink.gmane.org/gmane.os.dragonfly-bsd.kernel/14523
has some more specifics - with more details about AMD's plans for followup.
Correction - DragonFlyBSD did have it.
After this issue was found, the offending code was coded around to prevent the crash
issue, and the bug discussed with AMD, leading to this news article
Yes! I totally agree. Clearly the 2000 some odd monks living on mount athos that do nothing but pray, live simply, and offer hospitality to guests should die! What pigs! We would all be better off without these terrible people!
http://en.wikipedia.org/wiki/Mount_Athos
so - rationale for wars is bs, but suggesting millions of people drop dead on the spot is not?
and you're not a hipocrite?
Clearly you are the king of egypt, for you rule over the mighty De Nile
Yes - clearly the openly lesbian mayor of a major city in TEXAS proves your point about the blithing theocratic intolerance of the USA. Well put.
http://en.wikipedia.org/wiki/Annise_Parker
funded by iran and syria? hmm .. you don't say!
In the last 1,10 maybe 50, maybe 100, maybe more years, yes, I'm pretty sure he is.
or maybe your comment is so asinine I just got trolled. hmm.
From my take as a user and dev - dragonfly is targeted towards people that care about these features.
I use DragonFly on my key desktops / laptop / etc. Works just fine. Yes, some rough edges in places, but nothing I cant fix or live with - and some very smooth spots that aren't there elsewhere (like the features you mention). Having vkernels / jails / hammer allows for some excellent system managment features which can help sw development / testing / etc, plus the small group allows for a less disorienting community - it kind of 'feels' like using research unix or something in a computer lab.
plus, being interested in systems dev and having the small but not too bad rough edges and a simple and unified build system (latter common to all bsd-derived systems) allows me to easily add mini features which is great for getting involved in os development and deepening my knowledge of the 'guts' of how a system works
plus it's historically unix derived, which deepends knowledge of historical systems and 'why things are the way they are' immensely
umm -
the changlog contains many 'why you should care' type of things, and also a link to many 'what is the point' types of pages -
so - sounds to me like you are complaining about your own laziness
r.e. 'distros' - 99% of linux 'distros' are just repackaging of the same software using the same tools with a different default set of packages to stroke some teenyboppers ego - nothing new that you couldn't do with another by running a few yums or apt-gets
this is novel software, that you can 'only get here', and contains some advanced features that you cant get running another system - so thats why you should care.
and if that's not interesting to you - go find another site that doesn't contain 'news for nerds'
Looks like you're right on cpu families- however:
And how many of those m68k / mips / arm / etc. sub architectures that you so smoothly dismissed run on Linux?
they are separate 'ports' for a reason in netbsd . Personally, I'd think the important factor in 'counting' these is 'platforms' supported rather than CPU's
also r.e portability:
can you cross compile one from another, or even from another os simply from a checkout of the codebase without manually bootstrapping a toolchain?
r.e 'hack' - last I checked the linux code is much less modular w/r/t cpu platforms with more being duplicated in the subplatform code which is why I think this has a reputation for being 'hackish' - though I'm absolutely not knowledgable on linux portability.
anyhow - not trying to start a flamewar - more free OS's on more hardware is better all around no doubt
Quite simply - because someone ported it to FreeBSD first. Doesn't at all 'prove' the portability question -
FreeBSD: 6 architectures - with support for alpha having been *dropped*
NetBSD: 8x 'tier 1 architectures' and 49 'tier 2' architectures -> 57 architectures. Its like freaking Heinz Ketchup -
57 varieties - goes on anything!
As for:
"
FBSD plus OpenSSH be a good substitute for OBSD should one want both the stability and performance of FBSD as well as the wide peripheral support?
"
OpenSSH runs on just about any unix-like os - so this is kind of a moot point. The security features of OpenBSD are much more than ssh with things like stack-smashing protection, randomized address loading, code audits, etc.
OpenBSD also has very good hardware support - between all the bsd-derived system this is really a matter of what particular hardware you want to run - often the first driver for hardware 'x' is added to one of the systems first (wherever whichever dev has that hardware and wants to make it work), and is then ported elsewhere. Quite a few of those drivers have first been added in OpenBSD, as well as NetBSD or FreeBSD, etc. For example, my eeepc901 laptop's wireless driver only works on OpenBSD last I checked but I'm planning on porting this driver to DragonFly so I can use it there.
For: "Also, are the performance lags in OBSD a result of their strict security policies, or something totally independent of that? "
While I'm not an openbsd dev and don't speak for the project -
OpenBSD is focused on "Our efforts emphasize portability, standardization, correctness, proactive security and integrated cryptography. "
So, unlike popular conception, the focus is not just security, but all of the above, equally. A big focus is stability and making sure code changes are rock solid before committing, so things like SMP / threading, etc. have been less of a focus as the team doesn't want to make as radical changes which have the potential to negatively affect the above things - plus alot of the supported architectures weren't SMP architectures to begin with so the effort was not as important.
However, it will still run reasonably quick on most hardware, and there is SMP support nowadays, so for most tasks it will be fine. The extremely high stability and very high quality of releases / ease of binary maintenance would often be a good tradeoff for the performance in many scenarios. And high-end routing / firewalling (pfsync + carp, openospfd, openbgpd, etc) features make it the best choice for quite a few applications.
Both NetBSD's pkgsrc and OpenBSD's ports are also quite extensive with most important things being available.
IpV6 support, while different between the systems, is generally quite good.
Capisicum is a different kind of 'security' than what OpenBSD is focused on - more about fine grained multi user configuration of various roles, logging, etc. for high security corporate / govt type scenarios where you want auditing and a high level of specific process control (think SELinux), whereas OpenBSD's security focus has been more on 'can this program be exploited' / 'how to block a exploitable program from being sucessfully exploited' / 'has this code / protocol been audited for security holes' / 'lets priveledge separate this priveledged process in the system', 'lets replace this historically security lax daemon with another clean rewrite' etc. All related to security - but different aspects.
Personally I use DragonFlyBSD on my desktops primarily, with a linux box or two around to run things over X windows that I haven't gotten around to porting to DragonFly yet / for porting new stuff from, run OpenBSD on my routers, and have a NetBSD box for noodling with and testing netbsd compatibility for patches to pkgsrc (which DragonFly uses primarily but is maintained by the NetBSD team)
Try them all! Use them all! learn / read / etc. It will at expand your knowledge of system design and possibilities.
Also - forgot to discuss this:
"
For instance, PC-BSD too is a FreeBSD derivative, fine-tuned for use as a desktop, w/ a choice of user interfaces, a new PBI packaging system, USB3 support and so on. So I can see a desktop BSD user prefering PC-BSD to FreeBSD. What sort of BSD users would want to use DragonFly over FreeBSD? Ones that have SMP systems?
"
This is not an 'apples to apples' comparison - PC-BSD is basically a FreeBSD 'distribution' -
FreeBSD base OS rebuilt with added user-friendly features that you mention - a FreeBSD binary will run on PC-BSD and vice-versa - and as I understand it you can update the base PC-BSD system by pulling
FreeBSD source and rebuilding/reinstalling as the PC-BSD stuff is 'added on' - you can still use FreeBSD ports with PC-BSD, etc.
DragonFlyBSD is a FreeBSD fork - so a totally different OS, with common heritage. DragonFlyBSD is no longer directly binary compatible with FreeBSD (without using the binary emulation layer for old FreeBSD 4 binaries), and the kernel architecture has diverged quite a bit w/r/t threading, various device driver api's, networking etc being quite different (but still close enough that code can be ported back and forth without too much trouble). People (myself included) who would prefer DragonFlyBSD share the same philosophy w/r/t the design of the system and related goals. Purpose wise the two are quite similar - general purpose for desktop/server on mainly/exclusively x86/x86-64 platform - but my personal take and alot of the community is that DragonFly has taken the 'right approach' to 'next gen' features such as SMP, etc, and focusing on clean internals for these features has left things more flexible for future work. The 'fruits' of this effort can be seen in similar performance for the initial lock-free SMP in the last release compared to FreeBSD despite a much much smaller amount of developer time - with more performance improvments likely as the changes leading to 3.0 are tuned further.
I got into DragonFlyBSD because at the time (~2006) I was quite interested in OS internals / design, and the SMP work design goals seemed to 'seem right' as compared to the FreeBSD5+ approach - the small DragonFly community made it easy to get involved and seems much more 'cosy', so I stuck with it, esp. because at the time the VKernel work was just taking shape which was very exiting to have a BSD derived OS with native, BSD licensed full system virtualization (if not hardware assisted) - which is still unique among the BSD derivatives.
there's cost e.g. in lost revenue, but really, they just blast them off using the remaining fuel to a higher orbit.. so that is not too expensive to do. Not much else is done with them, they are just moved out of the geo[syncrhonous|stationary] orbit slots to eventually disentigrate on reentry when their orbit gets too out of whack.
if a company is too sloppy about this, I suppose the ITU will not give them any new orbital slots, which would keep them out of business.. so yes, there are incentives.
yup, that'll work just as fast as you can you say
"mac spoof nat ifconfig ate my homework"
My girlfriend bought the CD for me the other week much to my ..
..
happy surprise
saw the note on the back, and was a little worried I'd have to install windows to run it..
so:
First thing I did was pop it in my gentoo box and run
'rip'
cddb + mp3 conversion worked just fine thank you very much.
http://www.gnu.org/directory/audio/rip/rip.html
okay.. I take it back. BOO AMD!!!
However, my bet it that its just some yutes with stickers and not a soviet/amd plot.
don't get me wrong, I love my local free hotspots,
but I wonder if these whiny coffeeshops are paying for a 'business grade' internet connection licenced for bandwidth sharing...