I'm saying that the kernel of FreeBSD might be superior to Linux.
Did you ever stop to think that perhaps the FreeBSD userland might be superior to GNU's? I'm not talking about comparing individual pieces, but the wholes. Some pieces of GNU are better than BSD, and vice versa.But the *overall* FreeBSD userland might be better than the *overall* GNU userland.
I currently use two monitors, both filled to the brim with icons and several drawers on each desktop.
I think you are the problem. You need to organize yourself better. If two monitors are full of icons, then I have to wonder why you consider all of them so worthwhile you can't remove some of them.
I've walked by coworkers's desks and seen Windows desktops with icons lined up all the way to the right of the screen. This isn't a rarity. I can't understand how people work this way.
Organization and priority is the key. You've got four basic spots to put stuff. Menu, panel, desktop and folders. Put your applications in the menu, with links to your five most frequently used programs on the panel. The menu should be organized by category and frequency of use. Don't accept the default locations, use the menu editor! The desktop should not contain any applications at all. It should contains icons for drives, devices and projects. The latter is the key. Organize your computing into projects, and put all your data into hierarchical folders. There's also the fifth possibility of "the command line". There's no reason for non-GUI programs to be in your menu system. For instance, I use "tidy" all the time, but have never once considered making an icon for it. If you use KDE, the Alt-F2 key is your friend.
Finally, dump anything you don't use. Do you really need icons for five different music players, six different text editors, and a handful of CD burners and rippers? Do you have a document you're finished creating? Take it off the desktop and file it away!
This man page is not kept up to date except when volunteers
want to maintain it. If you find a discrepancy between the man page and the software, please check the Info file, which is the authoritative documentation.
If we find that the things in this man page that are out of date cause significant confusion or complaints, we will stop distributing the man page. The alternative, updating the man page when we update the Info file, is impossible because the rest of the work of maintaining GNU CC leaves us no time for that. The GNU project regards man pages as obsolete and should not let them take time away from other things.
Well, if you get the contributors to sign over their copyrights from the very beginning, you would never have to worry about this. If the code was owned by the Apache Foundation, then the Apache Foundation has full right to change the license.
It's the same reason why the FSF requires copyright assignment, and why the Linux kernel will NEVER EVER have a license other than GPLv2.
You're missing the point in your focus on reality. Of course they're couldn't be a 2GHz 6502! Play the game of "what if?"
If everything else were the same, an 8-bit CPU would blow the pants off of a 32-bit CPU, for benchmarks that don't need more than 8 bits. Pipeline the 6502, give it more registers, whatever. But keep it 8-bit.
The moral of the story is, almost every architectural difference between the 6502 and modern CPUs exists for one reason: speed.
Of course, but you can create analogous architectural improvements to the 6502. The reduced instruction set of 8-bit opcodes allows a level of parallelism that a 32-bit chip couldn't achieve on the same die space. You could put the entire address space in internal cache.
A 64-bit processor isn't going to be inherently faster than a 32-bit processor, except for code that needs 64 bits.
You're right. A 2GHz 6502 would be a screamer. But the drawbacks are numerous. When the world finally went to 32bit, I jumped for joy. Not because I thought stuff would be faster, but because I could finally use a flat memory space large enough for anything I could conceivably want. Integers were now large enough for any conceivable use. Etc, etc.
Of course, my conceptions back then might be getting a bit dated now. But not too terribly much. 32 bits will probably be the optimum for general use for quite some time. There's not too many applications that need a 64 bit address space. Not too many applications need 64 bit integers. We'll need 64 bit sometime, but I don't see the need for it in *general* purpose computing for the remainder of the decade. (Longhorn might actually need to a 64 bit address space, but that's another story...).
Remembering back to the 80286 days, people were always running up against the 16 bit barrier. It was a pain in the butt. But unless you're running an enterprise database, or performing complex cryptoanalysis, you're probably not running up against the 32 bit barrier.
But of course, given that you're viewed as a dusty relic if you're not using a box with 512Mb video memory and 5.1 audio to calculate your spreadsheets, the market might push us into 64 bit whether we need it or not.
It's not following the definitive standard that every application should follow. It's no different than if I wrote a Windows program that didn't follow ctrl-c and ctrl-v.
This is simple to fix, and the way this can be fixed is something you should keep in mind in general because it is helpfull in many similar situations.
If it's a true standard applicable to systems other than Linux, the BSD communities will follow it. We didn't follow the LSB because it was a standard specific. We won't follow a new LSB-with-teeth for the same reason.
Yep, it mostly sucks that a FBSD 5.x kernel install doesn't preserve modules that were added by the user. Not really an nvidia problem, more one of the kernel install.
Though I understand what you're saying, I'll have to disagree a bit. This isn't an instance of the driver failing to load, but an instance of it causing a page fault. I am not a kernel programmer by any means, but describing the problem and symptoms to a friend that is, he greatly suspects that it was caused by a fault in the modules's design and implementation.
But I will agree with you that updates should account for third party modules.
This is simple to fix, and the way this can be fixed is something you should keep in mind in general because it is helpfull in many similar situations.
I do know that one. And I did use it. But being stuck in single user mode didn't help much, because I still didn't know what was causing the problem. It would have been a two minute fix if I had known.
I blew my whole system to pot when I did not uninstall the NVIDIA drivers.
Oh man, I feel your pain! I got burned by that driver too.
The FreeBSD NVidia driver has a fragile interface. You change your kernel or XFree86, you have to rebuild it. I forget that I was automatically loading the NVidia driver in my loader.conf. So the first boot after the 5.2 build crashed hard. Nothing I tried got around it.
So I did an "upgrade" install back to 5.1, and restored my/etc backup. I was very sleepy at this point, which is the only excuse for what happened next. I still have no idea what I was thinking when I did it. I rebuilt the NVidia driver. But the kernel source tree was still 5.2. Crash!
Why would I give up the rock solid stability of 4.9 for an unknown?
Three reasons I can think of:
1) 5.2 supports a lot more hardware than 4.9. Granted, some of the support has been backported, but a lot has not. 4.9 won't run on my current desktop or laptop. 5.2 will.
2) New features. Unlike above, very little has been backported. UFS2, devfs, rcNG, etc.
3) "-CURRENT" doesn't necessarily mean "will crash all the time". 5.0 was a bit flaky around the edges, but 5.1 and 5.2 are very robust.
I wouldn't run 5.2 on mission critical servers, but not everything is in that category. For you Linux people out there, it's sort of like Debian. You run Debian-stable on your servers, and Debian-testing on your desktop.
Silver bricks? You was lucky! In my day we had mine our own ore and smelt it down. Then our dad would assay it, and if it wasn't 99% pure, all we got for breakfast was CompUSA Silver Thermal Grease!
XFree86 under FreeBSD absolutely identical to XFree86 under Linux. Well, not quite. It does support the FreeBSD sysmouse device (think gpm).
On the other hand, you DO NOT get a distro-supplied front end tool like YaST. If you're used to configuring XFree86 the XFree86 way, you're home free. Otherwise...
My advice is to get a basic configuration using "XFree86 -configure", and see if that works. It will do all the detecting and decide stuff for you. Unfortunately, it tends to give you as high of a resolution as possible, which typically is not what you want. But it will tell you what your hardware is. After that you can use "xf86config" and answer the questions manually.
If you're using an NVidia card, and want the proprietary NVidia driver, you'll have to install it manually from the ports system. There's instructions there on how to do it, but it's not necessarily the easiest thing in the world, since you're dealing with kernel. But you can put that off for a while, since the "nv" driver that comes with XFree86 works great if you don't need hardware accelerated 3D.
FreeBSD also won't automatically add fonts to your XFree86 configuration. It's an unwritten law that no third party package or port can alter any system wide configuration file (a good thing if you think about it). But if you read the messages after installing them from packages/ports, they'll tell you what to do.
Hah! Once you get past having to administer stuff yourself, you'll find it makes an excellent desktop. In fact, it has the exact same GUI as Linux. But that administration part can be a hurdle.
Well, if you don't run away screaming at the presence of an ncurses/dialog based installer, and follow through to the configuration section of the install, you're going to end up with an extremely usable system afterwards.
But it's still not really done yet. That's because FreeBSD does not presume to know what you want. It's not going to install a desktop until you tell it to, for example. In fact, it's not going to install anything outside of the base system unless you specifically tell it to. You are in full control. For some users this will be a breath of fresh air. But for others it will be a horrifying discovery that they're not as l33t as they thought they were.
It all comes down to "BSD versus Linux". The licensing is just a red herring. Linux users have been taught that Linux is the only worthwhile Free Software operating system. They think it's the pinnacle of creation. So when they're forced to think of the equally worthwhile BSD systems, they're minds twist up. One popular way out of this mental quandary is to attack the license.
Evidence: continual and constant attacks on the BSD license in relation to the BSD operating systems, but absolutely no attacks on the virtually identical licenses of XFree86 or Apache. Every slashdot article that even tangentally mentions a BSD system will be plastered with GPL vs BSDL posts. But it never happens on articles about XFree86 or Apache.
You're right, that's not what I meant. I tried to explain what I really meant, but you keep going back to my original fumbled words. Stop!
Let me rephrase one last time:
If someone, today, considers an action in the past to have been acceptable, then that someone, today, should still consider it acceptable in the present.
The topic of slavery is completely beside the point, because no one today considers it to have been acceptable in the past.
But we do not *currently* consider slavery acceptable either today or yesterday. However we do *currently* have double standards for acceptability, where past actions of Democrats are judged differently than the exact same actions performed in the present by Republicans.
The distribution supports it. Out of the box, actually. Unfortunately, that doesn't include during install. It worked on a USB-only motherboard, but it did not work on a motherboard with both PS/2 and USB, because the USB keyboard was somehow being seen as the second keyboard when no first keyboard was present.
I won't say which distro this is, because it's not really relevant. What is relevant is your attitude that something should be a universal standard when it still has problems on significant platforms. I have problems with USB, not as many as I had last year, but I still have them. In my own little corner of the world, USB is not universal until I can use it without problem with whatever my current software and hardware happens to be. And neither you, Bill Gates, or Michael Dell has any authority to say what the software or hardware that happens to be.
USB will replace PS/2, but not until the time is right. And that time is not today. In the meantime, nothing whatsoever is stopping YOU from using a USB-only system. That other people are not should be of no concern to you. If it makes you upset, get over it!
Slashdot Mirror
I'm saying that the kernel of FreeBSD might be superior to Linux.
Did you ever stop to think that perhaps the FreeBSD userland might be superior to GNU's? I'm not talking about comparing individual pieces, but the wholes. Some pieces of GNU are better than BSD, and vice versa.But the *overall* FreeBSD userland might be better than the *overall* GNU userland.
I currently use two monitors, both filled to the brim with icons and several drawers on each desktop.
I think you are the problem. You need to organize yourself better. If two monitors are full of icons, then I have to wonder why you consider all of them so worthwhile you can't remove some of them.
I've walked by coworkers's desks and seen Windows desktops with icons lined up all the way to the right of the screen. This isn't a rarity. I can't understand how people work this way.
Organization and priority is the key. You've got four basic spots to put stuff. Menu, panel, desktop and folders. Put your applications in the menu, with links to your five most frequently used programs on the panel. The menu should be organized by category and frequency of use. Don't accept the default locations, use the menu editor! The desktop should not contain any applications at all. It should contains icons for drives, devices and projects. The latter is the key. Organize your computing into projects, and put all your data into hierarchical folders. There's also the fifth possibility of "the command line". There's no reason for non-GUI programs to be in your menu system. For instance, I use "tidy" all the time, but have never once considered making an icon for it. If you use KDE, the Alt-F2 key is your friend.
Finally, dump anything you don't use. Do you really need icons for five different music players, six different text editors, and a handful of CD burners and rippers? Do you have a document you're finished creating? Take it off the desktop and file it away!
But until they standardize on either KDE or GNOME, it will never go mainstream!
Emphasis added...
man pages for Linux? Next thing you know, Beastie will be ice skating...
Neither does the new Apache license. I thought that was the topic...
OTOH, it's nice to have a major project with a separate license.
You mean like the BSD license used by three major BSD projects? Or the MIT license used by the major XFree86 project?
Well, if you get the contributors to sign over their copyrights from the very beginning, you would never have to worry about this. If the code was owned by the Apache Foundation, then the Apache Foundation has full right to change the license.
It's the same reason why the FSF requires copyright assignment, and why the Linux kernel will NEVER EVER have a license other than GPLv2.
You're missing the point in your focus on reality. Of course they're couldn't be a 2GHz 6502! Play the game of "what if?"
If everything else were the same, an 8-bit CPU would blow the pants off of a 32-bit CPU, for benchmarks that don't need more than 8 bits. Pipeline the 6502, give it more registers, whatever. But keep it 8-bit.
The moral of the story is, almost every architectural difference between the 6502 and modern CPUs exists for one reason: speed.
Of course, but you can create analogous architectural improvements to the 6502. The reduced instruction set of 8-bit opcodes allows a level of parallelism that a 32-bit chip couldn't achieve on the same die space. You could put the entire address space in internal cache.
A 64-bit processor isn't going to be inherently faster than a 32-bit processor, except for code that needs 64 bits.
You're right. A 2GHz 6502 would be a screamer. But the drawbacks are numerous. When the world finally went to 32bit, I jumped for joy. Not because I thought stuff would be faster, but because I could finally use a flat memory space large enough for anything I could conceivably want. Integers were now large enough for any conceivable use. Etc, etc.
Of course, my conceptions back then might be getting a bit dated now. But not too terribly much. 32 bits will probably be the optimum for general use for quite some time. There's not too many applications that need a 64 bit address space. Not too many applications need 64 bit integers. We'll need 64 bit sometime, but I don't see the need for it in *general* purpose computing for the remainder of the decade. (Longhorn might actually need to a 64 bit address space, but that's another story...).
Remembering back to the 80286 days, people were always running up against the 16 bit barrier. It was a pain in the butt. But unless you're running an enterprise database, or performing complex cryptoanalysis, you're probably not running up against the 32 bit barrier.
But of course, given that you're viewed as a dusty relic if you're not using a box with 512Mb video memory and 5.1 audio to calculate your spreadsheets, the market might push us into 64 bit whether we need it or not.
It's not following the definitive standard that every application should follow. It's no different than if I wrote a Windows program that didn't follow ctrl-c and ctrl-v.
If it doesn't work between two apps, it's because one or the other of those apps is not using the standard.
This is simple to fix, and the way this can be fixed is something you should keep in mind in general because it is helpfull in many similar situations.
If it's a true standard applicable to systems other than Linux, the BSD communities will follow it. We didn't follow the LSB because it was a standard specific. We won't follow a new LSB-with-teeth for the same reason.
Yep, it mostly sucks that a FBSD 5.x kernel install doesn't preserve modules that were added by the user. Not really an nvidia problem, more one of the kernel install.
Though I understand what you're saying, I'll have to disagree a bit. This isn't an instance of the driver failing to load, but an instance of it causing a page fault. I am not a kernel programmer by any means, but describing the problem and symptoms to a friend that is, he greatly suspects that it was caused by a fault in the modules's design and implementation.
But I will agree with you that updates should account for third party modules.
This is simple to fix, and the way this can be fixed is something you should keep in mind in general because it is helpfull in many similar situations.
I do know that one. And I did use it. But being stuck in single user mode didn't help much, because I still didn't know what was causing the problem. It would have been a two minute fix if I had known.
I blew my whole system to pot when I did not uninstall the NVIDIA drivers.
/etc backup. I was very sleepy at this point, which is the only excuse for what happened next. I still have no idea what I was thinking when I did it. I rebuilt the NVidia driver. But the kernel source tree was still 5.2. Crash!
Oh man, I feel your pain! I got burned by that driver too.
The FreeBSD NVidia driver has a fragile interface. You change your kernel or XFree86, you have to rebuild it. I forget that I was automatically loading the NVidia driver in my loader.conf. So the first boot after the 5.2 build crashed hard. Nothing I tried got around it.
So I did an "upgrade" install back to 5.1, and restored my
Sob...
Why would I give up the rock solid stability of 4.9 for an unknown?
Three reasons I can think of:
1) 5.2 supports a lot more hardware than 4.9. Granted, some of the support has been backported, but a lot has not. 4.9 won't run on my current desktop or laptop. 5.2 will.
2) New features. Unlike above, very little has been backported. UFS2, devfs, rcNG, etc.
3) "-CURRENT" doesn't necessarily mean "will crash all the time". 5.0 was a bit flaky around the edges, but 5.1 and 5.2 are very robust.
I wouldn't run 5.2 on mission critical servers, but not everything is in that category. For you Linux people out there, it's sort of like Debian. You run Debian-stable on your servers, and Debian-testing on your desktop.
i cant grasp how people could claim it works well for servers when you cant run it on smp boxen without handicapping them to death
Maybe because not all servers are SMP machines?
Silver bricks? You was lucky! In my day we had mine our own ore and smelt it down. Then our dad would assay it, and if it wasn't 99% pure, all we got for breakfast was CompUSA Silver Thermal Grease!
XFree86 under FreeBSD absolutely identical to XFree86 under Linux. Well, not quite. It does support the FreeBSD sysmouse device (think gpm).
On the other hand, you DO NOT get a distro-supplied front end tool like YaST. If you're used to configuring XFree86 the XFree86 way, you're home free. Otherwise...
My advice is to get a basic configuration using "XFree86 -configure", and see if that works. It will do all the detecting and decide stuff for you. Unfortunately, it tends to give you as high of a resolution as possible, which typically is not what you want. But it will tell you what your hardware is. After that you can use "xf86config" and answer the questions manually.
If you're using an NVidia card, and want the proprietary NVidia driver, you'll have to install it manually from the ports system. There's instructions there on how to do it, but it's not necessarily the easiest thing in the world, since you're dealing with kernel. But you can put that off for a while, since the "nv" driver that comes with XFree86 works great if you don't need hardware accelerated 3D.
FreeBSD also won't automatically add fonts to your XFree86 configuration. It's an unwritten law that no third party package or port can alter any system wide configuration file (a good thing if you think about it). But if you read the messages after installing them from packages/ports, they'll tell you what to do.
Hah! Once you get past having to administer stuff yourself, you'll find it makes an excellent desktop. In fact, it has the exact same GUI as Linux. But that administration part can be a hurdle.
Well, if you don't run away screaming at the presence of an ncurses/dialog based installer, and follow through to the configuration section of the install, you're going to end up with an extremely usable system afterwards.
But it's still not really done yet. That's because FreeBSD does not presume to know what you want. It's not going to install a desktop until you tell it to, for example. In fact, it's not going to install anything outside of the base system unless you specifically tell it to. You are in full control. For some users this will be a breath of fresh air. But for others it will be a horrifying discovery that they're not as l33t as they thought they were.
It all comes down to "BSD versus Linux". The licensing is just a red herring. Linux users have been taught that Linux is the only worthwhile Free Software operating system. They think it's the pinnacle of creation. So when they're forced to think of the equally worthwhile BSD systems, they're minds twist up. One popular way out of this mental quandary is to attack the license.
Evidence: continual and constant attacks on the BSD license in relation to the BSD operating systems, but absolutely no attacks on the virtually identical licenses of XFree86 or Apache. Every slashdot article that even tangentally mentions a BSD system will be plastered with GPL vs BSDL posts. But it never happens on articles about XFree86 or Apache.
Now maybe that was not what you meant
You're right, that's not what I meant. I tried to explain what I really meant, but you keep going back to my original fumbled words. Stop!
Let me rephrase one last time:
If someone, today, considers an action in the past to have been acceptable, then that someone, today, should still consider it acceptable in the present.
The topic of slavery is completely beside the point, because no one today considers it to have been acceptable in the past.
But we do not *currently* consider slavery acceptable either today or yesterday. However we do *currently* have double standards for acceptability, where past actions of Democrats are judged differently than the exact same actions performed in the present by Republicans.
The distribution supports it. Out of the box, actually. Unfortunately, that doesn't include during install. It worked on a USB-only motherboard, but it did not work on a motherboard with both PS/2 and USB, because the USB keyboard was somehow being seen as the second keyboard when no first keyboard was present.
I won't say which distro this is, because it's not really relevant. What is relevant is your attitude that something should be a universal standard when it still has problems on significant platforms. I have problems with USB, not as many as I had last year, but I still have them. In my own little corner of the world, USB is not universal until I can use it without problem with whatever my current software and hardware happens to be. And neither you, Bill Gates, or Michael Dell has any authority to say what the software or hardware that happens to be.
USB will replace PS/2, but not until the time is right. And that time is not today. In the meantime, nothing whatsoever is stopping YOU from using a USB-only system. That other people are not should be of no concern to you. If it makes you upset, get over it!