Slashdot Mirror
Diving Into GCC: OpenBSD and m88k
BSD Forums writes "This OnLamp article by Miod Vallat describes how the m88k-specific backend of the GNU C compiler, gcc, was fixed, from the discovery and analysis of the problems to the real fixing work. Since it started with almost zero gcc internals knowledge, it should be understandable by anyone able to read C code, and proves that diving into gcc is not as hard as one could imagine."
How can BSD be dying when it has a mascot like this?! Linux needs to get its act together if it's going to compete with the kind of hot chicks and gorgeous babes that BSD has to offer!
You just can't take Linux seriously when its fronted by losers like these. You Linux groupies need to find some sexy girls like her! I mean just look at this girl! Doesn't she make you hard? I know this little hottie floats my boat! This guy looks like he is about to cream his pants standing next to such a fox. As you can see, no man can resist this sexy little cock teaser. Even this old bearded Unix guru is apparently unable to take his eyes off her!
With sexy chicks like the lovely Ceren you will have people queuing up to buy open source products. Look! This guy can't get in there fast enough with her in the doorway! Come on, you must admit she is better than an overweight penguin! Don't you wish you could get one of these? Join the campaign for more cute open source babes today!
I know it's an example of how to start messing with gcc, but perhaps it would have been better not to use a dead CPU and a dead OS to make the point?
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
if an optimization would break gcc's portability model they could just fork.
...
Surely you forgot the "off"
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
Now that the M88K is extinct, we have gcc 2.95 support for it ;) ... now where did I put that VME box...
Maybe the rain Isn't really to blame. So I'll remove the cause, But not the symptom!
I use openbsd because its hack-proof. They have the security team that every software company wants. i have been using openbsd since version 2.3 and no one has hacked my laptop yet. i feel very safe and secure using this operating system.
m88k processor? is that better than intel p4? If so, how do i upgrade my dell laptop?
The reason i ask is cause i want to be on the leading edge of technology. i dont want to be insecure either. thats why i use openbsd. because i have not been hacked yet on my laptop. its a nice thought to know that no one has accessed my machine from the outside.
i think every machine should run openbsd.
just my $0.02
You want the impossible.
no, he forgat wanted to put "fuck off" instead
So does this mean that we are going to see a new release of mikmod soon?
Is this a POST or a SPOKE?!!!
You say that like there's more than one. There is no "A SPOKE"... there is only "TEH SPOKE".
These should be weekly /. regular-type posts. It's always cool to see someone's thoughts and methods for debugging some of the major tools/libraries that we use pretty regularly. Heck, this might even help someone find that obscure Athlon64 problem (not that one exists, just hypothetical). Remember, dead ARCH doesn't mean anything. The methodology of debugging here would work for any ARCH.
Heck, even finding one of those bugs where you compile for i386 and it works, but compiling for i586 or i686 and it breaking would be kinda cool. I just learned a few things about GCC's build that I didn't know. New info for the day! Huzzah!
-What have you contributed lately?
I love and trust OpenBSD, I really do. Nothing is more secure for a firewall or external server. But if they're not going to use the maintained versions of programs, I have little sympathy for their troubles; these situations have a big "for masochistic hobbyists only" sign all over them.
This is where I stopped reading. This has been "fixed" for a long, long time. If the GCC port is too old and has gone unmaintained, then just maybe it's time to throw it out and start over. The 2.x compiler is dead and buried. Nobody's interested in maintaining it. Patches for it are not going to be accepted.
For those interested in why certain kernel code has to be inlined (under any kernel): early in the boot process, you can't necessarily call functions. There's not enough of a sane stack or relocatable memory. Linux got bitten by this many times, relying on undefined behavior in particular versions of GCC. The choices are either to write one long hairy function, or force inlining.
GCC introduced always_inline for just those situations. Of course, if the users are still trying to get 2.x from years back to work, they won't be able to use it...
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
So why is it Apple can't make a real processor-specific-optimized version of GCC for Mac OS X?
There is no advantage to deviating away from GCC too much because you miss important optimizations in the main GCC trunk. BTW, Apple does have its own GCC tree fine-tuned for Mac OS X - they'd virtually have to as an OS vendor (think device drivers written in GCC 2.95 versus GCC 3.2). Apple would love to merge it back into the GCC main (complete with Objective C++), but the GCC project only accepts very conservative patches generally.
A while back, when I was hacking a new option into the Objective-C compiler (for 2.9.5), I ran into an interesting duality in GCC. Some things are really easy to change, others considerably less so.
The back-end of GCC is pretty cleanly designed, so it's not too hard to change the object code output for a particular processor, or even to add support for a new processor (as long as it's a 32-bit, RISC processor with lots of general purpose registers).
On the other hand, the front end is a mess. Heaven help you if you want to change the parser behavior. Even something as basic as the processing of command-line options is needlessly complicated. The GCC driver program and the C frontend use entirely different code for processing the command line.
Changing the output of the compiler was actually easier than getting the options passed from GCC into the Obj-C frontend so I could actually turn the new behavior on and off.
I even found out that there were several options in our version of GCC that didn't do ANYTHING, since they never actually got passed down to the compiler from the GCC driver.
Someday, I may get motivated to sit down and make a real effort to fix this mess. I wonder if anyone would care?
-Mark
" and proves that diving into gcc is not as hard as one could imagine."
Yeah, right. I'll continue the designs of my thermonuclear weapon using that abacus that I have lying around here.
Moomin
While anti-troll, the post is factually informative.
ROFL that's the best turn-around of the stupid "*BSD is dying" crap! :D
ROCK ON *BSD! WOOOOT!
The v2/v3 ABI changes in gcc *only* affect C++ code. Since Apple's device drivers don't use C++, it's not an issue.
The biggest problem in getting Apple/NeXT patches into GCC is that the gcc steering team is more interested in packing fudge with each other than objective C or non-x86 enhancements. Some Apple stuff does get in (like precompiled headers).
Apple's fork is synced with the main fork every couple weeks or so.
What, did all the m88k people get together during their coffee break and decide they need a free compiler that isn't really any good at all?
Some things - most - don't need to bother.
BWAHAHHAHAH!!!
That roxored me soxors.
You am teh roxor!
LOLOLOL.
No seriously that shit was funny as hell, hehehehahhahah.
Nothing better than working on MS Unix!
don't take the following out of context:
"Notice how CUM, the first parameter, is used unprotected? Guess what happens in the CUM++; statement when CUM happens..."
oh, you filthy little bastards...
I won't dignify your response with URLs refuting your nonsense. Many of Mac OS X's device drivers are written in C++, so what you claim is wrong.
Apple's fork is synced with main - but the opposite is not true - so what's your point?
As far as pre-compiled headers, too bad the GCC steering committee accepted it. It's a really poor implementation.
so, calling odd64() increases your CUM? What do I call to make money fast?
Ummm... Zarathustra?
Wow, that looks pretty simple... BrainFuck back-end here I come!
He succeeded.
Since Apple's device drivers don't use C++,
>>>>>>>>>>>>&g t;
All device drivers that use the I/O kit (that is, most of them) are written in C++, because the I/O kit is C++.
A deep unwavering belief is a sure sign you're missing something...
A couple of years ago, I was trying to write my own little stack-oriented language. I had written an interpreter for it in Turbo Pascal 3.0, an extremely old Pascal compiler. There was some kind of problem with the program, and when I was trying to find the cause, I discovered that just declaring a new variable (without ever using it) solved the problem...
Yetunde Bassey might be. Surprised, that is. As there's nothing in his name to suggest that he's anything but a Christian...
Proof postive, slashdotters are without a doubt the dumbest people on the internet.
go away. jerk.
Informative? Did anyone READ this tripe?
Not a hard task to succeed at.
OpenBSD user ARE morons.
Thanks for the laugh. A good end to a long day.
Mark parent as funny!!!
And that's why the front end was reworked for the GCC 3.x.x compilers. Supposedly they are much cleaner, and tasks like tracking the newest features of standards are easier now.
If tits were wings it'd be flying around.
Um, I don't know if the intent of this post was humorous or trollish but it is pretty clear that it wasn't meant to be informative.
I laughed, so let's call it humor.
ROTFLMAO!!! Thanks for making me smile!
-- "At Microsoft, quality is job 1.1" -- PC Magazine, Nov. 1994
Margialized operating systems require you to jump through more hoops to get things accomplished. Not only do you have to track changes in your operating system, but you have to track changes in unsupported software and emulation libraries. You always have to tweak and use "work-arounds" because your hardware is probably not supported by any vendor.
Things only get more hairy day by day as BSD becomes increasingly marginalized.
Let's make sure that no one ports anything to the next generation of CPUs from Intel or AMD so I can learn GCC too!!
Even though this shows a good starting point at jumping into GCC and ARCH debugging, it completely alienates all the Slashdot readers who don't have a rather high level understanding of how compilers work and the debugging process in general. The author presents a very readable and complete overview of the process he used, which is good. Unfortunately, he doesn't go into any details of why he chose to do what he is doing or the effects of doing it a different way.
This article is only truly accessable to the readers who are already familiar with C and wish to spend at least an hour going over the article and accompanying code. Even then, looking from the comments posted thus far, most readers will still be unable to grasp what is truly going on in the author's head or in the process he uses.
This article does belong in slashdot, but not the front page.
><));>
Boy, they are really scraping the bottom of the barrel to come up with BSD stories. I don't think there has been a real news item in the BSD section for months.
Who knows, but I am sure there is someone who still needs those wierd flags, even if they don't do anything anymore.
No.
I thought this was a troll, but it's WAY too over the top for trolling. This is satire, and it's pretty good.
Subject says it all: BSD is dead
The record is clear on one thing: no operating system has ever come back from the grave. Efforts to resuscitate *BSD are one step away from spiritualists wishing to communicate with the dead. As the situation grows more desperate for the adherents of this doomed OS, the sorrow takes hold. An unremitting gloom hangs like a death shroud over a once hopeful *BSD community. The hope is gone; a mournful nostalgia has settled in. Now is the end time for *BSD.
Christ, folks, if I didn't know better, I'd say you hate *BSD more than you hate SCO.
IT LOOKS LIKE YOUR AN ASSHOLE
the GCC project only accepts very conservative patches generally.
This is probably a good thing for such a crucial project by and large, but it does give rise to frustration among developers (and, historically, the whole egcs and pgcc malarkeys). Perhaps they should make a permanent gcc-unstable branch, to serve the same purpose that egcs did but not just on a temporary basis. That way "risky" patches such as any Apple might submit could go into the unstable tree and gradually find their way into gcc-stable.
"'I pass the test,' she said. 'I will diminish, and go into the West, and remain Galadriel.'"
- JRR Tolkien.
Now, I realize that *BSD is growing less and less popular, but I truly must say that it has always impressed me as being a good system.
I adminster a handful of OpenBSD servers, and they really are a joy to work on; they give me far fewer headaches than any of the Linux distros our clients use. Sure, there are things that frustrate me (especially lack of SMP), but for mission critial applications, I rarely use anything other than OpenBSD.
Also, if *BSD is dying, why did DragonflyBSD only start development back in June?
Maybe I'm an optimist, but I like something to actually work when I need it. (Maybe that explains why I drive a '91 Volvo station wagon)
WTF???
It was EXACTLY as hard as I imagined. It's a good article,and I'm glad it was put up... but the editors need to have a reality check before putting in statements like that.
I thought this was a troll, but it's WAY too over the top for trolling. This is satire, and it's pretty good.
:)
Satire? Seems more like slapstick to me
Miod, you twat, you're making us lesser beings look like fools. I hope you're content of what you achieved.
Wonderful! Very nicely done. There are so many clues to the "parallel-universe" version of OpenBSD you were using! But... did anyone believe it?
I cannot find a single true statement in your post other than the fact that the FSF holds the copyright to GCC. (Why you think that makes a difference escapes me.)
There are many other significant developers other than Red Hat employees. Only a quarter of the current list of maintainers are RH employees. Only a third of the steering committee are RH employees. The last time a RH employee was a release manager was back in the 2.x days, and that person worked for Cygnus.
There have been suggestions -- all rejected -- made to the developers to turn GCC into a more Linux-specific compiler. Come to think of it, those have all been made by VA Linux employees, so if you want ridiculous karma-whoring conspiracy theories, you know where to look for them.
All three of the *BSDs have maintainers which regularly contribute time and patches and computing resources to GCC. None of them have ever needed Red Hat's help to do so.
Perhaps you're (badly, woefully, insanely) confused by the fact that gcc.gnu.org is hosted on a Red Hat network. Believe me, it causes them no end of grief for maintenence. And yet you've never seen a "please click the paypal link to keep this server running" there. This being slashdot, I'm sure there are all kinds of useful suggestions about where else such a machine could be hosted, for free, on a high-speed connection, complete with very talented sysadmins. Anyone? Anyone? No? No.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
Are you saying that the GCC boys are gay? What makes you think that they are a bunch of fruits?
OpenBSD leader Theo states that there are 7000 users of OpenBSD. How many users of BSD are there? Let's see. The number of OpenBSD versus NetBSD posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400 NetBSD users. BSD/OS posts on Usenet are about half of the volume of NetBSD posts. Therefore there are about 700 users of BSD/OS. A recent article put FreeBSD at about 80 percent of the *BSD market. Therefore there are (7000+1400+700)*4 = 36400 FreeBSD users. This is consistent with the number of FreeBSD Usenet posts.
Due to the troubles of Walnut Creek, abysmal sales and so on, FreeBSD went out of business and was taken over by BSDI who sell another troubled OS. Now BSDI is also dead, its corpse turned over to yet another charnel house.
All major marketing surveys show that *BSD has steadily declined in market share. *BSD is very sick and its long term survival prospects are very dim. If *BSD is to survive at all it will be among hobbyist dilettante dabblers. In truth, for all practical purposes *BSD is already dead. It is a dead man walking.
Time to accept reality and move on.
[ed. note: in the following text, former FreeBSD developer Mike Smith gives his reasons for abandoning FreeBSD]
When I stood for election to the FreeBSD core team nearly two years ago, many of you will recall that it was after a long series of debates during which I maintained that too much organisation, too many rules and too much formality would be a bad thing for the project.
Today, as I read the latest discussions on the future of the FreeBSD project, I see the same problem; a few new faces and many of the old going over the same tired arguments and suggesting variations on the same worthless schemes. Frankly I'm sick of it.
FreeBSD used to be fun. It used to be about doing things the right way. It used to be something that you could sink your teeth into when the mundane chores of programming for a living got you down. It was something cool and exciting; a way to spend your spare time on an endeavour you loved that was at the same time wholesome and worthwhile.
It's not anymore. It's about bylaws and committees and reports and milestones, telling others what to do and doing what you're told. It's about who can rant the longest or shout the loudest or mislead the most people into a bloc in order to legitimise doing what they think is best. Individuals notwithstanding, the project as a whole has lost track of where it's going, and has instead become obsessed with process and mechanics.
So I'm leaving core. I don't want to feel like I should be "doing something" about a project that has lost interest in having something done for it. I don't have the energy to fight what has clearly become a losing battle; I have a life to live and a job to keep, and I won't achieve any of the goals I personally consider worthwhile if I remain obligated to care for the project.
Discussion
I'm sure that I've offended some people already; I'm sure that by the time I'm done here, I'll have offended more. If you feel a need to play to the crowd in your replies rather than make a sincere effort to address the problems I'm discussing here, please do us the courtesy of playing your politics openly.
From a technical perspective, the project faces a set of challenges that significantly outstrips our ability to deliver. Some of the resources that we need to address these challenges are tied up in the fruitless metadiscussions that have raged since we made the mistake of electing officers. Others have left in disgust, or been driven out by the culture of abuse and distraction that has grown up since then. More may well remain available to recruitment, but while the project is busy infighting our chances for successful outreach are sorely diminished.
There's no simple solution to this. For the project to move forward, one or the other of the warring philosophies must win out; either the project returns to its laid-back roots and gets on with the work, or it transforms into a super-organised engineering project and executes a brilliant plan to deliver what, ultimately, we all know we want.
Whatever path is chosen, whatever balance is struck, the choosing and the striking are the important parts. The current indecision and endless conflict are incompatible with any sort of progress.
Trying to dissect the above is far beyond the scope of any parting shot, no matter how distended. All I can really ask of you all is to let go of the minutiae for a moment and take a look at the big picture. What is the ultimate goal here? How can we get there with as little overhead as possible? How would you like to be treated by your fellow travellers?
Shouts
To the Slashdot "BSD is dying" crowd - big deal. Death is part of the cycle; take a look at your soft, pallid bodies and consider that right this very moment, parts of you are dying. See? It's not so bad.
To the bulk of the FreeBSD committerbase and the developer community at large - keep your eyes on the real goals. It
[ed. note: in the following text, former FreeBSD developer Mike Smith gives his reasons for abandoning FreeBSD]
When I stood for election to the FreeBSD core team nearly two years ago, many of you will recall that it was after a long series of debates during which I maintained that too much organisation, too many rules and too much formality would be a bad thing for the project.
Today, as I read the latest discussions on the future of the FreeBSD project, I see the same problem; a few new faces and many of the old going over the same tired arguments and suggesting variations on the same worthless schemes. Frankly I'm sick of it.
FreeBSD used to be fun. It used to be about doing things the right way. It used to be something that you could sink your teeth into when the mundane chores of programming for a living got you down. It was something cool and exciting; a way to spend your spare time on an endeavour you loved that was at the same time wholesome and worthwhile.
It's not anymore. It's about bylaws and committees and reports and milestones, telling others what to do and doing what you're told. It's about who can rant the longest or shout the loudest or mislead the most people into a bloc in order to legitimise doing what they think is best. Individuals notwithstanding, the project as a whole has lost track of where it's going, and has instead become obsessed with process and mechanics.
So I'm leaving core. I don't want to feel like I should be "doing something" about a project that has lost interest in having something done for it. I don't have the energy to fight what has clearly become a losing battle; I have a life to live and a job to keep, and I won't achieve any of the goals I personally consider worthwhile if I remain obligated to care for the project.
Discussion
I'm sure that I've offended some people already; I'm sure that by the time I'm done here, I'll have offended more. If you feel a need to play to the crowd in your replies rather than make a sincere effort to address the problems I'm discussing here, please do us the courtesy of playing your politics openly.
From a technical perspective, the project faces a set of challenges that significantly outstrips our ability to deliver. Some of the resources that we need to address these challenges are tied up in the fruitless metadiscussions that have raged since we made the mistake of electing officers. Others have left in disgust, or been driven out by the culture of abuse and distraction that has grown up since then. More may well remain available to recruitment, but while the project is busy infighting our chances for successful outreach are sorely diminished.
There's no simple solution to this. For the project to move forward, one or the other of the warring philosophies must win out; either the project returns to its laid-back roots and gets on with the work, or it transforms into a super-organised engineering project and executes a brilliant plan to deliver what, ultimately, we all know we want.
Whatever path is chosen, whatever balance is struck, the choosing and the striking are the important parts. The current indecision and endless conflict are incompatible with any sort of progress.
Trying to dissect the above is far beyond the scope of any parting shot, no matter how distended. All I can really ask of you all is to let go of the minutiae for a moment and take a look at the big picture. What is the ultimate goal here? How can we get there with as little overhead as possible? How would you like to be treated by your fellow travellers?
Shouts
To the Slashdot "BSD is dying" crowd - big deal. Death is part of the cycle; take a look at your soft, pallid bodies and consider that right this very moment, parts of you are dying. See? It's not so bad.
To the bulk of the FreeBSD committerbase and the developer community at large - keep your eyes on the real goals. It
One more crippling bombshell hit the already beleaguered *BSD community when IDC confirmed that *BSD market share has dropped yet again, now down to less than a fraction of 1 percent of all servers. Coming on the heels of a recent Netcraft survey which plainly states that *BSD has lost more market share, this news serves to reinforce what we've known all along. *BSD is collapsing in complete disarray, as fittingly exemplified by failing dead last in the recent Sys Admin comprehensive networking test.
You don't need to be a Kreskin to predict *BSD's future. The hand writing is on the wall: *BSD faces a bleak future. In fact there won't be any future at all for *BSD because *BSD is dying. Things are looking very bad for *BSD. As many of us are already aware, *BSD continues to lose market share. Red ink flows like a river of blood.
FreeBSD is the most endangered of them all, having lost 93% of its core developers. The sudden and unpleasant departures of long time FreeBSD developers Jordan Hubbard and Mike Smith only serve to underscore the point more clearly. There can no longer be any doubt: FreeBSD is dying.
Let's keep to the facts and look at the numbers.
OpenBSD leader Theo states that there are 7000 users of OpenBSD. How many users of NetBSD are there? Let's see. The number of OpenBSD versus NetBSD posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400 NetBSD users. BSD/OS posts on Usenet are about half of the volume of NetBSD posts. Therefore there are about 700 users of BSD/OS. A recent article put FreeBSD at about 80 percent of the *BSD market. Therefore there are (7000+1400+700)*4 = 36400 FreeBSD users. This is consistent with the number of FreeBSD Usenet posts.
Due to the troubles of Walnut Creek, abysmal sales and so on, FreeBSD went out of business and was taken over by BSDI who sell another troubled OS. Now BSDI is also dead, its corpse turned over to yet another charnel house.
All major surveys show that *BSD has steadily declined in market share. *BSD is very sick and its long term survival prospects are very dim. If *BSD is to survive at all it will be among OS dilettante dabblers. *BSD continues to decay. Nothing short of a miracle could save *BSD at this point in time. For all practical purposes, *BSD is already dead. *BSD is a dead man walking.
Fact: *BSD is dying
Wow, you're rather slow today, so allow Captain Obvious to fill you in:
1. picture of big dick
2. question posed: is it a spoke?
3. hypothesis: "Thus spake Zarasurethra", a play on Zarathustra implying Zara's Urethra
4. this is a reference to the big dick (urethra, aka piss tube)
5. spake=spoke therefore it's a spoke.
Grab a clue stick and beat yourself over the head already.
He may have. Just don't call him Shirley.
Both of the above are probably as significant contributers to GCC as Red Hat. The current release manager is from CodeSourcery, and the big, user visible features in GCC 3.4 are contributed by CodeSourcery (the new C++ Parser) and Apple (pre-compiled headers). And there are a lot of smaller conributors, who combined are more important than any of the big three. This includes the BSD projects.
Cygnus *used* to be the dominating GCC contributor, with about half all patches. However, that was before the egcs fork, which primary purpose was to make it easier for others to contribute. It worked, so while Red Hat now contribute as much as Cygnus used to contribute, other players have entered the game making the playing field more even.
I know that I'm responding to a troll, but someone moderated its lies "interesting", so apparently not everyone has the facts straight.
and Apple is contributing their Obj-C improvements to that branch. There doesn't seem to be any resistance among the main GCC developers to the changes in that branch, but some of the GNUStep people seem less enthusiastic about some of the language changes.
The problem is that the changes in the Apple version of GCC are mixed together and often Apple specific. They need to be seperated, cleaned up, and made generic before inclusion in the main branch. Both Apple and GCC agree that is a good policy, and Apple *is* willing to do the work (because it makes it easier to "track" GCC), and they are doing the work. It just take time.
My reply was to an AC's post that was deleted. But I guess this is what I get for trying to defend BSD users.
1f u c4n r34d th1s u r34lly n33d t0 g37 l41d
I do not agree with the poster of the story that "diving into gcc" is far more easy than you might have thought. ... and its likely also far more the avarage Java geek knows about programming.
Indeed the excellent articel shows HOW HARD it in fact is.
You need a lot of knowledge abiout how a compiler works, and how a processor works and how you can write a program to reproduce the bug.
Thats far more the avarage Python geek, PHP geek or Visual Basic freak knows about programming.
Erm
Also: the article does not give a hint how long the timeframe was for that fix.
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
You're a stupid cocksucker. I think "WOOT" is what people scream when a grizzly bear takes them from behind.
if the article clearly states that *c* is a prerequisite and is about gcc compiler internals on a very specific hardware platform the article is clearly catering for the technical specialist knowlegeable/or interested about such topics. why shouldnt it be on the front page. Since when has the front page been *slashdot for idiots* ?
/. whipper snapper wanting everything NOW ... :)
... hung drawn and quartered before you could even spell slashdot.
...
:)
if you cannot understand *c* or take the time to read and understand the suggested references then do not be surprised the article is unaccessable. Typical young
Dare you *not to do your homework* and post statements like this on the openbsd or gcc usenet forums
RTFM, RTFTB, man gcc(1), read the manual, already faq
Maybe a better suggestion maybe to post a question in the discussion asking for help or for someone to summarize the interesting points. Must use slashdot powers for good, not evil
peterrenshaw ~ Another Scrappy Startup
Margialized operating systems require you to jump through more hoops to get things accomplished. Not only do you have to track changes in your operating system, but you have to track changes in unsupported software and emulation libraries. You always have to tweak and use "work-arounds" because your hardware is probably not supported by any vendor.
Things only get more hairy day by day as BSD becomes increasingly marginalized.
I don't know whats funnier, this post, or the people who didn't get it and modded down.