Red Hat: no desktop products coming
Posted Apr 20, 2008 21:20 UTC (Sun) by nix
In reply to: Red Hat: no desktop products coming
Parent article: Red Hat: no desktop products coming
Why not ?... if costumers what they want is a particular app, why not
offer them what they want and take a small profit out of it ?... if i
remember FOSS philosophy is not opposed to profit...
No, but it is
opposed to distributing closed-source vendors'
code for them
. I'd have thought this would be obvious.
Nuclear facilities and weapon building
Well, the nuke embedded systems are classic examples of vertical apps,
passed around among interested parties (largely by technology transfer and
outright spying). The toolchains that build
those, well, I'd be
surprised to find all of them devoid of GNAT, which is of course free as
in copyrighted by FSF and based on code written by RMS :)
Politics!?... Compiler specifics won't depend of IL, but IL should depend
of compiler specifics, is that it ?
RMS's objection was that a persistent IL in any form would provide an
irresistible temptation to others to provide ways to effectively replace
parts of GCC with non-free software.
He was eventually persuaded that enough other free compilers now exist
that GCC alone cannot prevent this, and that further an IL which is
written with no particular attempt to make it GCC-independent is unlikely
to be used by many non-free GCC-replacers. We shall see if this is
But why can't GCC co-opt something like LLVM which is copyleft BSD ?
Last I looked LLVM's copyright wasn't owned by the FSF (though neither is
ecj, which is now used as GCJ's parser). There is substantial feedback
between LLVM and GCC: some people work on both projects. Co-opting it
whole is probably impractical, the architectures are too different: if you
did that you'd basically end up with LLVM, in which case why not use that
to start with?
But very important to have such kind of infrastructure independent of
language front end and of ISA backend representations IMHO...
Well, duh. Depending on how you look at it, this has been present since
the early 2000s (in the form of tree-ssa and the GENERIC and GIMPLE
representations), or since the start of GCC (in the form of RTL). You
simply can't write a multilanguage or multitarget compiler without some
form of IR.
if that IL is not completely suitable change it...
It's hard to make major changes to an IR once you have dozens of passes
depending on it. e.g. the mem-ssa changes (which were changes to
*representation* not semantics) were really quite difficult and
substantial. Making changes to semantics, particularly the semantics of
something like RTL which is wired into the quasidocumented and
heavily-coupled guts of Ancient GCC, is dramatically harder.
Seems a contradiction. IL should be more important IMHO.
Modular "optimization" much more flexible and practical. LLVM was just an
example. Its not perfect. What is not good about it, could be made much
better in another similar approach... Compiler approaches IMHO are in need
of a serious overhaul.. new ideas!... because the chips that are coming,
and the development models needed are different from the usual... the
clock is ticking, HW manufacturers wont wait for long debates... if FOSS
loses this boat... we'll came to LWN, but with nostalgia...
I'm afraid this makes no sense at all to me. Why would hardware
manufacturers care how code was distributed?
Rereading your older posts in this thread, you seem to be suffering under
the misconception that there's some sort of magic representation we could
use to ship J. Random Unix Program so that it would Just Work, only
faster, on massively multiprocessor systems, GPUs, and so on. This simply
isn't the case. Making programs capable of effective massive
parallelization requires pervasive algorithmic changes: worse, the field
is young, and we don't even know in many cases what the right algorithms
are (e.g. lockless algorithms are obviously preferable to locky ones, but
so far comparatively few lockless algorithms are known, and they're
substantially harder to understand than those that use locks).
It's trivial, in a built-from-source distro like gentoo, to probe hardware
requirements and set compiler flags appropriately (although this is also
largely pointless with GCC on x86 these days thanks
to -march=native, -mtune=generic and friends). But magically turning
single-threaded CPU hogs into multithreaded processes that run on your
graphics card isn't going to happen anytime soon, I'm afraid.
to post comments)