Lockups with USB disks on FreeBSD
I am currently using FreeBSD 8.0. I have been, for a long time, been having problems with lockups of FreeBSD 8.0 when using USB hard disks. Sometimes certain applications lock up for several minutes, when they use the disk, file operations are very slow, and sometimes the entire operating system can lock up for several minutes. This can be a pretty painful thing and makes the system seem very unstable. I am using UFS filesystems on the disks. It seems to happen on multiple disks that i use. I was hopeful changes to the FreeBSD USB drivers might have improved things but they are as bad as ever. Help is appreciated. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Lockups with USB disks on FreeBSD
David Jackson wrote: I am currently using FreeBSD 8.0. I have been, for a long time, been having problems with lockups of FreeBSD 8.0 when using USB hard disks. Sometimes certain applications lock up for several minutes, when they use the disk, file operations are very slow, and sometimes the entire operating system can lock up for several minutes. This can be a pretty painful thing and makes the system seem very unstable. I am using UFS filesystems on the disks. It seems to happen on multiple disks that i use. I was hopeful changes to the FreeBSD USB drivers might have improved things but they are as bad as ever. Help is appreciated. Are there perhaps diagnostic tools or an error log that can be enabled so I can see if maybe there is some sort of error occuring with the USB transmissions that might be causing this problem, or perhaps what part of the driver code it is getting locked up on?. Has anyone else experienced problems such as this with USB disks? If more information on my hardware is needed i will post dmesg output. Any help is appreciated. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Lockups with USB disks on FreeBSD
David Jackson wrote: David Jackson wrote: I am currently using FreeBSD 8.0. I have been, for a long time, been having problems with lockups of FreeBSD 8.0 when using USB hard disks. Sometimes certain applications lock up for several minutes, when they use the disk, file operations are very slow, and sometimes the entire operating system can lock up for several minutes. This can be a pretty painful thing and makes the system seem very unstable. I am using UFS filesystems on the disks. It seems to happen on multiple disks that i use. I was hopeful changes to the FreeBSD USB drivers might have improved things but they are as bad as ever. Help is appreciated. Are there perhaps diagnostic tools or an error log that can be enabled so I can see if maybe there is some sort of error occuring with the USB transmissions that might be causing this problem, or perhaps what part of the driver code it is getting locked up on?. Has anyone else experienced problems such as this with USB disks? If more information on my hardware is needed i will post dmesg output. Any help is appreciated. I have done some more thinking about this issue. Just an app freeze on USB access is one thing, however, the fact that the entire OS freezes up on access to the USB disk shows there are much more serious design problems in the FreeBSD kernel. A USB access should not cause the kernel to lock up for minutes. these are very serious flaws in the FreeBSD kernel and lead to an instable and unuseable system. With these problems, and the fact no one really seems to care that the FreeBSD kernel is unstable, freezes up, etc , really is shocking considering FreeBSD bills itself as a server OS. Freezes and lockups are not a sign of stability or good design, they are evidence of severe design flaws, especailly that the entire kernel would freeze. I would be glad to use diagnostic tools to help find the problem. Much of the FreeBSD kernel however seems to be a black box, I have tried to study it but it seems to be badly documented. I have not been able to penetrate it and i do not know enough, despite my efforts, about it to understand what is causing these problems. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Lockups with USB disks on FreeBSD
Aiza wrote: David Jackson wrote: David Jackson wrote: David Jackson wrote: I am currently using FreeBSD 8.0. I have been, for a long time, been having problems with lockups of FreeBSD 8.0 when using USB hard disks. Sometimes certain applications lock up for several minutes, when they use the disk, file operations are very slow, and sometimes the entire operating system can lock up for several minutes. This can be a pretty painful thing and makes the system seem very unstable. I am using UFS filesystems on the disks. It seems to happen on multiple disks that i use. I was hopeful changes to the FreeBSD USB drivers might have improved things but they are as bad as ever. Help is appreciated. Are there perhaps diagnostic tools or an error log that can be enabled so I can see if maybe there is some sort of error occuring with the USB transmissions that might be causing this problem, or perhaps what part of the driver code it is getting locked up on?. Has anyone else experienced problems such as this with USB disks? If more information on my hardware is needed i will post dmesg output. Any help is appreciated. I have done some more thinking about this issue. Just an app freeze on USB access is one thing, however, the fact that the entire OS freezes up on access to the USB disk shows there are much more serious problems in the FreeBSD kernel. A USB access should not cause the kernel to lock up for minutes. these are very serious flaws in the FreeBSD kernel and lead to an instable and unuseable system. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org Your description about what is happening is lacking any detail. Tell us what is on the USB disk, How you are using it, How you created it ECT ECT ECT Booting your system from it is way different than writing small data files to it or containing a raid file system or some database. You have to help us help you. The USB disk is being used with 2 UFS filesystems on it. Due to the bad performance, it takes a long time to copy data to the disk. It seems as though there is a complete lock up periodically when doing a very large copy. The system becomes very unstable. Conditions worsen when two or three apps are using the disk at once, it seems. Often the entire OS can lock up for minutes when the disk is being used. I once tried to copy a 200 mb directory, it took 7 hours. Perhaps the developers of the USB system would like discuss this, so we can figure out what is going on. I do not know enough about it as to say exactly where the problem is. Has anyone else been having these problems? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Severe instabilities and system lockups
I am still having severe problems with severe system instabilities with FreeBSD and have had these problrms in 7.1 and 8.0. The system randomly locks up, it appears applications lock up when they access the USb disk. Also, when accessing the USB disk, the entire system lockup often for minutes. Performance with accessing USB disks is horrendous,. it took 7 hours to copy a directory that was 200 MB. Any program that accesses the USB disk tend to freeze for minutes, and often the entire system becomes unresponsive for minutes. Overall FreeBSD here is characterized by severe instabilities, ive had better performance from Windows 98 systems. The fact that the entire system freezes up, this should not happen, a well designed system will not lock up the entire OS when accessing disk. Are there any diagnostic tools uch as getting a log of tranmissions on USB and probe it, ,or finmd out what code it is lockilng up on ?Has anyone else seen these problems with USB disks? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Severe instabilities and system lockups
David Jackson wrote: I am still having severe problems with severe system instabilities with FreeBSD and have had these problrms in 7.1 and 8.0. The system randomly locks up, it appears applications lock up when they access the USb disk. Also, when accessing the USB disk, the entire system lockup often for minutes. Performance with accessing USB disks is horrendous,. it took 7 hours to copy a directory that was 200 MB. Any program that accesses the USB disk tend to freeze for minutes, and often the entire system becomes unresponsive for minutes. Overall FreeBSD here is characterized by severe instabilities, ive had better performance from Windows 98 systems. The fact that the entire system freezes up, this should not happen, a well designed system will not lock up the entire OS when accessing disk. Are there any diagnostic tools uch as getting a log of tranmissions on USB and probe it, ,or finmd out what code it is lockilng up on ?Has anyone else seen these problems with USB disks? Thank you for the reply to my concerns. I have been reading through them carefully. I seem to have also discovered that the lockup problems are not entirely due to USB issues. Many of them were being caused by an apparent problem with the swap system. I have two swaps, a file backed swap and a partition swap on the same disk. Apparently when having two swaps on the disk there are severe performance problems. FreeBSD needs to fix whatever is causing this thrashing problem. So far the lockups have seem to become much less severe since i have disabled the file based swap file. I may disable the partition swap but i do not know if it is possible to have the system boot with a file based swap only. Perhaps i can disable the partition swap after it boots. I am trying to copy a directory on the USB drive however and it does seem to be rather slow still. It started at 5:45 and is still going. I will see how long it takes. Again thanks for the help with these issues ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: 2020: Will BSD and Linux be relevant anymore?
I do not believe that these phones or tablets will replace desktop but there is a lot of room for these two types of devices basically to communicate, giving people access to their data and environment from both. The reason I dont see the desktop going anywhere is that, basically people dont want to work on a spreadsheet, play a game, write a letter or do many other things on a 3 screen. Students wont want to use them to do their reports, etc. Phones and tablets are handy when on the go due to the portability, but their portability makes them impractical for use at home when a larger screen is more desirable. The growth of tablets is due to there simply not being the market there before and more people buying them for mobile use. But desktops will remain popular for home and work use. Also users want upgradeability, they dont want to be stuck with the same amount of hard disk space and may want to add a new camera to the system, a capture device, scanner, etc. Desktop systems provide much more upgrade flexibility. Linking the desktop to the tablet will be an important thing so people can access data and so on from their tablet. Problems with Linux and BSD user share relate to the lack of useability. One of the useability issues relates to hardware driver issues. I am convinced the only way to make Linux or BSD user friendly is to acknowledge that we need to make it so that 3rd party hardware provider drivers can be used easily on these operating systems and there is backwards compatability, allowing the drivers for an older version of the kernel to be continued to be used. Its not that I love the idea of 3rd party binary drivers, but that by putting up with the necessary evil we can greatly increase usage of BSD by greatly improving hardware compatability by getting hardware vendors to write drivers for their hardware. This of course still means open source drivers can be developed and then used instead of the hardware provider drivers, however, the hardware provider drivers would be avialable for many devices where open source drivers may not be available for months or years, if ever. Increasing available of hardware drivers for FreeBSD will also mean increasing numbers of FreeBSD/PCBSD users and that would mean more potential sources of donations, which could be requested by a pop up after installation. It is clear that hardware companies can provide hardware drivers more quickly and better tested and implemented for the hardware than kernel developers can. For instance, they can port their Windows drivers. People do not want to wait years for their hardware to be supported or having to not be able to use many kinds of hardware just so they can use BSD or LInux. People want to use hardware, and also they do not want a huge hassle with getting hardware to work. Basically users need to be able to plug in the device, throw the CD in the drive, and the hardware driver should install itself and work. Users are not going to use an OS that wont support hardware when Windows will. They are not going to wait months when hardware will work on windows right away. They wont give up on being able to use some hardware because it wont work on BSD, they will just use Windows. Hardware companies are not going to always provide open source drivers, but are willng to provide binary ones. And as well, Hardware companies need to have a well documented API, so they dont have to spend months trying to figure an undocumented API in the BSD kernel to figure out how to write a driver, and a stable ABI so they can release one copy of the driver and have it continue to work with many different versions of the kernel well into the future. The User may buy a printer that has a driver CD in it, this may be sitting on a store shelf for months or a year, and as well, the user may need to use this CD for years down the road to use their printer. The OS needs to support that binary driver for years following. We need hardware manufacturers to develop drivers and support their own drivers. The case with drivers developed by BSD people is the drivers may take months to appear, or for lesser known or more exotic software, might not be available ever. By putting up with a few pieces of binary 3rd party driver modules the deployment and popularity of BSD can be increased as it will begin to be useable with far more hardware. I think the hardware support problem is really the stumbling block now. Hardware support has to be avialable for hardware immediately. Users having a BSD OS install process bomb because their hardware is not supported is not acceptable, things have to work out of the box. Here BSD has advantages over Linux. There is no legal question that binary drivers can be used with BSD, there is no legal ambiguity here. BSD does have a potential really to compete with Windows for hardware support. provided, we make it easy for companies to develop drivers by providing for good documentation and facilities for quick, rapid
Re: 2020: Will BSD and Linux be relevant anymore?
upgradability is not just about about ram and hard drives. But i would beg to differ that people dont want to add hard drives considering how fast they can be filled with movies, or they wouldnt want to use their old hard drives on a newer system considering how much data is on the older hard drive. but you also have scanners, cameras, joysticks, capture devices for video, and so on that many common users love to use. A lot of people use computers for writing, home and office business work, and gaming, and given the choice between a 3 screen and a 20 screen, you want a 20 screen. Even facebook is better on a 20 screen. I stand by what i said, mobile is great for use on a subway, but when you get home, you really want a nice 20 screen to work on, and the bigger hard drive and faster CPU. I do want FreeBSD on both my handheld and the desktop. Now, notice its very difficult to near impossible to change the operating system on handhelds. Thats one reason I dont like most handhelds made today. They are designed to control you. On Wed, Jul 20, 2011 at 2:46 PM, Daniel Staal dst...@usa.net wrote: On Wed, July 20, 2011 1:52 pm, David Jackson wrote: I do not believe that these phones or tablets will replace desktop but there is a lot of room for these two types of devices basically to communicate, giving people access to their data and environment from both. The reason I dont see the desktop going anywhere is that, basically people dont want to work on a spreadsheet, play a game, write a letter or do many other things on a 3 screen. Students wont want to use them to do their reports, etc. Phones and tablets are handy when on the go due to the portability, but their portability makes them impractical for use at home when a larger screen is more desirable. The growth of tablets is due to there simply not being the market there before and more people buying them for mobile use. But desktops will remain popular for home and work use. Also users want upgradeability, they dont want to be stuck with the same amount of hard disk space and may want to add a new camera to the system, a capture device, scanner, etc. Desktop systems provide much more upgrade flexibility. Linking the desktop to the tablet will be an important thing so people can access data and so on from their tablet. I'll disagree, somewhat: I know several people who are using a tablet as a desktop-replacement laptop. They have a Bluetooth keyboard, and can use the tablet as a full computer or not. Most *consumers,* in my experience, also don't typically care about upgradablity. Either the machine works when they get it, or it doesn't (which is a warranty issue), and after that if it breaks in few years, well, time to get a new one. A few will add RAM or a HD when they get it, but that's about it. Other additions, if any, are done as USB/Bluetooth, etc, and can be done on a tablet just as easily as a desktop. As for binary drivers... They work ok *if* and *while* the company wants to support the hardware/OS. Once they decide they don't want to, that's it. This tends to cause problems down the road. Also, they may do no more than the minimum necessary to support a certain version of the OS, unless that OS is a major source for their customers. So while they *can* make better drivers than the core team, they often *don't.* Best is an open driver by the manufacturer. Second is open docs, third is binary blob. My opinion. Daniel T. Staal --- This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. --- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Archived FreeBSD versions
I have been looking for archived versions of FreeBSD back to 2.0. Where can these be found? I have looked on the FTP site but cannot find them there. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Problems with pkg_upgrade
Since I wish to use packages instead of ports to update my system, someone recommended I use pkg_upgrade. However, basically, it does not work. It gets to downloaded packages. But, after 10 packages, it prints a message Protocol error and then Package x cannot be fetched, where x is the name of the pavkage it stops at. I can restart pkg_upgrade, it downloads 10 more packages where it stopped previously, but then gives this same message again. Maybe the connection to the FTP server os being lost and code needs to be added to automatically restart the FTP connection without the whole thing crashing? I do think packages need to be better supported on FreeBSD, many users do prefer to use packages due to speed and convenience and do not prefer to build it all. it shouldnt be such a hassle ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Problems with pkg_upgrade
On Sun, Dec 25, 2011 at 11:52 PM, Carl Johnson ca...@peak.org wrote: David Jackson djackson...@gmail.com writes: Since I wish to use packages instead of ports to update my system, someone recommended I use pkg_upgrade. However, basically, it does not work. It gets to downloaded packages. But, after 10 packages, it prints a message Protocol error and then Package x cannot be fetched, where x is the name of the pavkage it stops at. I can restart pkg_upgrade, it downloads 10 more packages where it stopped previously, but then gives this same message again. Maybe the connection to the FTP server os being lost and code needs to be added to automatically restart the FTP connection without the whole thing crashing? I do think packages need to be better supported on FreeBSD, many users do prefer to use packages due to speed and convenience and do not prefer to build it all. it shouldnt be such a hassle I can't help directly with your problem, but both portupgrade and portmaster support packages. In both cases you can just supply the -P or -PP options to specify how to handle packages. I think they both require that the ports tree be present for the /usr/ports/INDEX file, but otherwise they can use just packages. -- Carl Johnsonca...@peak.org _ The fact is, I have had problems with portupgrade as well, in fact, portupgrade would give errors as well with not being able to download packages, the entire upgrade process at that point would fail. That is the reason I am trying pkg_upgrade. Again, things should work better than this. Things shouldnt be such a hassle. It should work similar to ubuntu apt-get, where it just works out of the box. You type apt-get upgrade and it automatically upgrades everything, no need to mess around, __ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Problems with pkg_upgrade
On Mon, Dec 26, 2011 at 9:43 AM, RW rwmailli...@googlemail.com wrote: On Sun, 25 Dec 2011 23:14:24 -0500 David Jackson wrote: I do think packages need to be better supported on FreeBSD, many users do prefer to use packages due to speed and convenience and do not prefer to build it all. it shouldnt be such a hassle If you want to use packages I would suggest updating, as far as possible, to release package. Huh? The release packages are most out of date. The idea of using old versions of packages, such as firefox, is dangerous because security vulnerabilities are always being fixed. So, it really is a best practice to use the most up to date packages rather than very old ones. To be more user friendly there needs to be less fuss to using FreeBSD, it needs to just work. I am a system administrator and in fact, an operating system that makes things unnecessarily difficult to get working is a problem, user friendliness is not just for non techies. Good software design involves allowing the user to configure and work on all parts of the system, and to make things work the way they want, but not forcing them to configure anything to use the software, it should work out of the box with reasonable defaults, and then the user can fine tune to their needs. On ubuntu, packages can be easily upgraded with apt-get upgrade. No fuss, no mess, no hours of trying to get something which should be simple to work. so a system should be very flexible, configurable, transparent and so on, but a user should not have to configure anything since it should have a reasonable default behaviour. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
FreeBSD Kernel Internals Documentation
I have had an interest in studying the FreeBSD kernel and getting to know its internals better. After all, in Open source projects, they say, community contributions are important. However, My finding is that due to poor documentation, the FreeBSD kernel is nearly impenetrable to an outsider. I have been able to find no comprehensive documentation of kernel internals. I have found it nearly impossible, due to lack of comprehensive documentation, much of any of the kernel internals. What I see is an internal cliche of developers who are aware of its myraid of undocumented esoteric secrets, and very little to actually help anyone else to understand it. Any good, well designed software projects will have comprehensive documentation of the source code, this includes code comments, information on what every piece of code does, how the entire system fits together, and descriptions of every variable and function. Any well run project would insist that code contributors upload full and comprehensive documentation of how their source code is written, how it works, etc. Documentation is vital and good practice because it saves time, it prevents people new to the project having to waste immense amounts of time trying to figure out a vast and cryptic puzzle. Without good documentation software can be nearly useless, unmaintainable and difficult for an outsider to learn, to the point where it may actually take less time to just throw it out and start from scratch. These are reasons that FreeBSD needs better documentation, documentation of how the entire system fits together, what lines of code do, the purpose of variables and functions, etc, in descriptive English. This is key to developing maintainable software. I saw where someone automatically generated documentation with Doxygen. This is nearly useless, because all it shows is a huge list of functions and variables but does not include any text on what they do. At best, Doxygen can only provide a template for documentation that can be filled in with descriptive English information on what everything does. One idea might be to have an official wiki that contains the template generated by Doxygen which can then be filled in. When changes to the source code is made, it is good practice for the commiter of such changes to document their code as it is submitted. This allows others who come along who need to maintain the code to more easily understand what the code does. Another idea which would also improve the useability of FreeBSD would be to have a wiki which would be updated by kernel contributors whenever they add support for a certain piece of hardware. This would make finding hardware compatability information easier from one central, up to date and current source of information. These documentaiton ideas, for commiters to document their code when they upload it, and document their hardware support additions, are just good software practices that should be highly recommended and encouraged ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD Kernel Internals Documentation
On Fri, Dec 30, 2011 at 1:04 AM, Robert Bonomi bon...@mail.r-bonomi.comwrote: From owner-freebsd-questi...@freebsd.org Thu Dec 29 21:46:36 2011 Date: Thu, 29 Dec 2011 22:43:16 -0500 From: David Jackson djackson...@gmail.com To: freebsd-questions@freebsd.org Subject: FreeBSD Kernel Internals Documentation I have had an interest in studying the FreeBSD kernel and getting to know its internals better. After all, in Open source projects, they say, community contributions are important. However, My finding is that due to poor documentation, the FreeBSD kernel is nearly impenetrable to an outsider. I have been able to find no comprehensive documentation of kernel internals. I have found it nearly impossible, due to lack of comprehensive documentation, much of any of the kernel internals. What I see is an internal cliche of developers who are aware of its myraid of undocumented esoteric secrets, and very little to actually help anyone else to understand it. You're talking abaout _volumes_ of documentation, literally many books worth. Start with The Design and Implementation of the BSD 4.4.4 Operating System by McKusick, eal. Then read The design and Implementation of the FreeBSD Operating System, by McKusick and Neville-Neal.` *You* are free to contribute 'better documentation' as you review any particular file. Since you feel it is important, you are strongly encouraged to do something to actually 'make it better', as opposed to merely sitting on the sidelines and sniping at the work of others. Well, okay, yes, I have heard of these books. Of course, if I am getting involved in studying and figuring out the FreeBSD kernel, I would contribute documentation, both for my own future use and for the benefit of others. Of course, those best able to document are those who wrote it in the first place, since they already know how it works. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD Kernel Internals Documentation
Again, as we did discuss (and agree upon) before, supporting FreeBSD is not in the scope of hardware manufacturers. Supporting more than the platform they get aliments for simply wouldn't pay. The unit sales for _this_ world of IT are simply to low to justify the work. That is the chicken and egg problem, an OS with bad hardware support people dont want to use, hardware vendors dont want to support OSs with few users. The alternative would be to release all the specs for the hardware. But if a manufacturer doesn't want to do this, primarily to _not_ publish essentials of the business, it is okay. Of course, this makes it harder for _free_ volunteers to write a driver. One could argument: The manufacturer _doesn't_ want you to use his hardware on any OS that is not Windows - which again is his right. I am not a socialist asshole. I'm happy to hear that, so please don't behave like one. Fascism is a derogatory term. Socialism, is not, means in its correct definition worker democratic control of the business they work for. One example is an employee owned corporation. it does not mean in correct definition central control, in fact, it is democratic and distributed power. The meaning of the term has been distorted by revisionists. Communism is where the idea that people contribute what they produce to the community and then receive what they need from the community, sort of like barter. It is a stateless system, hence, the revisionist US definition of the term is wrong, communist societies do not have a government. Communism/anarchism may be possible where there is a massive overabundance of resources, but with how overpopulated the world is those days are long gone. Stalinism is the proper term for the USSR as it was for many years, or state capitalism, where a dictatorship controlled a lot and it was not a democratic government, North Korea is also state capitalist. These are not communist or socialist societies in any way whatsoever. communist in name only. North Korea calling itself Communist is scandaleous, and as scandalous is people in the USA to similarily corrupt the term and defile its original meaning. The US economy has long been a hybrid of government and private industry and in fact, that is what tends to be most workable, government is better at doing some things, private industry at others. BSD remember was funded by the US government with DARPA contracts for many years. I think the investment of public money was well worth it in creating an operating system that is open and publicly accessible. I don't expect the government to bankroll me while I sit on my ass working on a hobby. So why do _you_ bankroll the government with your tax money for sitting on their ass spying at you or doing nothing? :-) Operating systems have become ubiqutous . Why not publicly fund an OS that is open and that everyone can use rather than be stuck with closed, crappy OSs from Greedy corporations like Microsoft. Remember, BSD was funded by the US governemnt. If FreeBSD really wanted to make a quality product they would hire competent programmers to create the drivers, etcetera that are seriously needed. I would gladly pay any reasonable charge for a product that worked. I am not a socialist/fascist asshole and I despise those who are. Other OSs have all ready gone this route. I would also be willing to buy FreeBSD as an OS if the functionality I require can be purchased that way. It's not that I'm using free software exclusively. I can't do that because _my_ reqirements are 99% met by free software, and 1% isn't, and this is where I happily pay to get things working. Contribute to FreeBSD Foundation, FreeBSD improvements can be funded with voluntary contributions if people make them. By the way, just out of morbid curiosity, how are ASLR and KMS support coming along? Doing a quick perusal it would appear that everyone but FreeBSD supports them. I am sure if I am in error and FreeBSD has full support for them you will inform me of same. I think KMS is still a Linuxism, such as Wayland. But it's possible that it will arrive in FreeBSD when an urgent need by its users is expressed. As long as this is a niche application, I don't think support will be created. You know, it's _very_ deep inside the bowels of the OS where this work has to be done.. KMS is what allows the kernel to basically restore the video display to a functioning condition of the X server crashes? is that all it does? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD Kernel Internals Documentation
On Sat, Dec 31, 2011 at 9:18 AM, Bas Smeelen b.smee...@ose.nl wrote: On 12/31/2011 01:02 PM, Joe Gain wrote: Writers who rely on ideological positions such as (socialism || fascism || jedi-knight == good | bad) really need to go visit a social science mailing list. It's not like political/ religious mailing lists don't exist. My positivist take on things: 1. Nobody is stopping anybody from changing their freebsd kernel. The same cannot be said of MS Windows. Documentation is an excuse. FreeBSD is very well documented! I guess a lot of people can't cope with how structured and professional it is. They are used to chaos, fear, uncertainty and doubt and feel comfortable that way. My experience is that FreeBSD kernel documentation is spotty and not really sufficient to understand the kernel. Without good documentation, code can take so much time to decipher it might be quicker to just throw it out and start from scratch. Maintainable code requires documentation. 2. FreeBsd is a main-stream O/S-- just look at the number of different architectures/applications which are supported by FreeBSD. Main stream and top player for web and internet servers FreeBSD is far from being mainstream or practical for most users. I tried to use a USB video capture device. For you, what may be useless may be indespensible for others. We should improve FreeBSD to make it work for better for more people, experts and non-techies alike. I am really appalled at an attitude that some have against making it better, adding features and functionality that will make for a smoother experience, its as if they dont care about anyone else and want the OS to be useful to no one else. We need to make it better for everyone. 3. FreeBSD isn't even hard to use, if you only want to use it like 80% of computer users, to run your web browser, watch videos and listen to music. People who consider it difficult might like to remember their first experiences with learning windows. Windows is much easier to learn than learning FreeBSD. On windows usually getting hardware to work just involves putting in a driver disk and clicking install.On FreeBSD, it can be difficult to impossible for even expert users. Again, most people want to do more than just watch a video, there are devices such as USB capture devices that people do want to use, and a vast array of hardware such as scanners that do not work on FreeBSD. 4. Drivers aren't really a limitation. Look at the history of computing, that modern O/S support such diverse platforms is an amazing development. As far as I'm concerned, FreeBSD supports main stream components, there are no classes of components that I'm aware of which aren't supported by FreeBSD. If you need to use a particular device, for which there is no driver, historically it's not unusual to find that on any particular platform a particular device is not supported. It supports most things except the things you wouldn't want anyway Drivers are a huge limitation, the lack of them, Here I beleive you are just plain wrong. The fact is, people do not want to have to think about whether or not their hardware will work with an OS or fight the OS for days to make it work. Trhe truth is on Windows things really do just work. Ive set up Windows, I know this. Windows has other things however which make it undesirable to use. What I want to use is combine the things Windows has right with an open source, free OS. The way things are now does not make since, you can use Windows, and the hardwarw works, but its a closed platform. You can use FreeBSD, which has bad hardware support, but is an open platform. I want to see an open platforn that has great hardware support, even if we have to use binary drivers. 5. Nobody is making anyone use FreeBSD. It's free. If you don't enjoy it, don't use it. Maybe remove yourself from the mailing list-- or don't, if you just want to stay informed. If you don't like it, please leave, there are a lot of alternatives What you are saying here is that your idea is instead of FreeBSD being responsive to the needs of all users, you basically want to own the project and dont care about anyone else. Normative takes: 6. Is FreeBSD better than windows? For me it is. For me it's stabler. What I remember from using windows, and what I'm aware of, from people around me who use windows is that over time, the system seems to degrade. This leads to really major actions such as re-installation every 6mths or so. And... It is! 7. The temptation to install illegal software on MS Windows is very high. Who wants to pay for every little gimmicky app? Who can afford to pay for some major applications, which are needed for studying etc.? This often leads to an unstable system and security problems. The ports system in comparison is a much preferred software/ application distribution system because at least you get to look at the source code, if you want to. Most
Re: FreeBSD Kernel Internals Documentation
An OS should strive to be a better platform for many people, including techies and non-techies. A good software design philosophy is that good software works out of the box without configuration using reasonable defaults, but, that that the software should be flexible, very configurable, the user should be able to configure everything how they need it, but they should not be required to. This allows the user to configure as much or as little as they want. Everything should be able to be accomplished with both GUI and CLI, and API. The entire system should be well understood, well documented and transparent . Its like a car, its better to have a car that has a spacious engine compartment and is very well documented in service manuals so that a car mechanic can easily fix it. While not every user may want to get under the hood, a spacious, well documented and easy to fix space under the hood makes the mechanics job easier of fixing the car. The car being made more reliable and easier to use as well means that the common driver has fewer breakdowns. Windows is a terrible OS because its like a car with the entire engine area sealed in a compartment that can only be opened with the car manufacturer with a key, so mechanics cannot even repair it. There is no dount that UNIX is a better design system, due to the fact it is open and the underlying systems are well understood, well defined and well known, including due to the Unix philosophy of modularisation of components. I am in full agreement with Unix design philosophies and unix conventions. I definitely oppose any effort to re-invent Unix or break with unix conventionsand philosophies. It has been said that people who try to reinvent Unix will do so poorly. I agree. I am very much in favour of respecting Unix traditions, backwards compatability and conventions. For instance, supporting the X11 Window System i think is something that we should always commit to, it is important for compatability and for the flexibility it provides. I think tis okay to build additions to the system, but in addition, to the existing components, not to overthrow existing parts of the system. Backwards compatability is very important which is why it is important to respect conventions such as POSIX. I think that we can create a GUI front end built on top of the Unix system that helps manage and configure the underlying Unix system for non-techie users. This is layered design that gives us both the techie friendliness and controllability of Unix and a GUI front end over that for non-techies. No one should be required to use a GUI front end and should be able to directly edit configuration files if they want and use the rich CLI that FreeBSD has. This is a philosophy i like of allowing users to exercise as much or as little fine control over the system as they want. An OS can be both techie and non-techie friendly by create GUI layer that is built over the underlying Unix system where more common features are put up front in the GUI, and advanced configuration in advanced screens, and layering the GUI on top of other layers which can be directly accesssed by techie users if they need to do so. This is the layered design where the GUI can serve as a front end layer to the underlying Unix system components. The techie users can directly access these underlying components if needed. GUIs as well can serve and be useful to both techie and non techie users, advanced configuration settings can be placed in advanced screens and so forth. A good GUI does not come from having few features, good, useable software has lots of features and is very flexible. Features should never be withheld because users are viewed to be too stupid. Good GUI design comes from good layout and putting more advanced features deeper in the UI, so they are there if needed. I think that we should be pragmatic about binary drivers and that it better to accept and welcome binary drivers from hardware companies. Open source drivers should of course be developed, then users can use the open source drivers as they become available, but, until then, they can use the binary driver, or use a binary driver for more rare and unusual hardware. I do think that, hardware driver backwards compatability should be provided perhaps through a compatability layer that can be loaded into the kernel as a module, and perhaps could be a porting of the IOKit driver system from Darwin, perhaps even allowing Darwin drivers to be used on FreeBSD. All of this can go into a kernel module so that if all one uses is native FreeBSD drivers made for FreeBSDs normal driver API, they won't need to load this subsystem. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD Kernel Internals Documentation
On Tue, Jan 3, 2012 at 9:46 AM, Alejandro Imass a...@p2ee.org wrote: On Tue, Jan 3, 2012 at 1:41 AM, Da Rock freebsd-questi...@herveybayaustralia.com.au wrote: On 01/03/12 12:06, Walter Alejandro Iglesias wrote: On Mon, Jan 02, 2012 at 12:33:20PM -0700, Chad Perrin wrote: Ubuntu, actually, has thrown out the baby with the bathwater. In its zeal to make things just work in a particular manner, it seems I would just like to add that is FreeBSD was so crappy open sour software, why does it run half the Internet? http://freebsdfoundation.blogspot.com/2011/12/apache-software-foundation-testimonial.html -- Alejandro Imass ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org I Never said that FreeBSD was not a good OS to use on a server, if you just want to install it and use it, its a really great OS on a server. My concerns, and this is entirely sincere and a result of my own attempts to read the source, that rarely, if ever, have I ever seen C code that is self documenting and where additional textual descriptions would not speed up learning of the source code to be able to work on the source code of the kernel. There is very little documentation of kernel internals and the source code comments are, really quite honest, do not really do a good job of explaining things.An example of somewhat better source code commenting can be seen in Minix. this makes it really hard, and it takes much longer than it should to become acquinted with the kernel and it is just an unproductive and bad coding style to not document source code, not necessarily in the file but it can be in a wiki of some sort. Document your stuff is really important and a well known good coding practice, Ubuntu got some things right but has gone awry on one thing the HORRIBLE Unity UI which most everyone i talk to hates it. The good thing about Ubuntu is with apt-get installing and maintaining up to date packages is easy and things usually come in an working out of the box state. If you dont like how Ubuntu is configured it is a real Unix system and one can get into the configuration files and change anything that one needs to. I used to use FreeBSD a lot but since Linux tends to support more hardware and plays better with Virtualbox I have had to use that more. I actually was considering starting my own project to develop some sort of driver compatability layer that would allow Darwin and or Linux drivers to be loaded on FreeBSD, and provide a stable binary ABI, in a kernel module. This is one reason I have started to look at the FreeBSD source code and noticed how difficult it really is to understand anything due to lack of documents. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD Kernel Internals Documentation
And that's just the way it is now. Try replicating the wealth of information you get in various config files in FreeBSD in a GUI. Just how hard it is to open a simple text file in an editor and just fracking do what it tells you to in comments?! And it's not just the base system, any decent third party program has this wonderfull feature. How hard can it be?! Seriously. Sure, sometimes things can get confusing but that's the nature of any complex system, you can't make it go away with a GUI. I absolutely agree that no one should be required to use a GUI. it should be there for those that want to use it. But you should be able to directly use config files if you would like, the GUI in any case would just be a front end to config files that, you would not need to use the GUI if you do not want to. A GUI for some users can improve useability. I think that we should be pragmatic about binary drivers and that it better to accept and welcome binary drivers from hardware companies. Open source drivers should of course be developed, then users can use the open source drivers as they become available, but, until then, they can use the binary driver, or use a binary driver for more rare and unusual hardware. You are either confusing FreeBSD with OpenBSD or just plain trolling. I would never troll. Everything I say is my sincere view, I do not say anything to offend people. As for my idea for a driver compatability layer of some sort, I have looked into doing that myself, Its not something i have asked anyone to do, that is the reason I have been studying the freebsd kernel. I think that, a description, some sort overview of how the kernel is put together, where things are, such as the location of the PCI system in the source tree and so on and how things fit together overall is something that I was sort of looking for as far as documentation, especially. in my comparison of source code, it seems like FreeBSD is about the same as far as source code comment quality, and Minix has much more descriptive source code comments. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Clang - what is the story?
On Sat, Jan 21, 2012 at 7:11 AM, Da Rock freebsd-questi...@herveybayaustralia.com.au wrote: I've been seeing a lot of hoorays and pats on the back and a general feeling satisfaction in being able to use clang to compile FreeBSD and ports. The only reason I can see from searching is a need to get away from gcc (which is tried and tested since the beginning of time) which is now apparently GPLv3. Can someone offer some clarity as to the importance of this? I'm guessing the that stepping away from GPL is generally a good thing, especially if there is something similar with similar license structure to BSD; I just can't understand the rush of it. Even under GPL anything built using gcc can be licensed as you like, so I doubt it could be that. I'm not skeptical, just curious- trying to get my head around some of the dev side of things :) __**_ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/**mailman/listinfo/freebsd-**questionshttp://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-** unsubscr...@freebsd.org freebsd-questions-unsubscr...@freebsd.org The reasons for Clang are not just for the GPLv3 issue, but Clang is architecturally superior in many ways over GCC, Clang was designed from the ground up to learn from GCCs mistakes and to be a better C compiler. One of the Clang's features is better debugging and a more modular architecture that is easier to develop and extend. GCC has often been criticised for its monolithic and inflexible structure that has often hindered implementing new features and functionality. One of the advantages of Clang is that it can be more easily plugged into IDEs for integrated debugging. You can read all about the many advantages and innovations of clang and how it exceeds GCC here: http://clang.llvm.org/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Trouble upgrading packages after 9.0 upgrade
I upgraded to 9.0. But when i use pkg_upgrade -a, i get this: ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-9-release/INDEX: File unavailable. Why? Also portupgrade -PP -a also fails spectacurly. Why. It seems like it is getting more and more difficult to use FreeBSD. To upgrade to the most recent packages should be a one step process of typing a simple upgrade command.it should work out of the box. It seems like the difficulties of getting FreeBSD to work make it unuseable for most people. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Trouble upgrading packages after 9.0 upgrade
On Sun, Jan 22, 2012 at 8:26 PM, Joshua Isom jri...@gmail.com wrote: It should be 9.0-release. I suspect a problem with pkg_upgrade any not FreeBSD. Install misc/compat8x and you won't need to upgrade all the ports at once, they'll still work. Yes But I want to be able to upgrade the binary packages all at once. The fact is, it shouldnt be that hard. This should work right out of the box. I should not have to configure anything for this to work. Why can't FreeBSD make something so basic work out of the box? It is important for having a useable OS to be able to install and upgrade everythinbg from binary packages out of the box like can be done on Ubuntu. I dont know whats wrong with this freebsd 9.0-release stuff or how to fix that error message. Your response does not tell me how to fix it. The thing is, I should not have to fix this because it should work out of the box. On 1/22/2012 12:42 PM, David Jackson wrote: I upgraded to 9.0. But when i use pkg_upgrade -a, i get this: ftp://ftp.freebsd.org/pub/**FreeBSD/ports/i386/packages-9-**release/INDEXftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-9-release/INDEX: File unavailable. Why? Also portupgrade -PP -a also fails spectacurly. Why. It seems like it is getting more and more difficult to use FreeBSD. To upgrade to the most recent packages should be a one step process of typing a simple upgrade command.it should work out of the box. It seems like the difficulties of getting FreeBSD to work make it unuseable for most people. __**_ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/**mailman/listinfo/freebsd-**questionshttp://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-** unsubscr...@freebsd.org freebsd-questions-unsubscr...@freebsd.org __**_ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/**mailman/listinfo/freebsd-**questionshttp://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-** unsubscr...@freebsd.org freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Unable to upgrade packages on FreeBSD
I have tried endlessly to no avail to upgrade binary the packages on Freebsd to the latest version. I have tried: *portupgrade -PP -a *portmaster -PP -a *pkg_update All fail miserably and totally and have left the system in an unuseable state. Why can't FreeBSD just make the package system just work. Right after installing FreeBSD I should be able to type a single command such as update_packages and it should update all packages on the system, with no errors and without requiring any configurations to be troubleshooted, it should work out of the box. Why not? Why is something so simple so difficult and impossible? Ubuntu can do it, why not FreeBSD? Why cant FreeBSD Just make the package upgrades work. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Unable to upgrade packages on FreeBSD
On Mon, Jan 30, 2012 at 3:58 PM, Bas Smeelen b.smee...@ose.nl wrote: On Mon, 30 Jan 2012 12:52:07 -0500 David Jackson djackson...@gmail.com wrote: I have tried endlessly to no avail to upgrade binary the packages on Freebsd to the latest version. I have tried: *portupgrade -PP -a *portmaster -PP -a *pkg_update All fail miserably and totally and have left the system in an unuseable state. What's unusable? For instance, servers are perfectly usable without graphical tools. If you have tried `endlessly` why didn't you consult /usr/ports/UPDATING and just recompile the ports without using binary packages? Or you might want to try PCBSD, it's FreeBSD with some fancy stuff taken care of which might solve the problem you complain about. I wish to use binary packages and I specifically do not want to compile anything, it tends to take far too long to compile programs and would rather install some packages and have it all work right away. Binary packages are a big time saver and are more efficient. It should be easy for FreeBSD to make it easy to install the most recent versions of all binary packages, its beyond belief they cannot pull off such a simple ans straight forward, and basic part of any OS. Why can't FreeBSD just make the package system just work. Right after installing FreeBSD I should be able to type a single command such as update_packages and it should update all packages on the system, with no errors and without requiring any configurations to be troubleshooted, it should work out of the box. Why not? Why is something so simple so difficult and impossible? Ubuntu can do it, why not FreeBSD? FreeBSD unlike Ubuntu is an entirely volunteer project. Ubuntu has a dedicated corporation working on it and I guess a larger user base. The reason that FreeBSD has a smaller user base is because it has a dysfunctional package system and it is hard to upgrade package to the most recent version, making FreeBSD more difficult to use/ But doing a workable package system is not difficult, it something that FreeBSD should be easily able to make it easy to have a way to upgrade packages to most recent versions out of box anbd in an error free and reliable way. Why cant FreeBSD Just make the package upgrades work. Because uh well it's not up to FreeBSD since the ports work perfectly with the documentation that comes with it or it might depend on the user base also, but _you_ can help to make binary package upgrades work better. A working package system is a part of any good operating system and saves time from having to compile programs. It is more convenient for most users to use packages so having a package system will make FreeBSD more popular. the reason freebsd is not used by as many people as Ubuntu is because of the extreme difficulty and unreliability of using FreeBSD. FreeBSD does not HAVE to make the system reasonably easy to use for common users who want to install packages, but it would be the right thing to do, especially if FreeBSD wants more users. Disclaimer: http://www.ose.nl/email ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Unable to upgrade packages on FreeBSD
On Mon, Jan 30, 2012 at 5:49 PM, Polytropon free...@edvax.de wrote: On Mon, 30 Jan 2012 17:04:56 -0500, David Jackson wrote: I wish to use binary packages and I specifically do not want to compile anything, it tends to take far too long to compile programs and would rather install some packages and have it all work right away. That's often true, especially when you're low on resources (CPU speed, disk, RAM). Binary packages are a big time saver and are more efficient. More efficient? Depends. In regards of installation, they're often faster. In regards of spped during operation... well, depends. :-) The binary packages are compiled from the ports sources with the maintainer's default options. Those options might not perform optimal on _every_ imaginable system. That's why compiling from source can make programs run faster when certain optimizations (e. g. specific CFLAGS, selection of CPU at compile time) are applied. Also functionality may increase as the default options may leave something out. A common example is mplayer: When compiled, it can have much more functionality and can even work wonders on old systems. The binary package doesn't give you that. That is true. Well, unless is a problem with cross CPU compatability, all available options should be compiled in by default. Mplayer (or it was some video players) has a huge number of display targets for instance, they can be runtime selected so support for all of them can be compiled in my default and the user can then select which one to use at runtime. I have used video player where you can choose between OpenGL, plain X11, Xvideo, and many other display options and I actually liked having these kinds of runtime choices. A package for these programs can be provided and if a user needs a compile time option they can then spot compile them as needed. Other things to keep in mind are language settings. One example is OpenOffice which needs to have the language setting at compile time, especially if you're not using the english language. You could compile a version of that for each language and I think thats what Ubuntu does, or, just compile maybe top 1 or 2 most commonly used language version and then other versions could be user compiled. Finally, there may be licensing restrictions that forbid the distribution in binary form, or even the distribution through the FreeBSD system. Traditional Java may be seen as an example. This is rare, but it happens. Most programs dont have this problem. a few programs must be compiled like this, it is a lot easier to compile that handful of programs for me than it is to compile the entire system. It should be easy for FreeBSD to make it easy to install the most recent versions of all binary packages, its beyond belief they cannot pull off such a simple ans straight forward, and basic part of any OS. Again, it depends. The options maintainers define as the default are typically okay for the build clusters that process them - they create the binary packages from the ports tree. At some occassions, options and dependencies can take into account things that are already installed, e. g. foo uses bar if bar is installed, but if it's not installed, it fetches and installs baz instead. Just imagine how many packages you would need to map all possible combinations of dependencies present, options set and languages available, and _then_ come up with a naming scheme for the packages. :-) Just compile package for the package download site with all optionals and functionality available. If it has optional dependancies, just install all of the dependancies when the package that needs them is installed. Then user can has all features avialable at runtime. If its an one or the other type option, compile with the most commonly used setting. In many cases they use run time options in programs so this is not as much of an issue in those cases. if people want to make their own compile time options then they can resort to compiling the package themselves. I know it is _partially_ possible, or _has been_ in the past. My famous example here is pkg_add -r de-openoffice to get a full installation of OpenOffice that would work (fully functional) and even bring a dictionary. With the newer versions, this easy approach isn't possible anymore. Just consider X: With or without HAL? With which drivers? A package plus updates for every possible combination? Probably throw in all options at compile time for packages, such as HAL, and then it will be available if people need to use it. If people dont want a component, then they compile on their own. As far as dependancies, the program can be compiled to rely on them and they would be installed automatically when the depending application is installed. Im not sure what HAL does but Ive installed it for X Window System, if it makes it work better, I have no problem with installing HAL
Re: Unable to upgrade packages on FreeBSD
On Wed, Feb 1, 2012 at 3:33 AM, Eduardo Morras nec...@retena.com wrote: At 11:42 31/01/2012, you wrote: While your offer is made with the best of intentions, I doubt the project would feel able take you up on it. The problem is simply one of security -- while crowd-sourcing package compilation would be a pretty sweet technical solution to much of the scaling and resource cost problems, it offers far too much opportunity for people up-to-no-good to be able to introduce trojans, spyware and so forth. No no, i didn't said i will make them manually, i wanted to said that i can add one server amd64 to the pool of automate servers that make the packages, i think it works automatically and distribute workload like boinc or other similar net. About the people which introduce trojans, rootkits etc... i didn't think on that issue and is really a very important stopper. With the rest of your mail, i agree with you, my idea was completly halfthinked (is it the correct word?). That security issue is a serious problem with that idea. I had thought of this idea before and discarded it because its unworkable (the crowd sourcing thing). Mental Note to remember: Beside daemons, there are devils. L __**_ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/**mailman/listinfo/freebsd-**questionshttp://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-** unsubscr...@freebsd.org freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Unable to upgrade packages on FreeBSD
On Tue, Jan 31, 2012 at 12:54 AM, Bernt Hansson b...@bananmonarki.se wrote: 2012-01-31 01:13, freebsd-lists-erik@**erikosterholm.orgfreebsd-lists-e...@erikosterholm.orgskrev: Oh come on, guys. David is the same person who said that FreeBSD was poorly documented. http://osdir.com/ml/freebsd-**questions/2011-12/msg00684.**htmlhttp://osdir.com/ml/freebsd-questions/2011-12/msg00684.html I'll give him the benefit of the doubt a bit longer. I do not. He is a whino. Blocked here from now on. My posts have always been sincere. It would seem to you that anyone who does not agree with you is whining. I would suggest it is you who have an unreasonable attitude. At least respect other people's right to express their views. __**_ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/**mailman/listinfo/freebsd-**questionshttp://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-** unsubscr...@freebsd.org freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Unable to upgrade packages on FreeBSD
On Tue, Jan 31, 2012 at 12:51 AM, Bernt Hansson b...@bananmonarki.se wrote: 2012-01-30 18:52, David Jackson skrev: I have tried endlessly to no avail to upgrade binary the packages on Freebsd to the latest version. I have tried: *portupgrade -PP -a *portmaster -PP -a *pkg_update All fail miserably and totally and have left the system in an unuseable state. What is the error message? They seem to have failed because they couldn't find the package on the download site. Other errors I got were that the package it had downloaded had an unrecognized format. I did not save them, there is really no way to save a copy of them unless I copy them by hand. I will have to rerun the commands to get the error messages and then transfer them by hand. Why can't FreeBSD just make the package system just work. It's already just works It does for you. I've had big problems with it. Right after installing FreeBSD I should be able to type a single command such as update_packages http://www.se.freebsd.org/doc/**en_US.ISO8859-1/books/** handbook/updating-upgrading-**freebsdupdate.htmlhttp://www.se.freebsd.org/doc/en_US.ISO8859-1/books/handbook/updating-upgrading-freebsdupdate.html ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Still having trouble with package upgrades
I still have yet to find a resolution to the problems I have had with binary packages and upgrades on FreeBSD. Binary upgrading is broken with every tool I have tried. There is no real reason why FreeBSD should not provide a facility for users to be able to binary upgrade to the most recent version of all packages with a simple upgrade command. One faulty argument I heard was that it is often not a good idea to upgrade to new software release. The whole purpose of having a release cycle for programs is to provide stable, tested releases for the public to install that will will work properly, and improve upon and fix problems with older releases. This is why mainline release are differentiated from betas and the CVS downloads which are experimental. So you really do want the most recent release, especially for corrections to any security problem. Making upgrades more difficult actually makes the system more insecure by exposing people for a long time to security problems that were fixed in software but making it difficult for people to upgrade. As for the security issues of downloading binary packages. The fact is source packages are not safer than binary packages, more on that in a bit. I am astonished that people here would not realise the obvious, having safe binary installs is do-able from mirror sites, just have the package management software download MD5s from many mirror sites, compare them and test the downloaded package, is they are off, then the package will not be installed the user will be prompted to allow a notification of the problem to be sent to the FreeBSD administrators. The fact is, binary releases are no more dangerous than source releases, someone could just as easily insert bad code in a source code package on a mirror, you need automated MD5 checking anyway, for both binary or source upgrades. So the idea that source upgrades are safer is false, just dead wrong. As for compile options, the solution is simple, compile in all feature options and the most commonly used settings into the binary packages, for the standard i386 CPU. If people want customisations then they can build the software for themselves. A good software philosophy is to allow software to work out of the box with as little configuration as possible, but allow everything to be configured by the user if they want, by shipping software with reasonable defaults which can be overridden by the user. Make simple things easy and complicated things doable. In GUI, by default, complexity can be hidden from users, but if people want fine grain control, they should be free to use advanced screens of the GUI to get complex, fine grained control. In GUI design, more commonly used settings can be provided more upfront while advanced features for use by experts can be placed deeper in advanced or expert screens oft the GUI. Everything should be able to be configured or accomplished by both GUI and CLI and API. A good user friendly model for a useable OS is to allow for binary packages of the entire system to be upgraded with a single upgrade command. It should work out of the box without hassle. Keeping software up to date to recent releases is good practice, remember what I said about the purpose of software releases. make it easy. why dont the freebsd administrators just have a build machine that automatically compiles the software and makes them available as the ports are updated. The user should be able to keep their system up to date without doing any system wide all at once OS-release upgrades at all. There is no reason why kernel and userland programs have to be upgraded at the same time. Especially considering its a good design practice for kernel to provide backward compatability. Instead the system would be piecemeal updated over time, including the kernel, in a piecemeal fashion. The need for system wide OS distribution version numbers like FreeBSD 9.0 is becoming obsolete. Versions are still very valuable for the kernel, but for collections of the entire system software, it has become much less relevant. This was from an age when people would receive a Tape or CD in the mail and update everything all at once, now software can be upgraded in a piecemeal way over time with automatic updates. The CD-based upgrade and all at once system wide upgrades actually for reasons are inferior, in that it meant often months would go by before a software program was updated, delying the application of vital security fixes. Before the age of the internet and the hacker, that may have been acceptable. Its not anymore. With Firefox and Flash for instance, security fixes are made sometimes weekly, with an system wide at once upgrade model, it could be a very long time between upgrades of such software between releases of the OS software distribution CD. The idea of waiting on a FreeBSD kernel release to upgrade firefox is absurd, and the idea that firefox must be upgraded during a kernel upgrade is also absurd. The piecemeal
Re: Still having trouble with package upgrades
On Wed, Mar 7, 2012 at 11:50 AM, tho...@sanbe-farma.com wrote: Hmm what is the problem ? Is there a log or something that you can share ? Usually portsnap, freebsd-update, pkg_add -r or portupgrade that do binary update should be enough Ive tried them all. I will work on getting some logs to post here shortly Regards Sent from my BlackBerry® smartphone from Sinyal Bagus XL, Nyambung Teruuusss...! -Original Message- From: David Jackson djackson...@gmail.com Sender: owner-freebsd-questi...@freebsd.org Date: Wed, 7 Mar 2012 11:28:47 To: freebsd-questions@freebsd.org Subject: Still having trouble with package upgrades I still have yet to find a resolution to the problems I have had with binary packages and upgrades on FreeBSD. Binary upgrading is broken with every tool I have tried. There is no real reason why FreeBSD should not provide a facility for users to be able to binary upgrade to the most recent version of all packages with a simple upgrade command. One faulty argument I heard was that it is often not a good idea to upgrade to new software release. The whole purpose of having a release cycle for programs is to provide stable, tested releases for the public to install that will will work properly, and improve upon and fix problems with older releases. This is why mainline release are differentiated from betas and the CVS downloads which are experimental. So you really do want the most recent release, especially for corrections to any security problem. Making upgrades more difficult actually makes the system more insecure by exposing people for a long time to security problems that were fixed in software but making it difficult for people to upgrade. As for the security issues of downloading binary packages. The fact is source packages are not safer than binary packages, more on that in a bit. I am astonished that people here would not realise the obvious, having safe binary installs is do-able from mirror sites, just have the package management software download MD5s from many mirror sites, compare them and test the downloaded package, is they are off, then the package will not be installed the user will be prompted to allow a notification of the problem to be sent to the FreeBSD administrators. The fact is, binary releases are no more dangerous than source releases, someone could just as easily insert bad code in a source code package on a mirror, you need automated MD5 checking anyway, for both binary or source upgrades. So the idea that source upgrades are safer is false, just dead wrong. As for compile options, the solution is simple, compile in all feature options and the most commonly used settings into the binary packages, for the standard i386 CPU. If people want customisations then they can build the software for themselves. A good software philosophy is to allow software to work out of the box with as little configuration as possible, but allow everything to be configured by the user if they want, by shipping software with reasonable defaults which can be overridden by the user. Make simple things easy and complicated things doable. In GUI, by default, complexity can be hidden from users, but if people want fine grain control, they should be free to use advanced screens of the GUI to get complex, fine grained control. In GUI design, more commonly used settings can be provided more upfront while advanced features for use by experts can be placed deeper in advanced or expert screens oft the GUI. Everything should be able to be configured or accomplished by both GUI and CLI and API. A good user friendly model for a useable OS is to allow for binary packages of the entire system to be upgraded with a single upgrade command. It should work out of the box without hassle. Keeping software up to date to recent releases is good practice, remember what I said about the purpose of software releases. make it easy. why dont the freebsd administrators just have a build machine that automatically compiles the software and makes them available as the ports are updated. The user should be able to keep their system up to date without doing any system wide all at once OS-release upgrades at all. There is no reason why kernel and userland programs have to be upgraded at the same time. Especially considering its a good design practice for kernel to provide backward compatability. Instead the system would be piecemeal updated over time, including the kernel, in a piecemeal fashion. The need for system wide OS distribution version numbers like FreeBSD 9.0 is becoming obsolete. Versions are still very valuable for the kernel, but for collections of the entire system software, it has become much less relevant. This was from an age when people would receive a Tape or CD in the mail and update everything all at once, now software can be upgraded in a piecemeal way over time with automatic updates. The CD-based upgrade
Re: Still having trouble with package upgrades
Many of your issues are non-issues, as your suggestions were implemented in some form long ago. For example, updated applications are compiled and available online. You can use pkg_add -r to install the newest binary package that is available, or you can update your an installed application by updating the ports and using portupgrade, which has options to control whether you compile updates from source or install binary packages. pkg-add -r does not seem to be an upgrade all packages sort of feature I am looking for. I have tried pkg-upgrade, portmaster, and portupgrade, all of these do not work. I am working on getting the logs ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Still having trouble with package upgrades
On Wed, Mar 7, 2012 at 11:58 AM, Polytropon free...@edvax.de wrote: David, allow me to add a few thoughts: On Wed, 7 Mar 2012 11:28:47 -0500, David Jackson wrote: As for compile options, the solution is simple, compile in all feature options and the most commonly used settings into the binary packages, for the standard i386 CPU. I think this can develop into a major problem in certain countries where listening to MP3 is illegal. :-) You are talking about the codec. What Ubuntu seems to do is distribute these codecs as a seperate nonfree addon package which are then loaded by applications at run time. You see, options do not necessarily have to be compiled into programs, they can be loaded at libraries and then loaded by programs at run time if they are available. This is also a rare circumstance, and there are workaround as above. If people want customisations then they can build the software for themselves. That's what they'll do anyway. :-) No, usually they do not. Few people except for hard core geeks want to mess around with compile options. most will use runtime configuration through a GUI which is faster. Especially on systems low on resources, compiling from source is _the_ way to squeeze every required (!) bit of performance out of code. Even if compiling may require some time (due to optimization flags), the result can be really usable. When a new kernel is released, there is no reason to reinstall all of the packages on the system at the same time. Since the kernel and userland packages have different development cycles, there is no reason why there has to be synchronization of the upgrading. It sometimes is neccessary, for example if kernel interfaces have changed. There is some means of compatibility provided by the compat_ ports. But if you start upgrading things, libraries can break, and the system may become unstable (in terms of not being able of running certain programs anymore). Just see how kernel and world are out of sync errors can even cause the system to stop booting. Degrading the inner workings of the OS to just another package can cause trouble. Simple updates as they are often performed on Linux systems can render the whole installation totally unusable because something minor went wrong. :-) A well designed system will provide backwards compatability through various strategies and this does not necessarily need to affect internal software design as the backwards compatability can also be provided by compatability layers and glue code. Programs communicate with the kernel via interrupts, pushing arguments for the system call onto the stack. The format of this closely matches the source code API. The API is used with the system calling convention. These are mostly mature and do not need to change much. Considering it also a bad practice to create an incompatable system API, there is little reason to change the system call interface. The system call interface has little impact on internal kernel except where adding a new feature can require additional kernel code. Most system calls are mature and do not need to change much. If a system call is needed to provide new functionality, a new system call can be added, which can if needed duplicate the functionality of an older system call. There is also ELF and binary code linking and calling conventions. This can also be maintained to be backwards compatability, if necessary through the use of compatability layers and glue in this process. Another strategy that is unlikely to be needed, since there really is not much reason to make non backwards compatable changes to the current system call set, and is only now used for Linux binary compatability is to mark a binary for a certain system call interface, that system call interface can be backed by glue code to the the main kernel interfaces. Other means of communicating with the kernel which are possible include the /proc interface and as as well UNIX domain sockets. Again if the format of these needs to changed in a non backwards compatable way, a new file or socket can be created at a new location for the new version, the old file or socket location would provide the old interface backed by glue code to the new interface. It is possible to provide backwards compatability through compatability layers and glue code like this, without in anyway impacting the internal design of a kernel or other software system. An OS that requires a user to reinstall everything just to upgrade the kernel is not user friendly. Why do consider a user being supposed to mess with kernels? This question can show that I'm already too old: Programs are for users, kernels are for sysadmins. Sysadmins do stuff properly, even if they shoot their foot in order to learn an important lesson. :-) Users have to upgrade the kernel, with a well designed OS this is a process that does not require any sort of problems for the user. Since good
Re: Still having trouble with package upgrades
On Wed, Mar 7, 2012 at 12:42 PM, David Jackson djackson...@gmail.comwrote: Especially on systems low on resources, compiling from source is _the_ way to squeeze every required (!) bit of performance out of code. Even if compiling may require some time (due to optimization flags), the result can be really usable. Again, if you want to customise your software and build it, fine, I am fully supportive of this flexibility and options being available. For many people however the extra effort to do all of this is just not worth it to save a little RAM by not loading library X. I am saying that all features included up to date prebuilt binaries should be avalable, NOT that this should be the only option. I fully support customized port build facility for those that want it. For people who just want a fully functional everything included binary package, then they should be able to use FreeBSDs binary packages. That will in no way affect your ability to compile your ports and i fully suppoert your right to conmpile your ports and configure them so things that you dont need are not compiled in. So it seems like a happy compromise here. You will get what you need and us newbies and other users who really dont want the extra trouble of compiling will get our binaries. Everyone gets what they want and is happy, it seems. I am not dissing or criticising the process of compiling your own ports, if thats what you want, fine, please do. All I am asking for is to be able to use binaries for those who want the binaries and dont want to compile their own stuff. if people dont want to use precompiled stuff, it wont be forced on them, they just compile their own stuff using the ports. I am fine with users having this choice. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Still having trouble with package upgrades
On Wed, Mar 7, 2012 at 12:52 PM, Rob li...@midsummerdream.org wrote: I ran into problems with pkg-upgrade when I upgraded from 8.2p6-9.0-RELEASE, and part of the problem ended up being a tool pkg_upgrade used (uma). That was the reason portupgrade didn't work as well. I ended up hacking the support tool and pkg_upgrade to do what I needed, but they are both definitely broken. iirc, one of the issues with uma was it's url generation. It would generate urls like 9-RELEASE instead of 9.0-RELEASE, the former being the format for 9-STABLE and the later (which I needed) was for an upgrade for a release. Sadly, I've forgotten the other issues, but I remember making about 3 hacks to the tools to get it working. Well, thank you for posting. At least its just not me that seen these problems. For me, binary package updates are completely broken. I wonder how this severe and glaring problem got back FreeBSD engineers. It is such an annoying problem. Why cant they just make things work for people who want binary packages? As it is now, FreeBSD is totally unuseable to me. Rob On 3/7/12 11:05 AM, David Jackson wrote: Many of your issues are non-issues, as your suggestions were implemented in some form long ago. For example, updated applications are compiled and available online. You can use pkg_add -r to install the newest binary package that is available, or you can update your an installed application by updating the ports and using portupgrade, which has options to control whether you compile updates from source or install binary packages. pkg-add -r does not seem to be an upgrade all packages sort of feature I am looking for. I have tried pkg-upgrade, portmaster, and portupgrade, all of these do not work. I am working on getting the logs __**_ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/**mailman/listinfo/freebsd-**questionshttp://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-** unsubscr...@freebsd.org freebsd-questions-unsubscr...@freebsd.org __**_ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/**mailman/listinfo/freebsd-**questionshttp://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-** unsubscr...@freebsd.org freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Still having trouble with package upgrades
This is irrelevant. FreeBSD has these options because most of its users are system administrators, developers or other types of geeks. Serving these needs is a major part of what FreeBSD does. That's why we have the long standing motto: FreeBSD - The power to serve. People who don't want these things, and insist on fool-proof upgrades will probably be happier running Windows, Mac OS X or some distribution of Linux. I've been around email lists long enough to know that every operating system (MS Windows, Linux, etc) occasionally has its update nightmares. My advice to you is: 1. Define your needs. 2. Choose the best software to meet your needs. 3. Choose the best operating system to run the software. 4. Choose the best hardware to run the operating system. If you've performed these steps out of order, you're unlikely to be happy. Andrew You have just now declared complete indifference to and alienated about 99% of the potential user base and their needs, those who could care less about compiling source and messing with compiler options. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Still having trouble with package upgrades
On Wed, Mar 7, 2012 at 2:11 PM, Andrew Gould andrewlylego...@gmail.comwrote: On Wed, Mar 7, 2012 at 12:56 PM, David Jackson djackson...@gmail.com wrote: This is irrelevant. FreeBSD has these options because most of its users are system administrators, developers or other types of geeks. Serving these needs is a major part of what FreeBSD does. That's why we have the long standing motto: FreeBSD - The power to serve. People who don't want these things, and insist on fool-proof upgrades will probably be happier running Windows, Mac OS X or some distribution of Linux. I've been around email lists long enough to know that every operating system (MS Windows, Linux, etc) occasionally has its update nightmares. My advice to you is: 1. Define your needs. 2. Choose the best software to meet your needs. 3. Choose the best operating system to run the software. 4. Choose the best hardware to run the operating system. If you've performed these steps out of order, you're unlikely to be happy. Andrew You have just now declared complete indifference to and alienated about 99% of the potential user base and their needs, those who could care less about compiling source and messing with compiler options. I disagree. I have provided a process for you (or others) to make better decisions regarding the selection of software, operating systems and hardware. How could the developers of any operating system please everyone without watering down the excellent qualities of their creation? It is good that we have so many operating systems from which to choose. This allows operating systems to specialize in their strengths and for users to prioritize their needs. To the extent that you have discussed tools that are broken, I thank you; and I hope you have reported the bugs. I'm sure the tools will be fixed. Every open source operating system is created by developers who decide the direction the operating system will take. The operating system is backed by its own community. When you throw claims about most users not wanting to compile applications from source code, it is clear that you have not taken time to learn about the operating system, its history or the culture of the community. I encourage you to do so. I think that your statement here is fundamentally flawed and wrong, because you have assumed that it is impossible for the OS to be able to be user friendly and geek friendly at the same time. This is wrong. In fact, I have outlined ways repeatedly that FreeBSD could provide an easy to use package system without compromising on the flexibility of ports in any way. The idea that the OS has to be either difficult to use or it has to be easy to use for novices is wrong. The OS can be both and I have written about ways that can be done, in fact, I can show how it can be done in every area. For instance, with better binary packages, those are simply built from ports using the best set of options. Those who want to compile for themselves will still be able to do so, just fine. So you have presented a position here that is simply not true. FreeBSD can be more user friendly and as the same time be flexible and friendly to experts such as yourself. its not an either or choice. Andrew ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Still having trouble with package upgrades
On Wed, Mar 7, 2012 at 2:12 PM, Benjamin Tovar b...@robotoloco.com wrote: On Wed, Mar 07, 2012 at 12:57:46PM -0500, David Jackson wrote: So it seems like a happy compromise here. You will get what you need and us newbies and other users who really dont want the extra trouble of compiling will get our binaries. Everyone gets what they want and is happy, it seems. Yes, this sounds awfully good, except that I think it is much harder than you think. First, some options are mutually exclusive (i.e. ncurses vs slang)... so, maybe there are two, or three versions of the same package... and again, this sounds awfully good, except for the limited and volunteered time of a port maintainer. A happy compromise might be then to have binary packages of popular ports, which is how we have it now. its really not that difficult and this is not an issue tht cannot be dealt with in the default binary package configuration. Both slang and ncurses could be installed and applications could be linked to one or the other. If ncurses is a better choice for instance, it couild be by default linked to that. So if a package has a choice oif being linked to ncurses or slang, then one package will be built, linked to ncurses or whatever is the generally best option and that build of the application will be the binary package. The point i would like to make is, for us to have good binary packages, we dont need to create a different package for every combination of compile time options, but instead compile with the best default set of options. If a user wants more flexibility than that, they are free to compile with ports. the availability of a binary package in no way whatsoever limits the availability of the option to compile a port if the user wants to do that. its not an either or thing. Where two options are mutually exclusive, the best option should be chosen. Where the two options are not mutually exclusive and add a feature or capability to the software, the option can be included. run time configuration settigns should be set to the most reasonable values. Second, and I think this the most important reason, ports put the responsibility of the system on the user. They force you to make decisions on exactly what software is installed. You want the stability and freedom of FreeBSD without this responsibility, and this seems very hard to compromise (e.g., macosx and most linux distributions remove the responsibility by making all these choices for you). Is this newbie friendly? Probably not. Does it need to be? Well, it would be nice if more people use it, but if we remove the responsibility from the user, then it would not be FreeBSD, it would be something else. (Like Debian GNU/kFreeBSD, which sounds like what you are looking for.) The fact is, again, allowing the user to not go into that kind of detail and not mess around with compile time options, does not prevent in any way you from doing so. the OS should be about freedom, Not YOU forcing your ideas about how the system should be used on everyone else. as I repeatedly said, you are free to configure your applications compile to your hearts content, i support you having that freedom.You are the one in fact who has been trying to take away my freedom of not having to mess around with compile options if I dont want to. -- just let users decide if they want to compile port or use pre compiled package for themselves Benjamin Tovar ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Still having trouble with package upgrades
On Wed, Mar 7, 2012 at 4:27 PM, David Brodbeck g...@gull.us wrote: On Wed, Mar 7, 2012 at 10:56 AM, David Jackson djackson...@gmail.com wrote: You have just now declared complete indifference to and alienated about 99% of the potential user base and their needs, those who could care less about compiling source and messing with compiler options. Maybe FreeBSD isn't right for them. It's not meant to be all things to all people. It may be that a different OS would fill your needs better. If so, you should use it! If you're determined to run some kind of BSD UNIX, you should investigate PC-BSD, which is meant to be easier to install and maintain for non-technical users. I actually did try PC-BSD and its not better than FreeBSD. An OS that demands users completely reinstall the operating system just to upgrade is user friendly? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Still having trouble with package upgrades
On Wed, Mar 7, 2012 at 6:51 PM, Polytropon free...@edvax.de wrote: On Wed, 7 Mar 2012 12:05:37 -0500, David Jackson wrote: Many of your issues are non-issues, as your suggestions were implemented in some form long ago. For example, updated applications are compiled and available online. You can use pkg_add -r to install the newest binary package that is available, or you can update your an installed application by updating the ports and using portupgrade, which has options to control whether you compile updates from source or install binary packages. pkg-add -r does not seem to be an upgrade all packages sort of feature I am looking for. I have tried pkg-upgrade, portmaster, and portupgrade, all of these do not work. The portupgrade -PP command should be fine, if your ports tree is up to date. portupgrade -PP did not work for me, it gave me error messages about failed downloads. I am working on getting the logs Those should be interesting. From my own experience, I know there is some software that cannot be easily be updated the binary way, but for most things, it should just work, especially if you keep the default options and have sufficient time. :-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Warning - FreeBSD (*BSD) entanglement in Linux ecosystem
On Mon, Aug 20, 2012 at 10:09 AM, jb jb.1234a...@gmail.com wrote: Hi, here is an interesting comment (basically echoing other people's view) on Linux developments: http://distrowatch.com/weekly.php?issue=20120820 Reader Comments 1 o Arch and systemd (by Microlinux on 2012-08-20 10:11:39 GMT from France) Much has been said on the subject of Systemd. Let me quote Eric Hameleers, one of Slackware's developers. [...] systemd is essentially evil. It is invasive, extremely hostile to other environments, threatening to kill non-Linux ecosystems which have hal, udev, dbus, consolekit, polkit, udisks, upower and friends as dependencies. And every iteration of the software written by the Redhat employees who are responsible for hal, udev, consiolekit, polkit and now systemd are incompatible with previous releases, re-implementing their bad ideas with new bad ideas... basically proving that these Redhat employees must be declared unfit to work on the core of a Linux distro. However, the influence of their employer is so big that these products are forced upon the wider UNIX community and at some point it will be assimilate or die. I hope we (Slackware) will find a way where we do not have to assimilate but still manage to keep the distro working. I have high hopes for KDE which has no Redhat ties and so far, manages to stay clear of this mess, sticking to widely accepted standards. Cheers from a Slackware user. For those of you who are unfamiliar - systemd is a replacement for SysV, LSB, and Upstart init subsystem scripts. Together with some other technologies like GNOME 3 (soon GNOME OS ?) they are aiming at being Microsoft-like Linux distro (soon OS ?). On my FreeBSD machine: $ ls /var/db/pkg/ ... hal-0.5.14_19/ dbus-1.4.14_i3/ consolekit-0.4.3/ polkit-0.99/ upower-0.9.7/ ... Also, once again I refer to Linux-related ports in *BSD ecosystem http://www.freebsd.org/cgi/ports.cgi?query=linuxstype=all and warn against becoming entangled in affairs of Linux ecosystem. jb ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org I will throw in my two cents. Systemd sounds fine to me. I think that having additional features such as event based startup of scripts is something that is okay and not a problem. I think as long as systemd supports SysV init and BSD startup scripts, it is fine. Remember you are free to have your own startup scripts run from systemd. The fact is that systemd is more powerful, its features are available but no one is absolutely required to use every feature. I believe people here would rather complain about it rather than have FreeBSD support it, in the process making FreeBSD better. Instead of making FreeBSD better all they know how to do is criticize OSs that are trying to improve things. I dont think the complaints here have anything to do with a shortcoming of systemd, i think it has to do with people who would rather attack anyone who implements something that is more powerful than what FreeBSD provides, so FreeBSD does not have to compete with a better, more flexible alternative. There is nothing stopping FreeBSD from adding the dependancy system features that are needed by systemd so that FreeBSD can use it. Instead of complaining about Linux implementing something better, why not match it? No one is stopping FreeBSD from implementing its own BSD systemd program. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Warning - FreeBSD (*BSD) entanglement in Linux ecosystem
On Tue, Aug 21, 2012 at 9:20 PM, David Jackson djackson...@gmail.comwrote: On Mon, Aug 20, 2012 at 10:09 AM, jb jb.1234a...@gmail.com wrote: Hi, here is an interesting comment (basically echoing other people's view) on Linux developments: http://distrowatch.com/weekly.php?issue=20120820 Reader Comments 1 o Arch and systemd (by Microlinux on 2012-08-20 10:11:39 GMT from France) Much has been said on the subject of Systemd. Let me quote Eric Hameleers, one of Slackware's developers. [...] systemd is essentially evil. It is invasive, extremely hostile to other environments, threatening to kill non-Linux ecosystems which have hal, udev, dbus, consolekit, polkit, udisks, upower and friends as dependencies. And every iteration of the software written by the Redhat employees who are responsible for hal, udev, consiolekit, polkit and now systemd are incompatible with previous releases, re-implementing their bad ideas with new bad ideas... basically proving that these Redhat employees must be declared unfit to work on the core of a Linux distro. However, the influence of their employer is so big that these products are forced upon the wider UNIX community and at some point it will be assimilate or die. I hope we (Slackware) will find a way where we do not have to assimilate but still manage to keep the distro working. I have high hopes for KDE which has no Redhat ties and so far, manages to stay clear of this mess, sticking to widely accepted standards. Cheers from a Slackware user. For those of you who are unfamiliar - systemd is a replacement for SysV, LSB, and Upstart init subsystem scripts. Together with some other technologies like GNOME 3 (soon GNOME OS ?) they are aiming at being Microsoft-like Linux distro (soon OS ?). On my FreeBSD machine: $ ls /var/db/pkg/ ... hal-0.5.14_19/ dbus-1.4.14_i3/ consolekit-0.4.3/ polkit-0.99/ upower-0.9.7/ ... Also, once again I refer to Linux-related ports in *BSD ecosystem http://www.freebsd.org/cgi/ports.cgi?query=linuxstype=all and warn against becoming entangled in affairs of Linux ecosystem. jb ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org In reference to the claims that systemd developers do not care about portability, this is deceptive and misleading. It implies that he is building in a dependance on intractable hardware platform dependance when this is absolutely not the case, there is no dependance on a hardware platform.There is nothing about systemd that FreeBSD could not easily support. Yes, his software does use system call facilities provided by Linux, but since this is a dependance on software systems, FreeBSD could easily add these facilities to its own libraries and kernel. This fact exposes what the complaints from some people are about, it has nothing to do with portability, because these issues can be easily addressed in software code by FreeBSD, it has to do with FreeBSD not wanting to implement equivalent functionality as Linux. The fact is, FreeBSD can fully support systemd and all kernel and system features, there is nothing here that is impossible for FreeBSD to support. By doing so, it would give users MORE freedom rather than less freedom. FreeBSD would not even be required to use systemd for its own bootup sequence, which can be BSD init scripts still, but, systemd could be made available on FreeBSD, called from FreeBSDs init scripts, for users that wants to use it. Some here would make it seem like it is impossible for FreeBSD to support systemd, nothing could be further from the truth. No one is stopping FreeBSD from implementing it or any other feature found in Linux. I carefully looked through the documentation of systemd, I could see nothing except for a well designed, powerful and flexible start up system that is a major improvement. It IS backwards compatable with SysV and init scripts, so, no one can say they are taking away someones capability to use their own init scripts. BSD could continue to use its own startup init system and optionally allow systemd to be called from this for software that needs systemd. So, FreeBSD does not even have to change much about its current init system to support systemd. systemd could be called from FreeBSDs current init scripts as an addon rather than needing to replace any of the existing init system. I basically cannot see a rational reason to not support it. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Warning - FreeBSD (*BSD) entanglement in Linux ecosystem
On Wed, Aug 22, 2012 at 7:03 AM, Jamie Paul Griffin ja...@kode5.net wrote: [ Michel Talon wrote on Wed 22.Aug'12 at 12:29:56 +0200 ] David Jackson said: In reference to the claims that systemd developers do not care about portability, this is deceptive and misleading. You should read the following interview of Lennart Poettering http://linuxfr.org/nodes/86687/comments/1249943 The amount of hubris and self confidence he deploys is really astounding. I will just quote two extracts: LinuxFr.org : Systemd use a lot of Linux only technologies (cgroups, udev, fanotify, timerfd, signalfd, etc). Do you really think the Linux API has been taking the role of the POSIX API and the other systems are irrelevant ? Lennart : Yes, I don't think BSD is really too relevant anymore, and I think that this implied requirement for compatibility with those systems when somebody hacks software for the free desktop or ecosystem is a burden, and holds us back for little benefit. That sort of shows my point in fact. There is nothing stopping FreeBSD from implementing cgroups, udev, fanotify, timerfd, signalfd, its not like Linux is going to enforce patents on these things, its software, and freebsd can easily add code to support these things, and as well, systemd. You are acting like there is dependancy in systemd on some hardware device you cannot change, this is not true, Software is flexible and can be easily extended and improved, they use some software features provided by the OS, and you clearly can install these features into FreeBSD if you would care to do so. FreeBSD can implement all of the software interfaces to make systemd and other software portable to FreeBSD. So this is clearly not about portability, FreeBSD is free to implement these software interfaces to assure that software is portable to FreeBSD. What this is about is FreeBSDs refusal to implement equivalent functionality as Linux has. On this, FreeBSD has only itself to blame if it refuses to do so, since FreeBSD clearly has the capability to easily add the code necessary. Clearly this is all FreeBSDs politics. It refuses to implement the features because Linux developed because of the animosity towards Linux. FreeBSD has a not made here syndrome. FreeBSD would rather criticize other OSs that are trying to improve their features and flexibility, and power, rather than to improve itself. As for FreeBSDs market share, it is vanishingly small on the desktop with far less uptake than Linux. It is also shrinking in the server area, there is increasingly little reason to use an OS that has worse hardware support, less functionality. Linux is just as reliable as FreeBSD and has more functionality by far. I have been a supporter of FreeBSD for some time, but it was becoming clear that Linux distributions can offer much more and are just as reliable, in addition to offering more capabilities, power and features. all of this has left little reason to keep using FreeBSD. Why use an OS that has less features and capabilities when there are more powerful alternatives with more capabilities that are just as reliable, available? This guy seems to be a real moron. What a ridiculous statement to make. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Problems with FreeBSD assembly
I am having great difficulty running a very simple assembler program on FreeBSD on x86 in my efforts to learn some assembly programming on FreeBSD. I have tried to compile the following with nasm, however i get nothing in response when I attempt to run this program: section .data hello db 'Hello, World!', 0xa hbytes equ $ - hello section .text global _start _start: pushdword hbytes pushdword hello pushdword 1 mov eax,0x4 int 0x80 add esp,12 pushdword 0 mov eax,0x1 int 0x80 nasm -f elf -o hello1s.o hello1.s ld -s -o hello1s hello1s.o ./hello1s prints nothing. What is wrong here? It should print hello world. Thanks in advance for your help, it is greatly appreciated. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Problems with freebsd assembly
I am having great difficulty running a very simple assembler program on FreeBSD on x86 in my efforts to learn some assembly programming on FreeBSD. I have tried to compile the following with nasm, however i get nothing in response when I attempt to run this program: section .data hello db 'Hello, World!', 0xa hbytes equ $ - hello section .text global _start _start: pushdword hbytes pushdword hello pushdword 1 mov eax,0x4 int 0x80 add esp,12 pushdword 0 mov eax,0x1 int 0x80 nasm -f elf -o hello1s.o hello1.s ld -s -o hello1s hello1s.o ./hello1s prints nothing. What is wrong here? It should print hello world. Thanks in advance for your help, it is greatly appreciated. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Problems with FreeBSD assembly
Charlie Kester wrote: On Wed 11 Nov 2009 at 17:32:41 PST Charlie Kester wrote: One more thing: Notice that the system call number (or any other dword) should also be pushed onto the stack before the int 80h. The reason for this is given at the top of the page: although the kernel is accessed using int 80h, it is assumed the program will call a function that issues int 80h, rather than issuing int 80h directly. So the extra dword pushed onto the stack takes the place of the return address from the function the kernel expects to have been called. And since you're not actually using as a return address, it doesn't matter what value it actually has. The kernel doesn't use it for anything; it just expects it to be there in a properly arranged stack frame. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org The push eax is what made it work. So that was the problem. Stdin and stdout do not need to opened before they are used, as in C. Thank you everyone for your help on this, that solved it. Here is the code that works: section .data hello db 'Hello, World!', 0xa hbytes equ $ - hello section .text global _start _start: pushdword hbytes pushdword hello pushdword 1 mov eax,0x4 push eax int 0x80 add esp,16 pushdword 0 mov eax,0x1 push eax int 0x80 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Lockup problems on FreeBSD disks
I have a USB hard drive. Whenever I open two programs which utilise the USB hard drive simultaneously, these programs, i assume when they attempt to write to the hard drive lock up due to what i suspect must be some issue with the USB driver and perhaps a deadlock involving multiple concurrent accesses to the drive. When they attempt to access the drive the programs can lock up for several minutes before being unblocked. When only one program is using the drive this behaviour does not seem to occur. It seems most likely that this is a USB level problem involving the USB drivers. I am using FreeBSD 7.1. It is annoying behaviour to say the least and I wonder what can be done about it, and if this issue is being addressed, perhaps in the recent redesign of the USB code. It seems to be a pretty consistent issue, happening with multiple installs of FreeBSD and different drives. Thank you. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Lockup problems with USB disks
I have a USB hard drive. Whenever I open two programs which utilise the USB hard drive simultaneously, these programs, i assume when they attempt to write to the hard drive lock up due to what i suspect must be some issue with the USB driver and perhaps a deadlock involving multiple concurrent accesses to the drive. When they attempt to access the drive the programs can lock up for several minutes before being unblocked. When only one program is using the drive this behaviour does not seem to occur. It seems most likely that this is a USB level problem involving the USB drivers. I am using FreeBSD 7.1. It is annoying behaviour to say the least and I wonder what can be done about it, and if this issue is being addressed, perhaps in the recent redesign of the USB code. It seems to be a pretty consistent issue, happening with multiple installs of FreeBSD and different drives. Thank you. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Lockup problems with USB disks
I apologise if this was posted more than once, for some reason the emails i sent were not reflected back to me, so i assumed they had not gone through , i checked the archive on the web page and they were there. For some reason some messages are not coming through on my gmail account. David Jackson wrote: I have a USB hard drive. Whenever I open two programs which utilise the USB hard drive simultaneously, these programs, i assume when they attempt to write to the hard drive lock up due to what i suspect must be some issue with the USB driver and perhaps a deadlock involving multiple concurrent accesses to the drive. When they attempt to access the drive the programs can lock up for several minutes before being unblocked. When only one program is using the drive this behaviour does not seem to occur. It seems most likely that this is a USB level problem involving the USB drivers. I am using FreeBSD 7.1. It is annoying behaviour to say the least and I wonder what can be done about it, and if this issue is being addressed, perhaps in the recent redesign of the USB code. It seems to be a pretty consistent issue, happening with multiple installs of FreeBSD and different drives. Thank you. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Lockup problems with USB disks
Thank you. I took a look. I was just wondering if this was a known bug, is it normal, etc. Maciej Milewski wrote: Dnia wtorek 17 listopad 2009 o 15:18:22 David Jackson napisał(a): I have a USB hard drive. Whenever I open two programs which utilise the USB hard drive simultaneously, these programs, i assume when they attempt to write to the hard drive lock up due to what i suspect must be some issue with the USB driver and perhaps a deadlock involving multiple concurrent accesses to the drive. When they attempt to access the drive the programs can lock up for several minutes before being unblocked. When only one program is using the drive this behaviour does not seem to occur. It seems most likely that this is a USB level problem involving the USB drivers. I am using FreeBSD 7.1. It is annoying behaviour to say the least and I wonder what can be done about it, and if this issue is being addressed, perhaps in the recent redesign of the USB code. It seems to be a pretty consistent issue, happening with multiple installs of FreeBSD and different drives. Thank you. I forgot to attach a link with information about this new stack. Some you can find at http://ivoras.sharanet.org/freebsd/freebsd8.html ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: flashplugin
I never had tried to install Linux flash. I did install Windows flash under Firefox on Wine and it worked. I found that the freebsd port for Wine would not work but if I downloaded the source from WineHQ and compiled it would work fine, however, i tried a more recent version of Wine which did not compile right on FreeBSD, my current properly compiled wine version is, 1.1.7. You can try the most recent version of Wine and see if tht works, if not you can try 1.1.7 which worked well for me. David Collins wrote: I have periodically tested with getting flash working, and everytime I try it fails and I go back to undoing everything I have done and re-installing gnash. Gnash works but it does have a few niggles. I tried the following: This is what I did for a 7.2 box. Note that there are compatibility # pkg_info -orx linux linux-stuff # pkg_delete -rx linux # cd /compat/linux # find . -type f -ls # rm -rf * # sysctl compat.linux.osrelease=2.6.16 OVERRIDE_LINUX_BASE_PORT= f10 OVERRIDE_LINUX_NONBASE_PORTS= f10 to /etc/make.conf. # portinstall www/nspluginwrapper # nspluginwrapper -v -a -i * Finally, fire up Firefox and check that it has loaded the flash plugin by typing 'about:plugins' into the URL bar. Find a site with flash content[*], and enjoy. Everything installed easily and about:plugins has Shockwave Flash and FutureSplash Player as enabled. But, when I go to youtube.com all I get a black screen and the video doesn't load. Does anyone have any ideas why flash isn't working? David ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Syinstall binary upgrade to FreeBSD 8.0
I would like to upgrade a 7.1 FreeBSD system to 8.0 FreeBSD using sysinstalls binary upgrade feature. I would mainly for now would like to upgrade the core OS and X and so on, but I still have some 7.1 binaries that will still be on the system. Is there binary compatability with 7.1 binaries on 8.0. Binary compatability is pretty important to me. Anything else i need to know about? As for why I am not using freebsd-update, i did try it once it seemed as though it was going to take 7 hours to update the system., when the old way will have it done in 30 minutes. Thanks in advance. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
