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.
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.
Unfortunately, gcc, by design, will never inline functions (even if explicitly requested) at -O0. The non-return point had been crossed: gcc had to be fixed.
[...]
After compiling gcc 2.95 with gcc 2.8,
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...
I solved the "3) start X and allow login ASAP" problem by taking advantage of the extreme flexibility that the ancient, limping, oh-no-it's-not-a-gui-it-must-die init procedure gives me by moving S90kdm to S21kdm.
1) sounds like gibberish to me, even after reading their site.
2) would be interesting to see.
4) sounds like (1) repeated.
What's the quote? "Those who do not understand Unix are condemmed to reinvent it, poorly."
replacing all mailto: links on our website with something unharvestable (i.e. 'user (at) address'
What makes you think "user at mail dot foo dot com" is unharvestable? The web archives of all the development mailing lists at gcc.gnu.org use that scheme, and we still get spam to unique addresses used only for sending mail to those lists.
It's a handy technique, and useful, but it's certainly not foolproof.
It hasn't been removed. It's a tweakable setting. Turned off, the login screen is sitting there asking for a username/password. Turned on, the login screen says "hit ctrl-alt-del to type in the username and password."
Exactly. They should start off working and get more stable, not start off broken and eventually get fixed. They definitely should not start off working and be broken by backports of k3w1 new features.
When these bugs are fixed, hopefully before the official 2.6.0 release, FIFO support will be readded.
Um, yeah, see... I don't doubt that's exactly what's going through the minds of the kernel developers./Hopefully/ before the official/stable/ release, a major facet of Unix filesystems will be working again. If not, well, nobody would dare criticize the Holy Linux Empire.
This is why the wise man continued to use 2.2 while the "stable" 2.4 was corrupting IDE partitions, until 2.4.2x finally calmed things down. This is why the wise man will continue to use 2.4.2x until 2.6.2x gets all of the killer bugs out -- the ones that should have gotten out before a "stable" release was even rolled.
Don't mind me, this is just my regularly scheduled rant about the spectacularly shitty quality of "get it out the door fast" software, OSS included. Flame on, my reading threshold is set to hard-ignore ACs.
Not any more; God was complaining in #offtopic the other day that His local ISP had really started enforcing the bandwidth caps on cable users. We advised Him to switch the entire heaven.org hookup to DSL, but apparently Gabriel bitches about Q3 ping times whenever the subject comes up.
In relation to another recent weird-science happening:
If you already knew that human beings were doing this kind of thing, by which I mean the spider-goat thing, my hat's off to you. We never heard about this shit until a week ago, which is surprising because when someone squeezes some Goddamn spider silk out of a goat's titty it's the kind of thing one expects to hear about. Industry is clacking its hideous mandibles with excitement over the applications of readily available spider silk, focused largely on the swinging and thwipping sectors of our economy. I'm making goofy jokes about it because I think that we are a young species that often fucks with things we don't know how to unfuck. It's a coping mechanism.
It is, however, nice to know that IBM's fire-breathing legion of IP lawyers is on the side of the GPL.
IBM's destroying legion is not on the GPL's side. They are on IBM's side. The two sides happen to both be opposed to SCO's position at the present time, in a enemy-of-my-enemy-is-my-friend situation. Those situations are not permanent.
I'd actually read the short story before the other two
There's a misunderstanding here. I meant "I had read them in this order," describing past experiences, not "I would read them in this order," making a recommendation. Shame on me for using the contraction there.:-) Does that clear things up?
I actually have no recommendation for the order of reading, other than "once done, loop through them again to pick up the stuff you missed."
This is why my current Dream Operating System [Actually Feasible Variant] is "GNU/Solaris" on UltraSPARC hardware. The Solaris kernel with all of its features, the SPARC hardware with all of its coolness, and the GNU userspace tools.
Alternative to the Solaris kernel, I'd like the Linux kernel but with a sane/dev and/proc.
I could tell you about my current Dream Operating System [Complete Science Fiction Variant], but what would be the point?:-)
A Deepness In the Sky is the prequel to this novel, but was written later. Excellent characters, fascinating plot, really sweet tech. Set only a few thousand years from now.
The reviewer asked about more Tines stories. There's a short story that occurs after both Deepness and Fire but was written first. Actually, it was the very first Zones of Thought story. It's called Blabber, and you can find it published in various Vinge compilations. "The Collected Stories of Vernor Vinge" has it, along with some comments by Vinge on the background.
I'd actually read the short story before the other two, then over the course of time, read the two novels and re-read the short. Wow. Vinge's stuff is chock full o' rereading goodness, meaning you pick up on a lot more on subsequent reads.
...Linux largely wins. The Solaris kernel is much more mature than Linux (instantly earning me a boatload of kneejerk flames on slashdot), but their userspace tools are crap. The desktops shipped with Solaris are ugly and awkward to use, and getting KDE or Gnome to build and run properly can be an exercise in frustration if you're not familiar with Sun's way of doing things.
On the flip side, installing a hundred Solaris boxes is trivial using their JumpStart programs. A new client system RARPs an IP address from the server, downloads a small kernel from the server, NFS mounts a copy of the installation packages from the server, and does a hands-free install. It's extremely flexible and has been ion production use for years. For Linux you're stuck with walking around with CDs, or using some kludge from sourceforge, or a less-well-tested solution like whatever redhat uses.
Along the same lines, Sun's patching utility is designed with remote-boot or diskless clients in mind. You apply the patch once to the directory tree being used, and you're done. Something similar can be done with diskful clients. Linux binary packages mostly assume that the machine is on its own, so each box will want to download from a remote site and store a local copy, leading to atrocious workarounds like an NFS-shared/var/cache.
Honestly, it doesn't make much difference. You'll be writing wrapper scripts and custom
solutions either way. The difference will be in other factors, like cost of hardware or price of support or political games with the rest of the organization.
Having managed groups of both kinds of systems in a production environment for years, I would probably recommend Linux to someone who is asking for recommendations. Not because it's inherently superior, but because you seem more comfortable with it.
My first pencil-and-paper RPG was a Tolkien-based one called MERP. Lots of maps. Lots and lots of maps. I distinctly recall re-claiming the tower in which Frodo was imprisoned.
At least, I think it was him. It's a short story about comm sats which gradually become self-aware. As our information passes through them, they learn from it, helped by other sats which are already "alive" and shepherding them along.
When we think they break down and go offline, it's actually the sat just getting bored and/or frustrated with humanity. They only talk amongst themselves after that point...
...trying to decide how best to help us, and exactly what/how that "help" should mean...
www.fingerworks.com sells a number of products that can be used with one hand. I just switched to a TouchStream keyboard, but that's two-handed. I really like having the entire surface as a mousepad, arrow keypad, special gesture pad, etc.
Switching, of course, is a kick. It's taken me several minutes to type this post.
Re:And the second rule of secure programming club
on
Secure Programming
·
· Score: 1
i don't believe i said that.
i also don't believe there's a point to this conversation. and i've just started usksing a pressure-sensitive touchpad instead of a normal keyboard, so i'm not going ti waste an time startging a flamewar while relearning how to type.
Yeah... I thought the CS community at large mostly knew about this. Okay:
Fortran specifies that Thou Shalt Not Alias, so in the example on the page that you linked to, the function-calling programmer, the function-implementing programmer, and the compiler can all assume that everything refers to non-overlapping memory, and can optimize the hell out of read/write memory accesses.
When Dennis Ritchie designed C, it was a deliberate decision to not prohibit aliasing. (C's ancestor languages may have allowed aliasing as well, and DMR just decided to continue that; I don't actually know. But the question was brought up and considered; it's not an accident.)
When C was first being standardized by ANSI, a
really sloppy proposal was made to add a 'noalias' keyword. It was so bad that DMR sent a public letter to the ANSI committee stating, "noalias must go; this is non-negotiable." So C89 has no way of restricting aliasing.
C++98 and C99 do, sort of. C99 added the __restrict keyword to the language. C++98 left the core language alone and defined a library type, std::valarray, that is free of aliasing by definition, opening up a number of optimization possibilities.
Valarray didn't quite work out; its design is semi-broken. Far more hopeful is using expression templates to expose more of the numerical computations to the compiler, so that more optimizations can be done on visible numbers. Check out Blitz++ at oonumerics.org for an example.
Call me a crazy dreamer, but I believe that's a play on one of his most popular titles, Speaker For the Dead. When/. talks to/about book authors, the "dept" line is almost always a riff on their books... pretty straightforward.
Assuming there aren't comparable features already available in g77, are there plans on eventually implementing similar?
There's already a team of very capable -- and young, not ancient/retired/whatever -- programmers implementing the Fortran 9x language, which defines some really interesting constructs. The current plan is for an initial release as part of 3.5.
Fortran 2000 has a spec, but I don't know of any implementations for it.
As far as "why is it still being used at all" comments, two words for you: no aliasing. The same reason why numerical computation in Fortran continues to chew C's head off.
Slashdot Mirror
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.
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...
I solved the "3) start X and allow login ASAP" problem by taking advantage of the extreme flexibility that the ancient, limping, oh-no-it's-not-a-gui-it-must-die init procedure gives me by moving S90kdm to S21kdm.
1) sounds like gibberish to me, even after reading their site.
2) would be interesting to see.
4) sounds like (1) repeated.
What's the quote? "Those who do not understand Unix are condemmed to reinvent it, poorly."
What makes you think "user at mail dot foo dot com" is unharvestable? The web archives of all the development mailing lists at gcc.gnu.org use that scheme, and we still get spam to unique addresses used only for sending mail to those lists.
It's a handy technique, and useful, but it's certainly not foolproof.
It hasn't been removed. It's a tweakable setting. Turned off, the login screen is sitting there asking for a username/password. Turned on, the login screen says "hit ctrl-alt-del to type in the username and password."
Thank you for telling me. (Although my point about the stability of the Linux kernels stands.)
Exactly. They should start off working and get more stable, not start off broken and eventually get fixed. They definitely should not start off working and be broken by backports of k3w1 new features.
Um, yeah, see... I don't doubt that's exactly what's going through the minds of the kernel developers. /Hopefully/ before the official /stable/ release, a major facet of Unix filesystems will be working again. If not, well, nobody would dare criticize the Holy Linux Empire.
This is why the wise man continued to use 2.2 while the "stable" 2.4 was corrupting IDE partitions, until 2.4.2x finally calmed things down. This is why the wise man will continue to use 2.4.2x until 2.6.2x gets all of the killer bugs out -- the ones that should have gotten out before a "stable" release was even rolled.
Don't mind me, this is just my regularly scheduled rant about the spectacularly shitty quality of "get it out the door fast" software, OSS included. Flame on, my reading threshold is set to hard-ignore ACs.
Not any more; God was complaining in #offtopic the other day that His local ISP had really started enforcing the bandwidth caps on cable users. We advised Him to switch the entire heaven.org hookup to DSL, but apparently Gabriel bitches about Q3 ping times whenever the subject comes up.
In relation to another recent weird-science happening:
from Penny Arcade
Also, something to keep in mind...
IBM's destroying legion is not on the GPL's side. They are on IBM's side. The two sides happen to both be opposed to SCO's position at the present time, in a enemy-of-my-enemy-is-my-friend situation. Those situations are not permanent.
There's a misunderstanding here. I meant "I had read them in this order," describing past experiences, not "I would read them in this order," making a recommendation. Shame on me for using the contraction there. :-) Does that clear things up?
I actually have no recommendation for the order of reading, other than "once done, loop through them again to pick up the stuff you missed."
This is why my current Dream Operating System [Actually Feasible Variant] is "GNU/Solaris" on UltraSPARC hardware. The Solaris kernel with all of its features, the SPARC hardware with all of its coolness, and the GNU userspace tools.
Alternative to the Solaris kernel, I'd like the Linux kernel but with a sane /dev and /proc.
I could tell you about my current Dream Operating System [Complete Science Fiction Variant], but what would be the point? :-)
A Deepness In the Sky is the prequel to this novel, but was written later. Excellent characters, fascinating plot, really sweet tech. Set only a few thousand years from now.
The reviewer asked about more Tines stories. There's a short story that occurs after both Deepness and Fire but was written first. Actually, it was the very first Zones of Thought story. It's called Blabber, and you can find it published in various Vinge compilations. "The Collected Stories of Vernor Vinge" has it, along with some comments by Vinge on the background.
I'd actually read the short story before the other two, then over the course of time, read the two novels and re-read the short. Wow. Vinge's stuff is chock full o' rereading goodness, meaning you pick up on a lot more on subsequent reads.
...Linux largely wins. The Solaris kernel is much more mature than Linux (instantly earning me a boatload of kneejerk flames on slashdot), but their userspace tools are crap. The desktops shipped with Solaris are ugly and awkward to use, and getting KDE or Gnome to build and run properly can be an exercise in frustration if you're not familiar with Sun's way of doing things.
On the flip side, installing a hundred Solaris boxes is trivial using their JumpStart programs. A new client system RARPs an IP address from the server, downloads a small kernel from the server, NFS mounts a copy of the installation packages from the server, and does a hands-free install. It's extremely flexible and has been ion production use for years. For Linux you're stuck with walking around with CDs, or using some kludge from sourceforge, or a less-well-tested solution like whatever redhat uses.
Along the same lines, Sun's patching utility is designed with remote-boot or diskless clients in mind. You apply the patch once to the directory tree being used, and you're done. Something similar can be done with diskful clients. Linux binary packages mostly assume that the machine is on its own, so each box will want to download from a remote site and store a local copy, leading to atrocious workarounds like an NFS-shared /var/cache.
Honestly, it doesn't make much difference. You'll be writing wrapper scripts and custom solutions either way. The difference will be in other factors, like cost of hardware or price of support or political games with the rest of the organization. Having managed groups of both kinds of systems in a production environment for years, I would probably recommend Linux to someone who is asking for recommendations. Not because it's inherently superior, but because you seem more comfortable with it.
My first pencil-and-paper RPG was a Tolkien-based one called MERP. Lots of maps. Lots and lots of maps. I distinctly recall re-claiming the tower in which Frodo was imprisoned.
At least, I think it was him. It's a short story about comm sats which gradually become self-aware. As our information passes through them, they learn from it, helped by other sats which are already "alive" and shepherding them along.
When we think they break down and go offline, it's actually the sat just getting bored and/or frustrated with humanity. They only talk amongst themselves after that point...
...trying to decide how best to help us, and exactly what/how that "help" should mean...
www.fingerworks.com sells a number of products that can be used with one hand. I just switched to a TouchStream keyboard, but that's two-handed. I really like having the entire surface as a mousepad, arrow keypad, special gesture pad, etc.
Switching, of course, is a kick. It's taken me several minutes to type this post.
i don't believe i said that.
i also don't believe there's a point to this conversation. and i've just started usksing a pressure-sensitive touchpad instead of a normal keyboard, so i'm not going ti waste an time startging a flamewar while relearning how to type.
Read Niven's A World Out Of Time (multiple meanings in the title) for a similar idea. It's one if his first "State" books.
SPOLIERS BELOW
Basically, something else gets dropped into Jupiter. And there's some fascinating ideas on how to move a planet around.
Here, I'll sum up EVERY SINGLE RELEASE for you:
Yeah... I thought the CS community at large mostly knew about this. Okay:
Fortran specifies that Thou Shalt Not Alias, so in the example on the page that you linked to, the function-calling programmer, the function-implementing programmer, and the compiler can all assume that everything refers to non-overlapping memory, and can optimize the hell out of read/write memory accesses.
When Dennis Ritchie designed C, it was a deliberate decision to not prohibit aliasing. (C's ancestor languages may have allowed aliasing as well, and DMR just decided to continue that; I don't actually know. But the question was brought up and considered; it's not an accident.)
When C was first being standardized by ANSI, a really sloppy proposal was made to add a 'noalias' keyword. It was so bad that DMR sent a public letter to the ANSI committee stating, "noalias must go; this is non-negotiable." So C89 has no way of restricting aliasing.
C++98 and C99 do, sort of. C99 added the __restrict keyword to the language. C++98 left the core language alone and defined a library type, std::valarray, that is free of aliasing by definition, opening up a number of optimization possibilities.
Valarray didn't quite work out; its design is semi-broken. Far more hopeful is using expression templates to expose more of the numerical computations to the compiler, so that more optimizations can be done on visible numbers. Check out Blitz++ at oonumerics.org for an example.
Shouldn't the kernel be wiping pages when it hands them to new processes?
Hmmm... possibly not. This is a topic of some debate, apparently.
Call me a crazy dreamer, but I believe that's a play on one of his most popular titles, Speaker For the Dead. When
There's already a team of very capable -- and young, not ancient/retired/whatever -- programmers implementing the Fortran 9x language, which defines some really interesting constructs. The current plan is for an initial release as part of 3.5.
Fortran 2000 has a spec, but I don't know of any implementations for it.
As far as "why is it still being used at all" comments, two words for you: no aliasing. The same reason why numerical computation in Fortran continues to chew C's head off.