Face it, commercial distributions that hop on the Linux bandwagon are keen on making money.
What does RedHat actually care that stuff they distribute is free ?
Only image: they want to appear as the good guys.
But there is a compromise at work! They have to include MORE bells and whistles than the opposition, while still looking like they endorse free software.
So mistakes like these are going to be made...
Because checking licenses and cataloguing stuff as free/restricted/commercial is not a priority for them.
Likewise, making sure everything is secure and hole-free is not a priority either.
If you want this to change, the only way is to act responsibly, like flaming them to hell each time they `forget' to check... and stop whinying and insisting every stupid new gadget gets included in the distribution.
Huh... wait a second. What am I doing ? asking a bunch of linux lusers to act responsibly ? naaaww. Linux is succesful, so you get the disgruntled Zin95 nincoocoomps. Good luck handling them.
One very important thing to keep in mind is that OpenBSD is a very small operation, especially when compared with some behemoths these days.
So, even though the project is alive and well, it's indeed a good idea to buy the CDs, or T-Shirts (for one thing, the CD artwork is nice, and it comes with mondo-cool stickers).
For one thing, sales are not large enough to warrant a larger format than 2 CDs right now (shipping & handling...), but if sales continue growing, it'll be economically viable to go to 4.
Yep, we do have enough material to fill the space:)
[Apologies for family name spelling, I'm doing this from memory...]
No actual relationship between Pgcc and egcs, except that Mark Lehman is a frequent contributor to the egcs mailing-list...
Most recent pgcc versions have been distributed as a somewhat largish source patch to the corresponding egcs snapshot.
Actually, the difference is not that large... several factors are at hand: - sloppy diffs, so that, e.g., generated files account for a large part of the diff, - improvement to the compiler user interface. Pgcc does have a much larger set of help messages and framework.
Once you remove those two unnecessary parts, you'll find out that pgcc's diffs are not THAT large.
As far as speed goes, the difference is decreasing, as everything that's safe is incorporated into egcs (remember that pgcc has some higher, experimental level of optimizations that may be `broken'), and there are some fairly interesting intel developments in egcs these days (Joern Ronnecke's work for instance).
Oh yes, there's also the point that all the world is not intel, so the compiler has to continue working properly on other targets...
If you read the pgcc documentation, you'll notice that the improvement over gcc is not always `dramatic' (NOT 30% always, not even on average).
If you want to find out for yourself, that's easy: Marc has been working on compiling a benchmark suite that's available from the same cvs repository that egcs is.
Actually there's much more to a C/C++ compiler than a puny linux kernel, but then I'm on slashdot, so what should I expect ?
The extended asm story is very simple: it was somewhat hackish in gcc 2.7/2.8. Poorly documented, and error-prone.
The checks egcs added should have been there all the time. What gcc did was take those badly constrained asm statements, and spurn out some code. Sometimes it worked, sometimes it did NOT, depending upon the vagaries of the optimizer. This is known as *broken* source... you know, like all these parts in the C standard that read `undefined behavior'.
Now, egcs complains about this kind of `undefined behavior'. Once you've read the fine documentation, and know a bit about that specific assembler, it's usually a matter of 30 seconds to fix a broken extended asm construct.
If you're really sooo impatient to get a standard C++ library, I think you can find out about the libstdc++ mailing-list, find out the state of affairs, and maybe even contribute yourself ?
Wow, does this mean redhat has stopped patching kernel and pcmcia sources to add support for their system management utilities ?
Last time I looked, either you used redhat unadultered, or you lost most of their system administration stuff each time you installed a new kernel.
Besides, installing new kernel source usually completely destroys your rpm database... pretty hard problem to solve, I know. But you're acting as though this kind of stuff didn't exist.
Not only is this FUD, but this looks malicious as well.
Either you're hell-bent on destroying OpenBSD's image, or you're completely clueless and terminally brain-dead, take your pick.
Yes, it's true, OpenBSD does not cater to complete idiots, as you've found out.
- ssh ? patent issues: can't be included on the CD if it's to be used BOTH in the US, and elsewhere. *however*, there is a port, and this is probably the most prominent package that gets built for all architectures... Installation is just a matter of getting either the intl or usa flavor, and doing a pkg_add. Shesh !
- sslay ? why don't you try `man ssl' some time ? maybe you'll find out that there *is* a patent issue as well, and that the true, complete sslay libraries with RSA code are *also* available for download... same problem as with ssh, and that *everything*'s ready for use (secure web server, and all that).
I should know, my OpenBSD box uses only ssh, and I'm setting up a secure-webserver next month... tried all the experiments on OpenBSD with no problem at all.
Re:Portability between versions: a question
on
*BSD News
·
· Score: 2
Binaries are usually portable if you have to. One point of the matter is to try to run from source when you can, which is why the ports systems of all three BSD are highly functional.
Just cd to the right directory, type make install, and magic starts: the box finds out what it needs, gets it thru ftp, and builds a brand new binary. Magic, or not ?:)
As far as emulation goes, let's see... - I've been running Linux's quake. - svgalib works as well, even though it's somewhat insecure. - libggi is mostly working. - my netscape is a bsdi binary, and I use Maple for linux every day.
Icky stuff such as OSSaudio calls works pretty well under OpenBSD (xanim runs, complete with sound)... it just becomes a question of how far you're willing to push linux support. One reason to run OpenBSD in the first place is so that you don't have to finnagle with all those libc5/libc6/glibc2.1/egcs fun that Linux seems to have these days.:)
Oh, and I also know that Mathematica runs, or that WordPerfect has a complete functional port... but I don't use these.
Re:I want to try BSD .. but which one?
on
*BSD News
·
· Score: 1
We're getting there as far as the new VM system goes... as far as I know, NetBSD still has some trouble with it in some areas, which is kind of why we're waiting on it...
On the other hand, it's true that we could use more people to play on some lesser-used platforms... one cool point of OpenBSD is that it's fairly open: once you prove you know how to do honest work, it's real easy to become a developper, and the source is completely open & visible for everyone to comment on.
Happy to use that failure :)
on
*BSD News
·
· Score: 2
There's a large difference between the Linux and the BSD model of development.
In Linux-land there is about one kernel (with slight tweaks) and loads of distributions with lots of minute to large changes everywhere).
In BSD-land, you've got three distributions, which noticeable changes everywhere: kernel, user-land, ports.
If you look at BSD logs, you'll often see the same names, or stuff taken from one BSD to the next. I think there might even be a higher level of cooperation between BSD distros than Linux. I know for sure that we don't hesitate to pick useful stuff from Net/FreeBSD when it comes along... in some cases, we wait until stuff is stable enough to include.
Sure, you might miss some of the `bleeding edge' that's soooo keewl when running linux with a beta kernel, a beta glib, and beta stuff everywhere.
Not to say that this is impossible in BSD land, my laptop running full-tilt egcs-990502 and soon binutils-990427 is about as bleeding edge as it goes:) It's just a bit less accessible for newbies, which just means you can't feel like a hacker without *becoming* one.
Re:BSD subsidized by charity
on
*BSD News
·
· Score: 1
Complete FUD.
Almost every `free' distribution get sponsored by various people at different points. The FSF gets grants, David Millert is payed by RedHat, and so on.
Getting a grant from Usenix and using it to press/give away more CDs makes perfect commercial sense.
This does *not* mean BSDs are dead. I can assure you that OpenBSD is quite well, financially speaking.
Oh yes, and for buying OpenBSD in Europe, you have a choice of Germany, Norway, Sweden, Finland, Britain, and even France now !:)
Re:Where to buy the CD-ROM?
on
*BSD News
·
· Score: 1
Go to the web sites and look around a little bit...
For instance, OpenBSD's site is pretty small and to the point: you can order CD-Roms from a variety of places, including Amazon. You can also get rather nice T-Shirts.
egcs is a fairly good C/C++ compiler, especially considering the range of architecture it works on.
Specialized products can beat it. For instance, KAI C++ is known to be much better for heavy numerical templates (check Blitz++).
egcs is getting better at handling x86. It's definitely not perfect, especially since egcs aims at architectures with a wide range of general registers, and this is definitely not the case with x86...
Considering its architecture, finding when to spill registers out to the stack or how to keep stuff in registers is sometimes a bit hard. Current snapshots are much better at that game than the egcs-1.1 series.
Re:Imminent meaningless of "port" predicted
on
Gcc for the IA-64.
·
· Score: 1
Hello ?
There's now lots of stuff in gcc/egcs (threads, frame-unwinding) that NEEDS to be ported for other architectures (not mentionning binutils issues)
This has *no* relationship to simply writing a new backend to gcc. Yep, both are needed to make egcs work on a new machine.
`Porting' is a nice blanket term that covers this nicely.
Cygnus is possibly the company that has contributed the MOST to the GNU projects.
They are a service society, they make money by pandering to their customer wishes.
Very often, you get a specific client that asks for improvements in the compiler, and pays for it. So they get back their compiler, and for a while it's unavailable to the public at large.
Then the code gets contributed to gcc, and everyone in the free software arena is free to use it.
There is a small delay in between, that is perfectly reasonable (on the order of three to six months). The FSF doesn't work different, you have releases, and then there are in-between states for various projects to which you don't necessarily have access.
One other area where Cygnus makes money is service and tools. Their development environment can be sold, and their expert advice as well.
But code *is* thrown away and rewritten in the BSD world.
The i386 serial driver has been completely rewritten, the ffs code has little in common with the older ufs, there is all the vfs code, and a major effort is going on to completely re-vamp the memory handling system (as known as uvm).
Apart from that, if you think IPv6 or SMP don't count as `major' changes, well, I don't know what will...
Well, Linux drivers are highly specialized, to an absurd point sometimes.
Don't forget that the standard drivers are made by OSS, a company who makes a living selling drivers.
Considering their business, having shitloads of drivers to every card in existence makes lots of sense, but you sometimes get absurd results: this is getting so specialized that my laptop's soundcard isn't recognized by *anything* in Free OSS, except as an older SBPro !
Of course, the commercial version of OSS has truckloads more drivers, and recognizes it.
On the other side, OpenBSD generic Windows Sound System driver is not that sophisticated: it doesn't try to check every functionality of that card, it simply picks it up as yet another cs4231 clone.
Yep, you've got it, I've got a sound card with *BETTER* support under OpenBSD than I ever managed to get under Linux... which is why I'm playing quake under OpenBSD + GGI, not Linux.
Linux distributions usually have all the shiny knobs, but more often than not, this means more rope to hang yourself.
BSD distributions usually try to keep configuration to the bare possible minimum, and automate everything.
As a recent personal example, I can remember having trouble with redhat's CD which insisted on me having a swap partition, even though that machine didn't NEED any swap (128 Mb).
One other point where BSD is easier is man pages. At least, you have documentation for all commands and system calls. This is more compact than howto, but this means LESS to read.
Depends on which class of newbie you belong to. Newbies who are not afraid of manual pages may have a simpler time with BSDs... and they can still read the BSD 4.4 manuals, printed version.
Do you guys even know how Linux emulation works on BSD machines ???
It's just a question of having a kernel with COMPAT_LINUX compiled in. Then processes are tagged from start, and use another set of stubs for system calls.
The `slowdown' is *dwarfed* by the context switches, which is the reason system calls under Unix are a bit slow (and hence, that there are not that many of it). The only inefficiency is *memory* since you need to have another set of dynamic libraries loaded.
I've been checking Linux emulation with such programs as xanim. There is *no measurable slowdown* from the native version.
The only programs that perform slower under BSDs are those that can use svgalib under Linux, but this is bound to change with GGI...
Slashdot Mirror
Yeah sure... start projects to recreate all partially free software.
Talk is cheap. *Acting* on it is ways better.
Like, use rsync, which is free, and start contributing to it so that it handles rdist-like features better.
Face it, commercial distributions that hop on the Linux bandwagon are keen on making money.
What does RedHat actually care that stuff they distribute is free ?
Only image: they want to appear as the good guys.
But there is a compromise at work! They have to include MORE bells and whistles than the opposition, while still looking like they endorse free software.
So mistakes like these are going to be made...
Because checking licenses and cataloguing stuff as free/restricted/commercial is not a priority for them.
Likewise, making sure everything is secure and hole-free is not a priority either.
If you want this to change, the only way is to act responsibly, like flaming them to hell each time they `forget' to check... and stop whinying and insisting every stupid new gadget gets included in the distribution.
Huh... wait a second. What am I doing ? asking a bunch of linux lusers to act responsibly ? naaaww. Linux is succesful, so you get the disgruntled Zin95 nincoocoomps. Good luck handling them.
So what's your point ?
Do I need further emphasize that it's `my point of view', and that you needn't bother justify anything there ?
One very important thing to keep in mind is that OpenBSD is a very small operation, especially when compared with some behemoths these days.
:)
So, even though the project is alive and well, it's indeed a good idea to buy the CDs, or T-Shirts (for one thing, the CD artwork is nice, and it comes with mondo-cool stickers).
For one thing, sales are not large enough to warrant a larger format than 2 CDs right now (shipping & handling...), but if sales continue growing, it'll be economically viable to go to 4.
Yep, we do have enough material to fill the space
maybe because no-one tolds them ?
/. rather tends to be Linux-centric as well, so I'm happy to see BSD announces.
from my point of view,
Ok, so redhat-specific sound configuration
/usr/include, or are you saying you don't overwrite files there ?
utilities don't exist...
and the redhat kernel source is the actual official release...
and the pcmcia drop-in without any trouble.
and you install your kernels WITHOUT upgrading
[Apologies for family name spelling, I'm doing this from memory...]
No actual relationship between Pgcc and egcs, except that Mark Lehman is a frequent contributor to the egcs mailing-list...
Most recent pgcc versions have been distributed as a somewhat largish source patch to the corresponding egcs snapshot.
Actually, the difference is not that large... several factors are at hand:
- sloppy diffs, so that, e.g., generated files account for a large part of the diff,
- improvement to the compiler user interface. Pgcc does have a much larger set of help messages and framework.
Once you remove those two unnecessary parts, you'll find out that pgcc's diffs are not THAT large.
As far as speed goes, the difference is decreasing, as everything that's safe is incorporated into egcs (remember that pgcc has some higher, experimental level of optimizations that may be `broken'), and there are some fairly interesting intel developments in egcs these days (Joern Ronnecke's work for instance).
Oh yes, there's also the point that all the world is not intel, so the compiler has to continue working properly on other targets...
If you read the pgcc documentation, you'll notice that the improvement over gcc is not always `dramatic' (NOT 30% always, not even on average).
If you want to find out for yourself, that's easy: Marc has been working on compiling a benchmark suite that's available from the same cvs repository that egcs is.
Actually there's much more to a C/C++ compiler than a puny linux kernel, but then I'm on slashdot, so what should I expect ?
The extended asm story is very simple: it was somewhat hackish in gcc 2.7/2.8. Poorly documented, and error-prone.
The checks egcs added should have been there all the time. What gcc did was take those badly constrained asm statements, and spurn out some code. Sometimes it worked, sometimes it did NOT, depending upon the vagaries of the optimizer. This is known as *broken* source... you know, like all these parts in the C standard that read `undefined behavior'.
Now, egcs complains about this kind of `undefined behavior'. Once you've read the fine documentation, and know a bit about that specific assembler, it's usually a matter of 30 seconds to fix a broken extended asm construct.
Why don't you go read the egcs web pages ?
If you're really sooo impatient to get a standard C++ library, I think you can find out about the libstdc++ mailing-list, find out the state of affairs, and maybe even contribute yourself ?
Wow, does this mean redhat has stopped patching kernel and pcmcia sources to add support for their system management utilities ?
Last time I looked, either you used redhat unadultered, or you lost most of their system administration stuff each time you installed a new kernel.
Besides, installing new kernel source usually completely destroys your rpm database... pretty hard problem to solve, I know. But you're acting as though this kind of stuff didn't exist.
Not only is this FUD, but this looks malicious as well.
Either you're hell-bent on destroying OpenBSD's image, or you're completely clueless and terminally brain-dead, take your pick.
Yes, it's true, OpenBSD does not cater to complete idiots, as you've found out.
- ssh ?
patent issues: can't be included on the CD if it's to be used BOTH in the US, and elsewhere. *however*, there is a port, and this is probably the most prominent package that gets built for all architectures... Installation is just a matter of getting either the intl or usa flavor, and doing a pkg_add. Shesh !
- sslay ?
why don't you try `man ssl' some time ? maybe you'll find out that there *is* a patent issue as well, and that the true, complete sslay libraries with RSA code are *also* available for download... same problem as with ssh, and that *everything*'s ready for use (secure web server, and all that).
I should know, my OpenBSD box uses only ssh, and I'm setting up a secure-webserver next month... tried all the experiments on OpenBSD with no problem at all.
Binaries are usually portable if you have to.
:)
:)
One point of the matter is to try to run from source when you can, which is why the ports systems of all three BSD are highly functional.
Just cd to the right directory, type make install, and magic starts: the box finds out what it needs, gets it thru ftp, and builds a brand new binary. Magic, or not ?
As far as emulation goes, let's see...
- I've been running Linux's quake.
- svgalib works as well, even though it's somewhat insecure.
- libggi is mostly working.
- my netscape is a bsdi binary, and I use Maple for linux every day.
Icky stuff such as OSSaudio calls works pretty well under OpenBSD (xanim runs, complete with sound)... it just becomes a question of how far you're willing to push linux support. One reason to run OpenBSD in the first place is so that you don't have to finnagle with all those libc5/libc6/glibc2.1/egcs fun that Linux seems to have these days.
Oh, and I also know that Mathematica runs, or that WordPerfect has a complete functional port... but I don't use these.
We're getting there as far as the new VM system goes... as far as I know, NetBSD still has some trouble with it in some areas, which is kind of why we're waiting on it...
On the other hand, it's true that we could use more people to play on some lesser-used platforms... one cool point of OpenBSD is that it's fairly open: once you prove you know how to do honest work, it's real easy to become a developper, and the source is completely open & visible for everyone to comment on.
There's a large difference between the Linux and the BSD model of development.
:) It's just a bit less accessible for newbies, which just means you can't feel like a hacker without *becoming* one.
In Linux-land there is about one kernel (with slight tweaks) and loads of distributions with lots of minute to large changes everywhere).
In BSD-land, you've got three distributions, which noticeable changes everywhere: kernel, user-land, ports.
If you look at BSD logs, you'll often see the same names, or stuff taken from one BSD to the next. I think there might even be a higher level of cooperation between BSD distros than Linux. I know for sure that we don't hesitate to pick useful stuff from Net/FreeBSD when it comes along... in some cases, we wait until stuff is stable enough to include.
Sure, you might miss some of the `bleeding edge' that's soooo keewl when running linux with a beta kernel, a beta glib, and beta stuff everywhere.
Not to say that this is impossible in BSD land, my laptop running full-tilt egcs-990502 and soon binutils-990427 is about as bleeding edge as it goes
Complete FUD.
Almost every `free' distribution get sponsored by various people at different points. The FSF gets grants, David Millert is payed by RedHat, and so on.
Getting a grant from Usenix and using it to press/give away more CDs makes perfect commercial sense.
This does *not* mean BSDs are dead. I can assure you that OpenBSD is quite well, financially speaking.
This is one prominent new feature of OpenBSD 2.5, along with IPv6 and loads of minor tweaks everywhere.
Oh yes, and for buying OpenBSD in Europe, you have a choice of Germany, Norway, Sweden, Finland, Britain, and even France now ! :)
Go to the web sites and look around a little bit...
For instance, OpenBSD's site is pretty small and to the point: you can order CD-Roms from a variety of places, including Amazon. You can also get rather nice T-Shirts.
egcs is a fairly good C/C++ compiler, especially considering the range of architecture it works on.
Specialized products can beat it. For instance, KAI C++ is known to be much better for heavy numerical templates (check Blitz++).
egcs is getting better at handling x86. It's definitely not perfect, especially since egcs aims at architectures with a wide range of general registers, and this is definitely not the case with x86...
Considering its architecture, finding when to spill registers out to the stack or how to keep stuff in registers is sometimes a bit hard. Current snapshots are much better at that game than the egcs-1.1 series.
Hello ?
There's now lots of stuff in gcc/egcs (threads, frame-unwinding) that NEEDS to be ported for other architectures (not mentionning binutils issues)
This has *no* relationship to simply writing a new backend to gcc. Yep, both are needed to make egcs work on a new machine.
`Porting' is a nice blanket term that covers this nicely.
Cygnus is possibly the company that has contributed the MOST to the GNU projects.
They are a service society, they make money by pandering to their customer wishes.
Very often, you get a specific client that asks for improvements in the compiler, and pays for it. So they get back their compiler, and for a while it's unavailable to the public at large.
Then the code gets contributed to gcc, and everyone in the free software arena is free to use it.
There is a small delay in between, that is perfectly reasonable (on the order of three to six months). The FSF doesn't work different, you have releases, and then there are in-between states for various projects to which you don't necessarily have access.
One other area where Cygnus makes money is service and tools. Their development environment can be sold, and their expert advice as well.
But code *is* thrown away and rewritten in the BSD world.
The i386 serial driver has been completely rewritten, the ffs code has little in common with the older ufs, there is all the vfs code, and a major effort is going on to completely re-vamp the memory handling system (as known as uvm).
Apart from that, if you think IPv6 or SMP don't count as `major' changes, well, I don't know what will...
Well, Linux drivers are highly specialized, to an absurd point sometimes.
Don't forget that the standard drivers are made by OSS, a company who makes a living selling drivers.
Considering their business, having shitloads of drivers to every card in existence makes lots of sense, but you sometimes get absurd results: this is getting so specialized that my laptop's soundcard isn't recognized by *anything* in Free OSS, except as an older SBPro !
Of course, the commercial version of OSS has truckloads more drivers, and recognizes it.
On the other side, OpenBSD generic Windows Sound System driver is not that sophisticated: it doesn't try to check every functionality of that card, it simply picks it up as yet another cs4231 clone.
Yep, you've got it, I've got a sound card with *BETTER* support under OpenBSD than I ever managed to get under Linux... which is why I'm playing quake under OpenBSD + GGI, not Linux.
This is plain FUD.
Linux distributions usually have all the shiny knobs, but more often than not, this means more rope to hang yourself.
BSD distributions usually try to keep configuration to the bare possible minimum, and automate everything.
As a recent personal example, I can remember having trouble with redhat's CD which insisted on me having a swap partition, even though that machine didn't NEED any swap (128 Mb).
One other point where BSD is easier is man pages. At least, you have documentation for all commands and system calls. This is more compact than howto, but this means LESS to read.
Depends on which class of newbie you belong to. Newbies who are not afraid of manual pages may have a simpler time with BSDs... and they can still read the BSD 4.4 manuals, printed version.
Slowdown ?
Where ?
Do you guys even know how Linux emulation works on BSD machines ???
It's just a question of having a kernel with COMPAT_LINUX compiled in. Then processes are tagged from start, and use another set of stubs for system calls.
The `slowdown' is *dwarfed* by the context switches, which is the reason system calls under Unix are a bit slow (and hence, that there are not that many of it). The only inefficiency is *memory* since you need to have another set of dynamic libraries loaded.
I've been checking Linux emulation with such programs as xanim. There is *no measurable slowdown* from the native version.
The only programs that perform slower under BSDs are those that can use svgalib under Linux, but this is bound to change with GGI...