Currently we have less than 50 percent world-wide Internet penetration, and we have used most of the address space.
Um, no.
Take a look at the IPv4 address space. Over a third of the addresses are still unused.
Now, I understand that this is a result of the stingyness in handing out IPv4 addresses due to the address crunch -- I'm ready for IPv6 to go mainstream, so the/48 I get from freenet6 will be usable -- goodbye silly NAT hacks! -- but the statement that we're nearly out of addresses is untrue.
Yep, radeonfb and friends get it right because BenH sweats bits to make it so -- otherwise open-source 3D wouldn't be possible on any recent Macintosh (it's not possible on the nVidia-chipped Macs in any case).
The amount of voodoo involved in getting three video drivers to get along on all the different versions and revisions of the Radeon is insane. I keep tabs on linux-ppc-devel, the LKML, and from time to time dri-devel. It seems he's tweaking one component or another every week.
A good deal of the point of XGL, once you get past the hype-machine eye-candy business, is that it means only *one* driver for every video card -- a DRI one. Eliminating the dichotomy between the 2D X drivers and the 3D DRI drivers will only improve driver support for both 2D and 3D -- the effort needed to support both will be halfed, and 3D support will be required to support 2D.
There's even been talk about porting the Linux kernel framebuffer drivers to the DRI interface (possibly in userspace, run from initramfs).
Have you ever tried to get an X server, accelerated 3D, and a framebuffer console to get along on the same machine? It's ugly.
Add in multi-monitor support, and you can't even do it. So it's not possible to have all of accelerated 3D, multiple monitors and a console on platforms like the Macintosh that don't have a text mode in hardware.
Jon Smirl was also doing work on DRI/DRM, an area of the Linux video "architecture" that's much in need of love. I'm really sad to hear that he's giving all his video work up -- I was really looking forward to the day the whole Linux video mess got cleaned up for good.
dpkg-reconfigure fontconfig, and choose "yes" when asked about bitmapped fonts.
It's a good idea to install the x-ttcidfont.conf (or whatever it's called) package and follow the directions in/usr/share/doc/x-ttcidfont-conf/README.Debian.
Other than that, I recommend you don't try to understand the font mechanisms, but just try to forget they're there; it's easier that way.
Absolutely, that is your reward, as things stand now. Andrew is saying this isn't enough, and he has good reason to believe so.
AKPM puts out the -mm series of kernels, where major/non-obvious/controversial patches go to get tested before going into the vanilla tree. A lot of the subsystem (ACPI, USB, DRM, etc) maintainers go through Andrew (and -mm) as well, before hitting mainline.
The problem is that -mm isn't getting nearly enough testing. I tracked down and reported a bug that completely broke initrds in one release, *a week after it came out.* There was some grumbling that that particular release didn't boot for somebody, but it was a week before someone picked up on the fact that a major kernel function was completely non-functional. Had I not taken the time to track it down, it might have gone to mainline before someone noticed what was broken. And this isn't the only time things like this have happened.
AKPM is a stand-up kernel maintainer, and a lot of the advances in the way the kernel is being developed have come from him (it *is* an advance; remember what 2.4.11 was like?). When dealing with bug reports, and you know, users, he's wonderfully responsive and easy to work with.
But I don't have the time or inclination to build every -mm release on i386 and ppc like I used to, and he stability of the Linux kernel is suffering for it, not because I'm a great coder (I'm certainly not!) but because -mm is so short of testers that every single one counts.
If there were some more reward for the hours I put in to tracking down some missing #include or just pinning down the symptoms of a bug I'd probably still be doing it. But it just doesn't seem worth my time, and my conscience is clear.
The 'tad faster than Safari' only applies if you have a newer Mac with lots of Mhz, unfortunately. My 500mhz G3 has a fast disk and lots of RAM, and for moderate-to-heavy desktop use can keep up with anything but a G5 for most tasks -- but the CPU-usage difference between Safari and anything Gecko-based is pronounced, just as it was between Moz and Konqueror on my K6-2 450 box 3 years ago. Gecko is a CPU-hog, and always has been.
This is more important on Macs than other platforms, I think, because it's only been in the past couple of years that Macintosh processor speeds have started to approach parity with the i386 PC world. The number of mhz-challenged Macs out there is large; they're only a few years old.
Linux is slowly moving that direction, in a natural-selection sort of way. Initramfs and klibc ("early userspace") will allow things like root-on-nfs and in-kernel DHCP (which arguably shouldn't have been in the kernel in the first place) to move to userspace, but developers are already beginning to talk about using it to put things like partition table parsing and console terminal support into userspace as well. I'd guess that more people will start to see applications for early userspace once it's "complete" and distributions start using it (initramfs is already in the kernel; it's the anomalous rootfs that shows up in/proc/mounts).
Filesystems and the network stack are never going to move to userspace, though; Linus is dead-set against it, for the same reasons he always has been. If you were completely batshit, you could probably convince FUSE to run from initramfs, and get wholly userspace filesystems that way, but FUSE doesn't support any non-network filesystems, AFAIK.
Right, but did IBM have a fast desktop-ish machine available 1 1/2 years ago when Linus acquired his G5? This happened right after Linus moved to OSDL from Transmeta, and it's always seemed suggestive to me.
Yeah, IIRC, Linus switched to a PPC64 box not long after his move to OSDL, and it's definitely had a positive affect on PPC Linux. In 2.4 days, anyone who wanted to build a kernel for their PPC Linux box learned quickly to avoid the mainline kernel -- mainline was the "official" ppc Linux tree, but quite often the releases wouldn't even build on ppc. Everyone (including most of the PPC-specific distributions) worked from the -BENH tree, where ppc-specific problems were quickly fixed, and ppc-specific releases were made. Those patches made it to mainline eventually, but like many of the other ports, PPC was it's own little fiefdom in kernel-land.
Today, you can't even find the -BENH tree. Every mainline release builds on ppc64, and ppc32 tends to need only tiny patches, if any; when PPC breaks, Linus notices, and cares. PPC is a "tier 1" platform.
Some of this is probably due to bitkeeper -- the ppc development tree was kept in bk before even Linus adopted it, so the common infrastructure probably smooths the path of PPC-specific patches into mainline. But the fact is, when ppc64 is broken in mainline, Linus can't work on any other part of the kernel until it's fixed, and every kernel gets built and booted on such a machine before it can become a release. It makes a big difference in the quality of PPC support in Linux.
The way I understood it (from something Alan Cox mentioned in the original LKML thread that started this project), the two big card vendors have so much cross-licenced IP that they're both terrified to even consider making any information public; it would open them up to lawsuits from the other (legitimate, or maybe not so much).
I've had the amd64 (nee x86-64) manuals that AMD is giving away for free on x86-64.org for a while now. I've been waiting for the Opteron and the Athlon64 with anticipation. And part of the deal with amd64 is that, while AMD was defining a new x86-ish ISA, they made some other changes -- like doubling the number of general purpose registers as well as the number of registers available for MMX and SSE.
But these extra registers are only available when using the new amd64 ISA -- i.e. when executing 64 bit code. We've seen lots of benchmarks and tests with the introduction of the Athlon64 running 32 bit windows, but next to none of the amd64 architecture in 64 bit mode.
But this CD boots the amd64 port of Linux, capable of using all 16 GPRs. And it reads like the America's Army version on the CD was compiled 64 bit too -- so it has access to 16 GPRs, 16 MMX and 16 XMM registers instead of the 8 available to standard x86.
It's the first 64bit game available for the Opteron and Athlon64! Somebody needs to go get this CD and benchmark it next to a 32bit x86 version of America's Army. Anyone, anyone?
It seems Alan Cox is considering his -ac kernel tree to be a legitimate alternative to the official "Linus" tree, rather than a playground for testing patches. He's actually perpetuating a difference between -ac and the official tree, in a way that breaks source compatibility between the two (albeit in a very small way.) The fact that RedHat's kernels are all based on -ac now bears this out.
Alan has forked the Linux kernel.
::meyhem::
I think he has Linus' blessing in this though. Reading between the lines, I think Alan has been taking on more and more work in the past year or so that had previously been Linus'. Linux is ten years old now; I suppose Linus is burning out.
And Alan works for RedHat too, which is one of the two distributions that I *know* will be around in ten more years -- they have a solid business plan. Alan is voracious, just tireless, and RedHat would hire the entire core kernel development team if they had to. Linux will not die for lack of a maintainer if Linus gets hit by a bus tomorrow.
I saw this yesterday somewhere, and thought I'd like to try it out, but snes9x.com is down! Anyone know where myself and other interested Slashdotters could get a snes emulator (for Linux of course?)
What is the EFF again? What do they do? What are they doing today?
I find is a bit strange that, given this opportunity to question this fellow (whoever he is) that the/. community chose to use the opertunity as a free legal consultation. It seems mightily selfish.
Thank you, Mr. Kadie, for your efforts and your time.
I've always thought the install failure has something to do with using newer versions of RPM v4.x, such as that shipped with fisher or that included in the install of Nautilus PR3 for RH7. These later versions break up2date and helix-update as well.
What is to become now of the 3dfx opensource effort, given nVidia's anti-opensource leanings? The linux.3dfx.com site is gone, and the placeholder 3dfx.com site explicitly lists nothing for linux drivers.
What has become of the existing code? I know some of it has been merged into the XFree86 trees, but the rest?
It's in the reiserfs FAQ -- this isn't strictly a reiserfs problem, but more a problem with the linux KNFSD (shipped as nfsd in many distribs).
There is a patch to fix this, but unfortunately it is against the -test10 kernel. By 'visual diff'ing the failed hunks, I have a patch that works on 2.4.0. After I test it a few more days, I will post it to the reiserfs mailing list. If you want it, mail me, or keep an eye on the mailing list archive at Namesys.
From what I understand, this patch has been held back from the main reiserfs distrib (and now the kernel proper) because it depends on a feature that is still being debated.
Actually, it's copyright that has to be protected. Patents are good until they expire, whether their owner chooses to enforce them or not. That's why FreeType needs to develop their own system -- Apple could choose to enforce their patents at any time becuse infringing on the patent is illegal.
Still, considering how much Apple has borrowed from the open-source community -- which lends them considerable credit they would do well not to lose -- Apple ethically should leave the well-intentioned and cooperative FreeType group alone.
Hmmm... I wonder, does Microsoft have a license to use Apple's TrueType patents?
Didn't Apple just send cease-and-desist orders to the authors of the various Aqua-like themes for X?
Let me get this straight. Apple uses open-source technology to create a kernel (Darwin) which they ask the community to help develop.
Apple then takes BSD software -- containing large amounts of code that was reverse-engineered from AT&T -- and uses it to create stable underpinnings for their new OS/GUI/coffee-maker.
Apple creates a powerful, sane GUI/windowing system that, while closed-source, may be the alternative to X Windows people have been looking for for 10 years now.
Now Apple attacks the open-source community for infringing on their patents (which they have apparently not bothered to make well known)?! Who's shoulders are you standing on, Apple? Do you really think it's wise to be stirring the shit?
I was looking forward to picking up an iMac to run OS X on (with the Missing Link of course), but if this turns out to be true, I don't know if I can give my money to Apple like that.
I dunno. The URLs at LinuxToday are dynamic somehow -- I've seen them move -- but I can't find the story anywhere. I sincerely hope it doesn't exist.
A few years ago when I took an 'Introduction to Operating Systems' class as a freshman, my classmates and I were given a quick overview of the UNIX shell (using the MKS tools in DOS, ick!) Most of my fellow students hated it; I think they found it too arcane and complex.
I had a background in computer programming, though, and appreciated the richness of the enviroment right away. UNIX is an operating system by programmers, for programmers: its user interface is a programming language!
So you can follow me when I say I think this idea of using pipes in GUIs is just a special case of a bigger question -- how would a visual, GUI based programming language work?
I have often visualized a programming language(?) for GUIs where one could drag & drop elements around to create windows, dialogs, etc. I've never taken the much further than wondering how the actions resulting from activating those elements in the final product would be represented in such a language, i.e., how do you tell the computer what those buttons do without resorting to textual code?
In a way, I guess this is a catch-22 situation, like compiling a compiler -- at some point, somebody has to write the machine code.
Slashdot Mirror
Currently we have less than 50 percent world-wide Internet penetration, and we have used most of the address space.
Um, no.
Take a look at the IPv4 address space. Over a third of the addresses are still unused.
Now, I understand that this is a result of the stingyness in handing out IPv4 addresses due to the address crunch -- I'm ready for IPv6 to go mainstream, so the /48 I get from freenet6 will be usable -- goodbye silly NAT hacks! -- but the statement that we're nearly out of addresses is untrue.
Yep, radeonfb and friends get it right because BenH sweats bits to make it so -- otherwise open-source 3D wouldn't be possible on any recent Macintosh (it's not possible on the nVidia-chipped Macs in any case).
The amount of voodoo involved in getting three video drivers to get along on all the different versions and revisions of the Radeon is insane. I keep tabs on linux-ppc-devel, the LKML, and from time to time dri-devel. It seems he's tweaking one component or another every week.
It shouldn't be that difficult.
A good deal of the point of XGL, once you get past the hype-machine eye-candy business, is that it means only *one* driver for every video card -- a DRI one. Eliminating the dichotomy between the 2D X drivers and the 3D DRI drivers will only improve driver support for both 2D and 3D -- the effort needed to support both will be halfed, and 3D support will be required to support 2D.
There's even been talk about porting the Linux kernel framebuffer drivers to the DRI interface (possibly in userspace, run from initramfs).
Have you ever tried to get an X server, accelerated 3D, and a framebuffer console to get along on the same machine? It's ugly.
Add in multi-monitor support, and you can't even do it. So it's not possible to have all of accelerated 3D, multiple monitors and a console on platforms like the Macintosh that don't have a text mode in hardware.
Jon Smirl was also doing work on DRI/DRM, an area of the Linux video "architecture" that's much in need of love. I'm really sad to hear that he's giving all his video work up -- I was really looking forward to the day the whole Linux video mess got cleaned up for good.
*nods* Their corporate headquarters is in Hilliard now.
Holy Shitballs!
dpkg-reconfigure fontconfig, and choose "yes" when asked about bitmapped fonts.
It's a good idea to install the x-ttcidfont.conf (or whatever it's called) package and follow the directions in /usr/share/doc/x-ttcidfont-conf/README.Debian.
Other than that, I recommend you don't try to understand the font mechanisms, but just try to forget they're there; it's easier that way.
Absolutely, that is your reward, as things stand now. Andrew is saying this isn't enough, and he has good reason to believe so.
AKPM puts out the -mm series of kernels, where major/non-obvious/controversial patches go to get tested before going into the vanilla tree. A lot of the subsystem (ACPI, USB, DRM, etc) maintainers go through Andrew (and -mm) as well, before hitting mainline.
The problem is that -mm isn't getting nearly enough testing. I tracked down and reported a bug that completely broke initrds in one release, *a week after it came out.* There was some grumbling that that particular release didn't boot for somebody, but it was a week before someone picked up on the fact that a major kernel function was completely non-functional. Had I not taken the time to track it down, it might have gone to mainline before someone noticed what was broken. And this isn't the only time things like this have happened.
AKPM is a stand-up kernel maintainer, and a lot of the advances in the way the kernel is being developed have come from him (it *is* an advance; remember what 2.4.11 was like?). When dealing with bug reports, and you know, users, he's wonderfully responsive and easy to work with.
But I don't have the time or inclination to build every -mm release on i386 and ppc like I used to, and he stability of the Linux kernel is suffering for it, not because I'm a great coder (I'm certainly not!) but because -mm is so short of testers that every single one counts.
If there were some more reward for the hours I put in to tracking down some missing #include or just pinning down the symptoms of a bug I'd probably still be doing it. But it just doesn't seem worth my time, and my conscience is clear.
The patch to fix this landed just after FF 1.0 shipped -- grab a nightly build.
The 'tad faster than Safari' only applies if you have a newer Mac with lots of Mhz, unfortunately. My 500mhz G3 has a fast disk and lots of RAM, and for moderate-to-heavy desktop use can keep up with anything but a G5 for most tasks -- but the CPU-usage difference between Safari and anything Gecko-based is pronounced, just as it was between Moz and Konqueror on my K6-2 450 box 3 years ago. Gecko is a CPU-hog, and always has been.
This is more important on Macs than other platforms, I think, because it's only been in the past couple of years that Macintosh processor speeds have started to approach parity with the i386 PC world. The number of mhz-challenged Macs out there is large; they're only a few years old.
Linux is slowly moving that direction, in a natural-selection sort of way. Initramfs and klibc ("early userspace") will allow things like root-on-nfs and in-kernel DHCP (which arguably shouldn't have been in the kernel in the first place) to move to userspace, but developers are already beginning to talk about using it to put things like partition table parsing and console terminal support into userspace as well. I'd guess that more people will start to see applications for early userspace once it's "complete" and distributions start using it (initramfs is already in the kernel; it's the anomalous rootfs that shows up in /proc/mounts).
Filesystems and the network stack are never going to move to userspace, though; Linus is dead-set against it, for the same reasons he always has been. If you were completely batshit, you could probably convince FUSE to run from initramfs, and get wholly userspace filesystems that way, but FUSE doesn't support any non-network filesystems, AFAIK.
Psst -- I hear IBM makes their own hardware.
Right, but did IBM have a fast desktop-ish machine available 1 1/2 years ago when Linus acquired his G5? This happened right after Linus moved to OSDL from Transmeta, and it's always seemed suggestive to me.
Yeah, IIRC, Linus switched to a PPC64 box not long after his move to OSDL, and it's definitely had a positive affect on PPC Linux. In 2.4 days, anyone who wanted to build a kernel for their PPC Linux box learned quickly to avoid the mainline kernel -- mainline was the "official" ppc Linux tree, but quite often the releases wouldn't even build on ppc. Everyone (including most of the PPC-specific distributions) worked from the -BENH tree, where ppc-specific problems were quickly fixed, and ppc-specific releases were made. Those patches made it to mainline eventually, but like many of the other ports, PPC was it's own little fiefdom in kernel-land.
Today, you can't even find the -BENH tree. Every mainline release builds on ppc64, and ppc32 tends to need only tiny patches, if any; when PPC breaks, Linus notices, and cares. PPC is a "tier 1" platform.
Some of this is probably due to bitkeeper -- the ppc development tree was kept in bk before even Linus adopted it, so the common infrastructure probably smooths the path of PPC-specific patches into mainline. But the fact is, when ppc64 is broken in mainline, Linus can't work on any other part of the kernel until it's fixed, and every kernel gets built and booted on such a machine before it can become a release. It makes a big difference in the quality of PPC support in Linux.
The way I understood it (from something Alan Cox mentioned in the original LKML thread that started this project), the two big card vendors have so much cross-licenced IP that they're both terrified to even consider making any information public; it would open them up to lawsuits from the other (legitimate, or maybe not so much).
But this is a 64bit CD!
I've had the amd64 (nee x86-64) manuals that AMD is giving away for free on x86-64.org for a while now. I've been waiting for the Opteron and the Athlon64 with anticipation. And part of the deal with amd64 is that, while AMD was defining a new x86-ish ISA, they made some other changes -- like doubling the number of general purpose registers as well as the number of registers available for MMX and SSE.
But these extra registers are only available when using the new amd64 ISA -- i.e. when executing 64 bit code. We've seen lots of benchmarks and tests with the introduction of the Athlon64 running 32 bit windows, but next to none of the amd64 architecture in 64 bit mode.
But this CD boots the amd64 port of Linux, capable of using all 16 GPRs. And it reads like the America's Army version on the CD was compiled 64 bit too -- so it has access to 16 GPRs, 16 MMX and 16 XMM registers instead of the 8 available to standard x86.
It's the first 64bit game available for the Opteron and Athlon64! Somebody needs to go get this CD and benchmark it next to a 32bit x86 version of America's Army. Anyone, anyone?
OpenNICg t; (which was born out of a thread on k5) already has a .geek TLD. There's no registration charge -- the administrator of the domain will even host your .geek DNS for you if you ask nicely.
/. community isn't more conversant with it, with all the ICANN hate and all.
OpenNIC is a long way from Aunt Tillie-type mainstream exceptance, but I'm surprised the
This is very interesting:l /0108.2/0416.html
http://www.uwsg.indiana.edu/hypermail/linux/kerne
It seems Alan Cox is considering his -ac kernel tree to be a legitimate alternative to the official "Linus" tree, rather than a playground for testing patches. He's actually perpetuating a difference between -ac and the official tree, in a way that breaks source compatibility between the two (albeit in a very small way.) The fact that RedHat's kernels are all based on -ac now bears this out.
Alan has forked the Linux kernel.
::meyhem::
I think he has Linus' blessing in this though. Reading between the lines, I think Alan has been taking on more and more work in the past year or so that had previously been Linus'. Linux is ten years old now; I suppose Linus is burning out.
And Alan works for RedHat too, which is one of the two distributions that I *know* will be around in ten more years -- they have a solid business plan. Alan is voracious, just tireless, and RedHat would hire the entire core kernel development team if they had to. Linux will not die for lack of a maintainer if Linus gets hit by a bus tomorrow.
I saw this yesterday somewhere, and thought I'd like to try it out, but snes9x.com is down! Anyone know where myself and other interested Slashdotters could get a snes emulator (for Linux of course?)
What is the EFF again? What do they do? What are they doing today?
I find is a bit strange that, given this opportunity to question this fellow (whoever he is) that the /. community chose to use the opertunity as a free legal consultation. It seems mightily selfish.
Thank you, Mr. Kadie, for your efforts and your time.
I've always thought the install failure has something to do with using newer versions of RPM v4.x, such as that shipped with fisher or that included in the install of Nautilus PR3 for RH7. These later versions break up2date and helix-update as well.
'Nuff said.
What is to become now of the 3dfx opensource effort, given nVidia's anti-opensource leanings? The linux.3dfx.com site is gone, and the placeholder 3dfx.com site explicitly lists nothing for linux drivers.
What has become of the existing code? I know some of it has been merged into the XFree86 trees, but the rest?
It's in the reiserfs FAQ -- this isn't strictly a reiserfs problem, but more a problem with the linux KNFSD (shipped as nfsd in many distribs).
There is a patch to fix this, but unfortunately it is against the -test10 kernel. By 'visual diff'ing the failed hunks, I have a patch that works on 2.4.0. After I test it a few more days, I will post it to the reiserfs mailing list. If you want it, mail me, or keep an eye on the mailing list archive at Namesys.
From what I understand, this patch has been held back from the main reiserfs distrib (and now the kernel proper) because it depends on a feature that is still being debated.
Actually, it's copyright that has to be protected. Patents are good until they expire, whether their owner chooses to enforce them or not. That's why FreeType needs to develop their own system -- Apple could choose to enforce their patents at any time becuse infringing on the patent is illegal.
Still, considering how much Apple has borrowed from the open-source community -- which lends them considerable credit they would do well not to lose -- Apple ethically should leave the well-intentioned and cooperative FreeType group alone.
Hmmm... I wonder, does Microsoft have a license to use Apple's TrueType patents?
Didn't Apple just send cease-and-desist orders to the authors of the various Aqua-like themes for X?
Let me get this straight. Apple uses open-source technology to create a kernel (Darwin) which they ask the community to help develop.
Apple then takes BSD software -- containing large amounts of code that was reverse-engineered from AT&T -- and uses it to create stable underpinnings for their new OS/GUI/coffee-maker.
Apple creates a powerful, sane GUI/windowing system that, while closed-source, may be the alternative to X Windows people have been looking for for 10 years now.
Now Apple attacks the open-source community for infringing on their patents (which they have apparently not bothered to make well known)?! Who's shoulders are you standing on, Apple? Do you really think it's wise to be stirring the shit?
I was looking forward to picking up an iMac to run OS X on (with the Missing Link of course), but if this turns out to be true, I don't know if I can give my money to Apple like that.
I dunno. The URLs at LinuxToday are dynamic somehow -- I've seen them move -- but I can't find the story anywhere. I sincerely hope it doesn't exist.
A few years ago when I took an 'Introduction to Operating Systems' class as a freshman, my classmates and I were given a quick overview of the UNIX shell (using the MKS tools in DOS, ick!) Most of my fellow students hated it; I think they found it too arcane and complex.
I had a background in computer programming, though, and appreciated the richness of the enviroment right away. UNIX is an operating system by programmers, for programmers: its user interface is a programming language!
So you can follow me when I say I think this idea of using pipes in GUIs is just a special case of a bigger question -- how would a visual, GUI based programming language work?
I have often visualized a programming language(?) for GUIs where one could drag & drop elements around to create windows, dialogs, etc. I've never taken the much further than wondering how the actions resulting from activating those elements in the final product would be represented in such a language, i.e., how do you tell the computer what those buttons do without resorting to textual code?
In a way, I guess this is a catch-22 situation, like compiling a compiler -- at some point, somebody has to write the machine code.