The first release candidate of the next version of FreeBSD’s STABLE branch, FreeBSD 4.10-RC1 has been released. It contains many changes including bugfixes and backported features from the development branch such as enhanced USB support. Get it from a mirror before using the master server. Testers should get their hands on this now as the final release is expected in a couple of weeks.
FreeBSD 4.10-RC1 Released
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Any knows whether the USB driven HP PSC 2100 all in one (Printer/Scanner/Copier) is fully supported by Free BSD. It is supported under Linux for sure, but can anyone tell me whether it works fully with USB under FreeBSD.
Thanks.
For the printing, it’s not so much a question of whether it’s supported by FreeBSD but whether cups/gimp-print. etc support it. I would assume that the printing works under FreeBSD if it does under Linux.
Scanning is a different story as kernel-dependent drivers are usually needed. A large number of scanners do work under FreeBSD, particularly HP ones so I believe your model should be supported. If 4.10 doesn’t support it, try 5.2.1 as development versions contain better driver support.
Thanks Mathew,
Will try it out this weekend and let you’ll know how it goes.
Thats why i made sure i got an hibrid printer of those office combos, since i was spending 400 euros. In Freebsd it uses the lpt and on lunix it uses the USB uhci connection. The scanner bit, its a little more “scary” since i need the linux hpoj drivers (hpoj.sourceforge.net) and they were broken for several time in the ports tree (www.freshports.org/graphics/hpoj) , for several time i could only scan in lunix. The current status of the drivers are ok, and since xsane its a pretty good tool and mixes well with gimp i can now do whatever i do in linux.
I guess that for the past these 2 years what hold me was that option of connecting it via lpt, otherwise my experience with the printer/scanner on freebsd would be null.
An advice to others, before buying any hardware, and if you are going to use it in freebsd do a little research by the model name or else you can end with a dead hardware that will not function with your OS.
Btw
(not following my last advice) anyone got an USB game pad working with xmame in freebsd 5.2.1-RELEASE-p5? a pointer will be thankfull.
Why do they call it a ‘stable’ branch if its the testing branch for patches anyway?
Hi
“backported features from the development branch such as enhanced USB support.”
Becuase it is in general very stable and only meant for including stuff that is in general very stable.
Right here. Some of us have jobs you know. And yes, my arguments stand.
Just a reminder, my thoughts are that it is retarded to backport from one stable branch to another, not from a development branch to a production one, and that all backporting of new untested features is likely to cause instability in monolithic systems like Linux and BSD.
4.10 is using the code from the stable branch, and the last release of that stable branch was 4.9
While 4.10 may be ‘from’ the stable branch, it won’t be ‘the’ stable branch until it is released. Which will be after the release candidates are tested and debugged.
They are backporting from a development branch to a stable branch. The 5.X branch is still development. It’s not considered to be -STABLE, but the 4.X branch is -STABLE.
Although, once things in the development branch seem to be “stable” enough to use in the production branch then they MFC (merge from current) the code into the -STABLE branch. In this case they merged in the USB code. FreeBSD has been doing this for quite awhile now. You don’t need to get your panties in a bunch over it, it’s normal.
This process is how new features and drivers get into the -STABLE branch. They get it production ready in -CURRENT, then move it to -STABLE.
On a similar note, RedHat seems to be doing something similar with the 2.4 and 2.6 kernels. They have been backporting stuff from 2.6 to 2.4 which in my honest opinion is an okay thing. I’m no Linux guru, but the 2.4 kernel has been tried and proven (I guess in the Linux world) therefore, it would make sense to keep using it and bring some of the 2.6 goodies into it. This is something that FreeBSD has been doing and doing quite well. Once again, Linux learns something good from the BSD camp. They should pay attention more often.
I’m well aware of the BSD situation. As to bacporting from one stable branch to another,
here we go again), backporting from the latest stable release to the old one seems a monumental waste of time and effort. Why not just test/use/fix the new current stable branch?
> …backporting from the latest stable release to the old one
> seems a monumental waste of time and effort. Why not just
> test/use/fix the new current stable branch?
The current branch is continuously being tested, used and fixed (I’m running 5.2.1 as I type this). The reason that changes are backported to the older branch is to continue to support systems that require better-tested, time proven code. As for the backporting effort being “monumental”, I disagree. Compared to developing new code for the first time, backporting is relatively simple.
Code from the Linux kernel branches is continuosly being backported between 2.6 and 2.4. In Linux, big new features like SATA support are being backported but FreeBSD takes a more cautious approach by backporting mainly security/stability fixes with the occasional driver update.
> DEVELOPMENT –> STABLE is acceptable with appropriate testing.
> NEW PRODUCTION branch –> OLD PRODUCTION branch is UNPRODUCTIVE.
FreeBSD 4.x is still the stable/production branch. 5.x is the development branch. Occasionally, a release such as 5.1, 5.2 or 5.2.1 is made to give users of the development branch a properly tested “snapshot” if you will.
Didn’t I say something a few posts up about understanding the BSD situation? (*me checks*) Yup. Seems like I did.
Anyhow, I’ve been complaining for the last two days or so about the sillyness with the Linux people. Backporting from 2.6 to 2.4.
2.5 to 2.4 made some kind of sense (new desired features not available in the production branch and all). What they’re doing now is rather braindead, backporting from the new production release to the old one (2.6 to 2.4).
By doing so, they’re not speeding adoption of the new release, they’re not testing the new features as they relate to the new release (therefore not helping to stablize this so called production release), and withevery vendor backporting different features to thier outdated kernels, they’re cleating the Linux equivelent of vendor lock-in, as most Linux users just aren’t capable of adding the patches to the vanilla 2.4 kernel or to that of another distro to give it the same backported funtionality while keeping everything nice and stable.