They don't have to release the source of the modified GCC, but they do have to release the binary.
i really dont think they do; read your GPL, if you release binary code, you have to supply a means of getting the source code. but to hit your argument at the base... the fact is, they don't even need to provide binaries for the modified gcc. it is being used "in house" and there is therefore no need to redistribute the changes. (remember, gcc is not provided to the end user in the router firmware)
i have heard these quotes before; but since 2.6.x is on its way, i noticed that the kernel (and glibc) can have Native POSIX Threads support, which apparently run much faster than before. does anyone know if/why the kernel teams views have changed? and if, as the name suggests, we are indeed getting POSIX compatible threads?
Re:LSB or POSIX, it really doesn't matter, because
on
LSB & Posix Conflicts
·
· Score: 1
GNU Hello is pure bloat; no wonder it can't follow ANSI C standards. It can take five options, and it has a feature to output your mail spool. Why?!
i hope you are aiming for a funny moderation... because if not, you have missed the point of this program!
often, the best way to learn something is by example; the GNU auto* tools, internationalisation, localisation and overall package maintenence hierarchy/structure is all documented in this package extremely well. in fact, its only purpose is to serve as a a guidance for people who dont want to reinvent the wheel with these things, and just want to get stuck into writing their program.
there are ANSI standards, and there are POSIX standards, they are different. is there a standard for the exact path and command line arguments to a c compiler or linker? not that i am aware of...
the C code itself may be standardised, but often the build environment is not. that is what the GNU tools help you sort out. add to that, the immense need to translate programs to non-english speaking countires and you find yourself needing soemthing like the GNU precedures for that as well (unless you'd care to write your own, which distracts you from your coding...)
yes, i have a radeon and i am running with 3D acceleration: you are confusing drivers and DRI/DRM. You also are thinking you have to use the binary ATI drivers from their site... which are rubbish and nobody uses them. Use the XFree86 native drivers instead.
the driver just does all the 2D and normal screen stuff (i belive 2D acceleration is in here). if you want 3D acceleration however, you use the DRI/DRM system. all this means in reality is that (for the DRI part) you add
Load "glx"
Load "dri"
to the "Modules" section of your XFree86 config file.
for the DRM part, all you need do is make sure you have the kernel module loaded. it must be the XFree86-4.3 one, not the vanilla kernel module [it must be built against your kernel and with the same c compiler as your kernel... but if you use a distro they will ensure that is all correct.]
so, in short; add those lines to your config file (when using the radeon driver). in fact, if the distro is set up correctly, you wont even need to do any of this as it will do it all for you during the install... and all will "just work";-)
The trick to installing mplayer is to use an RPM-based distro
yes, my GNU/Linux from Scratch distro is da-bomb at RPM stuff... *cough* (goes away to use xine which was built from source and has no playback problems whatsoever...).
people on this thread are comparing apples and oranges; they are comparing different versions of xine-lib on different platforms and wondering why one is more stable than the other. it is quite obvious that a more recent bug-fixed version will be more stable. if your distro's install method is screwy; it is your distros fault, not the xine peoples. they release source only. i dont think they even _officially_ support RPMs either (most people dont).
the trick to watching most formats is to ensure that you have the binary codecs installed. although, having said that, i am getting by on ffmpeg these days...
i fail to see how any of these supposed disadvantages of CVS applies to the linux kernel source tree... i hardly think private/public trees is an issue and "Advanced Merging Features" is a bit fague... also i think "atomic commits" are silly as they are an extra overhead: if you are on a publically viewable CVS system you should never commit a file unless everything else will agree with it. i.e. if you commit an abi change, only commit it after you have changed everything to use the ABI. if anything i think cvs helps stop lazyness in this regard.
i am still awaiting enlightening as to how CVS is failing... thanks anyway for the link!
please tell me! it's good enough for *BSD, mozilla and pretty much every other free project out there. as far as i see it, all linux needs is versioning, a history archive and different branches (linus', ac etc and a submissions tree). this is not a troll, i really do want to know what bitkeeper can do that CVS cannot!
don't you just love it when some smartass needs a comment explained to them:
all readers of/. are geeks, right? geek watch star wars... in fact, for the certain age group (which i fall into), we GREW UP with star wars as our favourite movie... to not know that X, Y, B and A wings are already in the original movies is blasphemy!!
why do you assume i am american? unable to click on a user link?
uhh... well if MODERN day slackware 9.0 didnt run on modern machines i'd wonder about what the hell was going on!!!! the grandparent was blatently talking about the one in the article.
no, people complain because the developers listen! granted, some people are not very polite about it, and the developers of any GNU project will just ignore them.
often, bug reports look like a load of winging... unless you have been on the receiving end of bug reports, you will never know that they are a GOOD thing! (its easy to read a bug report with a grumpy cynical voice in your head). you WANT to know exactly how something is breaking and when, so you can fix it quickly and make it better... unless of course, you are just in it for the money and don't give a shit about the quality.
native POSIX threads (needs to be enabled in the glibc with an adon package, and probably all packages recompiled against it..., but) look here if you fancy setting it up yourself. i've heard of unbelieveable speedups on threaded code using this library, which will not work on a 2.4.x kernel.
how the hell did this get modded up??? EVERY well-informed linux user on the planet, ESPECIALLY slashdotters, know that x.EVEN.z releases are stable, x.ODD.z are development, and the transition from an odd to even release is entirely stability related. therefore, there will be NO new major revamps of core components (hopefully) unless an emergency comes up... like the 2.4.8 vfs fiasco.
damn right... im glad `make menuconfig` is staying in, i was actually getting worried that its support was getting ripped out entirely! i heard rumours, but i never actually tested 2.5.x so i couldnt confirm them. phew! well, in hindsight, the rumours were stupid and i was a fool for even considering them to be true: who in their right minds would require a GUI library to build the kernel:-/
well, in south africa, they call floppies "stiffies". you have no idea how afraid i was to ask for a stiffy from the woman behind the counter when i was there...
Re:Gnumeric is ok, but not THAT hot
on
Gnumeric Turns 5
·
· Score: 1
it should, but i've had mixed success. but come to think of it, i did "source ~/.profile", when like you say, i should be POSIX compliant and do a ". ~/.profile" because the SUN/bin/sh is a POSIX shell, not bash. hmm... sam goes off to remove the giggery pokery form his recursive setup...
is this not what zISO is anyway? the linux kernel can handle this transparently, and i think knoppix uses it.
this is nothing new...
Re:Gnumeric is ok, but not THAT hot
on
Gnumeric Turns 5
·
· Score: 1
not on all systems, (i find at least on solaris and generic gnu/linux) that.xsession is only sourced by the system file, so it doesnt matter what the first line has. unless of course you add "#!/bin/sh -l" to the top of the system file (a hack, and its what i do on machines i can); but not everyone has root access, so on my user-only machines i "exec bash --login.another_file" in my.xsession which is the jiggery pokery i mean...
Slashdot Mirror
i really dont think they do; read your GPL, if you release binary code, you have to supply a means of getting the source code. but to hit your argument at the base... the fact is, they don't even need to provide binaries for the modified gcc. it is being used "in house" and there is therefore no need to redistribute the changes. (remember, gcc is not provided to the end user in the router firmware)
i have heard these quotes before; but since 2.6.x is on its way, i noticed that the kernel (and glibc) can have Native POSIX Threads support, which apparently run much faster than before. does anyone know if/why the kernel teams views have changed? and if, as the name suggests, we are indeed getting POSIX compatible threads?
i hope you are aiming for a funny moderation... because if not, you have missed the point of this program!
often, the best way to learn something is by example; the GNU auto* tools, internationalisation, localisation and overall package maintenence hierarchy/structure is all documented in this package extremely well. in fact, its only purpose is to serve as a a guidance for people who dont want to reinvent the wheel with these things, and just want to get stuck into writing their program.
there are ANSI standards, and there are POSIX standards, they are different. is there a standard for the exact path and command line arguments to a c compiler or linker? not that i am aware of...
the C code itself may be standardised, but often the build environment is not. that is what the GNU tools help you sort out. add to that, the immense need to translate programs to non-english speaking countires and you find yourself needing soemthing like the GNU precedures for that as well (unless you'd care to write your own, which distracts you from your coding...)
damn, i just fed a troll, didnt i? :-/
i can't believe how many people replied to this with serious advise...
is that for real? or is it the obligatory intentional-typo ;-)
the driver just does all the 2D and normal screen stuff (i belive 2D acceleration is in here). if you want 3D acceleration however, you use the DRI/DRM system. all this means in reality is that (for the DRI part) you add
to the "Modules" section of your XFree86 config file.
for the DRM part, all you need do is make sure you have the kernel module loaded. it must be the XFree86-4.3 one, not the vanilla kernel module [it must be built against your kernel and with the same c compiler as your kernel... but if you use a distro they will ensure that is all correct.]
so, in short; add those lines to your config file (when using the radeon driver). in fact, if the distro is set up correctly, you wont even need to do any of this as it will do it all for you during the install... and all will "just work" ;-)
yes, my GNU/Linux from Scratch distro is da-bomb at RPM stuff... *cough* (goes away to use xine which was built from source and has no playback problems whatsoever...).
people on this thread are comparing apples and oranges; they are comparing different versions of xine-lib on different platforms and wondering why one is more stable than the other. it is quite obvious that a more recent bug-fixed version will be more stable. if your distro's install method is screwy; it is your distros fault, not the xine peoples. they release source only. i dont think they even _officially_ support RPMs either (most people dont).
the trick to watching most formats is to ensure that you have the binary codecs installed. although, having said that, i am getting by on ffmpeg these days...
Uranus has rings AND moons
it's funny, laugh!
i am still awaiting enlightening as to how CVS is failing... thanks anyway for the link!
please tell me! it's good enough for *BSD, mozilla and pretty much every other free project out there. as far as i see it, all linux needs is versioning, a history archive and different branches (linus', ac etc and a submissions tree). this is not a troll, i really do want to know what bitkeeper can do that CVS cannot!
dont forget the perpetual motion machine!
all readers of /. are geeks, right? geek watch star wars... in fact, for the certain age group (which i fall into), we GREW UP with star wars as our favourite movie... to not know that X, Y, B and A wings are already in the original movies is blasphemy!!
why do you assume i am american? unable to click on a user link?
how can you be on /. and not know the answer to this question as if it were the only thing you were taught as a child!!!! :-|
uhh... well if MODERN day slackware 9.0 didnt run on modern machines i'd wonder about what the hell was going on!!!! the grandparent was blatently talking about the one in the article.
often, bug reports look like a load of winging... unless you have been on the receiving end of bug reports, you will never know that they are a GOOD thing! (its easy to read a bug report with a grumpy cynical voice in your head). you WANT to know exactly how something is breaking and when, so you can fix it quickly and make it better... unless of course, you are just in it for the money and don't give a shit about the quality.
native POSIX threads (needs to be enabled in the glibc with an adon package, and probably all packages recompiled against it..., but) look here if you fancy setting it up yourself. i've heard of unbelieveable speedups on threaded code using this library, which will not work on a 2.4.x kernel.
meta-moderators, you know what to do...
i still use `make oldconfig` between kernel updates, but if you are using `make config`, then god help you!! :-D
damn right... im glad `make menuconfig` is staying in, i was actually getting worried that its support was getting ripped out entirely! i heard rumours, but i never actually tested 2.5.x so i couldnt confirm them. phew! well, in hindsight, the rumours were stupid and i was a fool for even considering them to be true: who in their right minds would require a GUI library to build the kernel :-/
no ways; Fishburne would be RMS!!! what about all that religous sheeat going down in Zion... all hail the emacs which will save us...
He calls floppies "tapes".
well, in south africa, they call floppies "stiffies". you have no idea how afraid i was to ask for a stiffy from the woman behind the counter when i was there...it should, but i've had mixed success. but come to think of it, i did "source ~/.profile", when like you say, i should be POSIX compliant and do a ". ~/.profile" because the SUN /bin/sh is a POSIX shell, not bash. hmm... sam goes off to remove the giggery pokery form his recursive setup...
this is nothing new...
not on all systems, (i find at least on solaris and generic gnu/linux) that .xsession is only sourced by the system file, so it doesnt matter what the first line has. unless of course you add "#!/bin/sh -l" to the top of the system file (a hack, and its what i do on machines i can); but not everyone has root access, so on my user-only machines i "exec bash --login .another_file" in my .xsession which is the jiggery pokery i mean...