Submitted by The second beta of FreeBSD 7 has been released. “The 7.0-BETA2 builds have completed and are on many of the FreeBSD mirror sites. If you want to update an existing machine using cvsup use RELENG_7 as the branch tag. Instructions on using FreeBSD Update to perform a binary upgrade from FreeBSD 6.x to 7.0-BETA2 will be provided via the freebsd-stable list when available.” Additionally, there’s a discussion on supporting a subset of c++ in the FreeBSD kernel.
I haven’t tried FreeBSD in years and thought I’d give this a go. Sadly the installer dies at some point with a signal 11.
Looks like I’ll have to wait for another beta before I give this a go again!
If you were trying an OS out for the 1st time in years then wouldn’t it have made more sense to install a stable release?
Nothing wrong with trying a beta. Send them a bug report plz! I hope pc-bsd moves to 7.0 asap!
Edited 2007-11-05 23:52
Funny, I’ve found FreeBSD 7 beta2 to be an order of magnitude better than beta1 — on my amd64 box during the beta1 phase a simple startx would print a memory access error, drop to the standard console which was turned green.
A make buildworld to beta2 fixed this, without even rebuilding xorg.
Did you use beta 1 or 2?
I started from scratch when beta 1 came out and had no troubles at all.
7 is running fine, did a buildworld and buildkernel and build up my system with the ports and all runs fine.
The only drawback is not having a compatible driver from Nvidia so I can’t tell for sure if SCHED_ULE does make the system feel more responsive compared to SCHED_4BSD. Graphic performance is too slow with the nv driver. 🙁
“I haven’t tried FreeBSD in years and thought I’d give this a go. Sadly the installer dies at some point with a signal 11.”
This could be interesting for the FreeBSD developers, as long as you can assert that there’s no hardware failure (e. g. defective RAM) causing such an error. If other OSes run fine, FreeBSD should, too – in most cases.
“Looks like I’ll have to wait for another beta before I give this a go again!”
You’re stating it: It’s a beta, not a RELEASE. If you’re new to FreeBSD and want to have something tested, you should first use something from the -RELEASE branch, for example the latest 6-RELEASE (6.2). In most cases, a beta has some problems. This is what it’s used for. 🙂
I installed FreeBSD7 very quickly, all went through fine.
Even had Lighttpd w/PHP5-cgi up within about 10minutes or so.
Seemed to be running great.
I’ll keep testing for other bugs of course, but so far so good.
I’m really looking forward to this release, especially with the improvements with MySQL.
The post mentions a proposal for the use of a subset f C++ (or K) http://wiki.freebsd.org/K
Before speaking of the evils of compiler dependency and pushing yourself out of the reach of programmers, I’d be interested in the reasons why they think plain and standard C is not good enough?
If its access to things like kernel data structures libraries like linked lists and queues then there’s nothing wrong with a “collections” abstraction in C. There’s also a danger that OS design follows the proposed K/C++ metaphors – minimising metaphors is better for OS evolution.
I think I disagree with every point you made =P
First, plain C *is* good enough, as is any Turing-complete language. The point here is how to do it in a way that is less error-prone.
Some ways to make code less error-prone are by writing less code, making it easy to express ideas bearing higher levels of abstraction, and by enforcing reusability of code you know is both correct and efficient. And macros can only go so far. It’s entirely possible to write object-oriented code in plain C, but it’s just not convenient. At all. Ugh.
What they’re going after resembles a lot the research on aspect oriented programming(*), in that you enlist the shielding requirements of a given piece of code, and just write the code and letting the compiler environment take care of the work. The prime example here is locking: if C directly supported the monitor locking model, most locking problems wouldn’t exist. The fact that you must deal with it by hand causes errors and makes you spend a lot of effort on repetitive, almost boilerplate-like code that you must customise a little bit for every different situation.
The sheer mechanics of such tasks lead to subtle errors: forgetting to unlock on the right place, double locking, double unlocking, inverting locking order, not having a mechanism to release locks held by “rogue” processes… I could spend whole pages discussing those problems.
All in all, I believe that the ideal solution would be some bytecode, register-based, JIT-compiled scripting language that can be easily modified (read: instrumented) on symbolic form during runtime. If this sounds dangerously close to LISP or Lua (actually the Metalua variant) to you, you’re spot on. The downside of those two is that the latter is different enough fom C to warrant justified arguments about barrier-to-entry and learning curves (despite the fact that Lua is probably the easiest-to-learn programming language I’ve ever encountered), and the former is different enough from everything else to warrant revisiting the remarks I made about Lua, only a thousand times worse.
But if leaving the job of producing kernel-oriented machine code to a JIT compiler gives you the creeps, an alternative would, again, write a customised preprocessor in Lua (which is small enough to make part of a compiler toolchain, and its interface to C is second to none) that takes the linguistic constructs they’re after, and produces annotated C code afterwards, with all the plumbing in place (and for the love of God don’t suggest preparsing the sources with Yacc/Lex, not this day and age!). It would make expressing stuff like shared areas very easy, while producing compilable code that uses the API that’s already in place.
(*) And seeing how Sun made it with DTrace, I think my suggestion is no way far off from reality. WTF, they wrapped self-modifying code on a C-like scripting language!
Edit: typo, and brought the points about Yacc/Lex (I still have bad dreams about these two =P)
Edited 2007-11-06 03:33
Replying myself:
That is, assuming that, for various reasons, they won’t go C++. RAII is a mighty powerful idiom for resource management.
Brilliant message on the benefits of C++:
http://lists.freebsd.org/pipermail/freebsd-arch/2007-October/007003…
Before speaking of the evils of compiler dependency and pushing yourself out of the reach of programmers, I’d be interested in the reasons why they think plain and standard C is not good enough?
Pushing out of the reach of programmers? Sounds like pretty poor programmers! While C++ is certainly “meatier” than C, it’s not going to be pushing any competent developer away.
I haven’t yet read their article, but C tends to be suitable for low level systems programming, while C++ is more suitable for high level applications programming. The fact that they are considering it, tells me that the want (not need, but want) a higher level of abstraction. Namely objects. You can do OO programming in C, but so what? You can do OO programming in assembly! You use C++ because it makes the OO easier!
Read up on Apple’s C++ subset and their driver framework; there are a few things which Apple do right – especially in the highly technical area, its sad that other projects don’t take advantage of these opensource components.
Atleast if the BSD’s stanardised on the I/O Kit (http://en.wikipedia.org/wiki/I/O_Kit) it would also reduce the barrier for driver writers – and the bonus of having an elegant driver API as a cherry ontop.
Edit: Although the above was probably so far off topic, it isn’t funny – the main point I was trying to get at is this; lets stop the C++ hate. What I see is the hate spread by those who either have never used it or when they have used it, they’ve done so in such a bad manner it gives nightmares.
I’ve dabbled in C and C++ (and funny enough found that C++ was easier to learn/understand than VisualBasic). To blame the language for the stupidity of the programmer is short sighted at best.
Edited 2007-11-06 04:23
They’re not avoiding C++ for the (hypothetical) ugliness of it, but for
1) the potential for misusing language features;
2) the availability of suitable compilers for whichever architectures FreeBSD may support. Specifically, PHK seems to be wary of depending on a GPLv3 compiler.
Now, 2) is a much more of a political than technical decision, but it is theirs to make. 1) is really about education; aside from the danger of falsely believing some clever C++ trick actually works on kernel-land as well as it does on user-land, some C++ code is a joy to read, while some is like having your wrists slit by a rusty blade, while actually imploring to have your eyes slashed out (by said rusty blade).
*shivers*
the ghc team released a upgrade two days ago to address the gcc4 issues that were keeping the code out of the 7x ports tree. please please let it make the release! i want to upgrade but i have lots of little programs i wrote in haskell that i cannot go without