I stand corrected. I misinterpreted I guess. Oh well.. I just might pick up the design documents, so I won't talk out of my ass next time:)
Another question: how feasible is doing what OS X is doing on XFree wrt using the OpenGL/DRI pipeline to do much of the rendering? I know Evas exists and uses OpenGL, but will one still have the neat client/server stuff?
Direct Rendering is a bit of a misnomer. It still uses the batching mechanism of XFree86, and yes, that's a good thing. The AGP bus on most system is so slow, you wouldn't want to tuoch the bare metal anyway. It's better to have bursts of commands to the graphics hardware in a batched fashion anyway. There are some very good posts about it in this story somewhere. Some explain it better than I can.
But I agree it would be interesting to see what you suggest would do for 2d speed.
I just think the architecture of the project is what's a mess. I compiled the new 4.3 on a Mac yesterday, and I find the project is stuck in an Imake Spin Cycle.
Just because you don't understand how to build XFree86, and think it takes a long time, you claim that XFree itself is flawed?
Hmm, maybe I should stop using FreeBSD then, because compiling world on that takes a very long time and I don't understand all of what exactly happens.
Then you complain about the monolithic nature of the X build process and what you'd like to see happen. Well, the source is there, man. Make it better if you can. I dare you. Impress us. Oh, and while you're at it, split up teTeX as well, it's a whale too.
On the other hand, there are packages (.deb/.rpm/whathaveyou) or (heh) ports/pkgsrc/fink entries for most operating systems. Try installing just the X11 libs from packages, the development headers, the base fonts and the server you need, leave the contrib packages alone, have a coke and a smile, and shut the hell up.
I've seen Keith's code, and it's very tidy and neat (well, neater than the crap I usually pull). He might not like GNU autoconf/automake, I don't either. Just because an application doesn't use GNU autoconf to "aid" in it's build process, doesn't mean the app itself is crap.
ACK. And local sockets are very simple. Effectively slightly slower but almost as fast as direct memcpy calls to video memory. In fact, local sockets _are_ just all memcpy calls to some memory address:) Very fast under many unixen. Heck, we can have client-server and it costs virtually nothing. I say we keep it.
I don't agree with Havoc Pennington on many things (like usability matters), but I do agree with this. Keep the client-server model, it's virtually free (wrt resource costs). The real performance sink is in the rendering of fonts, opengl, window managing, redrawing et al. X11 just needs to catch up with the capabilities of current graphics hardware. There's really not much wrong with it, besides that it lags behind somewhat.
This fork might be just the kick in the arse XFree86 needs to get it up to speed again. Nothing like a little ruckus amongst the developers to get the creative blood flowing again. Go Keith!
(IE 'Our webserving software is Linux' No its apache)
Well, apache is not the be-all end-all of webserving. There are lots of webservers available for the *nix platform that are not based on or related to apache. One notable exception is roxen, although the development activity is a bit shady at the moment. Check freshmeat for more webservers. There are many.
Not only mac 68k's, but also sparcs (not the ultra's) are poorly supported by Linux at the moment. I'm glad I can still run NetBSD on my rickety old sparcstations.
Has anyone reliably got a 2.4 kernel to work on a sun4m lately?
Not for every file in/etc... for some (like resolv.conf for instance) you don't even have to parse that hard. passwd/shadow are easy too (colon delimited), and sendmail.mc isn't the line noise you think it is.
named.conf is pretty easy to parse. If you're unsure, you can always resort to yacc/bison to build a grammar file and build a parser that way. It's ages old, and really not that hard once you've rtfmmed a bit about it. And it's very flexible too.
Same goes for perl. You can do a lot with a well built regular expression. I'd handle the named.conf case by building a regexp that matches one zone, cut and parse everything neatly into a nice data structure (while ignoring whitespace and comments). Then I just regenerate the named.conf from the data I've gathered. Don't whine that that gobbles memory, because an XML parser does basically the same when modifying xml files.
In case of a forwarder entry, no problem, I've done it before, and no, it wasn't hard. I never needed XML to do it. I've done parsers in C too. It's just cutting the data up into convenient chunks and dealing with the data. Since the most basic config files in/etc have a simple structure, parsing them is really really easy.
I can see XML being used to create portable documents, or but I fail to see the use for it regarding simple config files. XML means eXtensible Markup Language, not I Will Build A Kitchen Sink With This language.
Having a standard, structred, text-based, and editable-by-hand-when-necessary format is a godsend. Period.
You mean like most other non-xml config files in/etc, like say hosts, DNS zone files, named.conf, passwd/shadow, hosts.allow/deny, sendmail.mc or resolv.conf (etc. etc.)? These have standard layouts, text-based, can be edited by hand and can be easily parsed.
My point: XML is over-used for a lot of things. In some places it makes sense, but in many places it doesn't.
I have a very selective memory. Passwords do fall through the holes. I can remember a lot, but it seems that my brain uses a lossy compression algorithm to store it, so to keep track of all my passwords on all my systems, I use a plain text file, encrypted with my public key.
I only have to remember one passphrase to get to all my passwords, and I have to have my keychain umass device in the USB port (my private key is stored on that).
I've been using that system for quite some time now, and it works beautifully.
Well, how many systems that use ELF have a/proc fs like Linux? Only one. Your idea might work, but it's not portable. Linux is not the only one with ELF. Most current *nixes and *nix-likes use ELF nowadays.
Using the facilities in ELF to 'group' objects per architecture is a much better. Or bundling, like NeXTSTEP and Mac OS X do, which basically means that binaries for all arches are included, but it uses some OS framework to decide which binary gets run.
I have yet to play with multiplatform ELF binaries, it sounds like an interesting thing to play with. Has anyone out there ever merged binaries for different plaforms together with the framework ELF provides for it?
No, I hate Itanium mostly because it's something Intel wants to shove through our collective throats, and I happen to agree on what Linus says about Itanium when he says that it will be too expensive.
AMD is doing it right. They will have a cheap 64-bit platform for everyone. Of course, Torvalds is paid to like Hammer because his employer licensed the technology, but why would a chip manufacturer like Transmeta license it if it weren't any good?
[snip]
ELF provides a framework in which to define a family of object files, supporting multiple processors and architectures. An important distinction among object files is the class, or capacity, of the file. The 32-bit class supports architectures in which a 32-bit object can represent addresses, file sizes, etc., as in the following.
[snip]
So, basically it's possible with ELF. I don't know about PE. Otherwise, bundling is possible. Just look at Mac OS X/NeXTSTEP, which used fat bins with Bundles.
Well, the industry can always revert to what Apple did if it isn't possible. Make "Fat" executables. ia-64, ia-32 and x86-64 in one executable. Sure, the binaries will be bigger, but with harddisk prices nowadays I don't believe disk space is really an issue:)
I'd hope so for intel that they do this, and yes, it is a bit ironic, I agree.
The AMD x86-64 is the kick in the arse that Intel desperately needs. We all know Linus hates Itanium with a passion too. It's good for competition. Since x86 is almost a commodity, it should be good if Intel adopts somebody else's "standard" for a change. The whole IA-64/x86-64 split reeks a bit of NIH syndrome.
On Windows, I believe DirectSound does software mixing in the kernel....
So does FreeBSD. They have virtual devices in/dev called/dev/dsp.{1..n} (for all the channels), and/dev/dsp just takes which ever one's free. In-kernel sound multiplexing. Is that cool or what. No matter what your desktop uses (arts, esd, whatever) it will always work.
Of course your audio card must support it. One card at least that I know off that can do it are the ESS/Maestro type cards.
Slashdot Mirror
Another question: how feasible is doing what OS X is doing on XFree wrt using the OpenGL/DRI pipeline to do much of the rendering? I know Evas exists and uses OpenGL, but will one still have the neat client/server stuff?
But I agree it would be interesting to see what you suggest would do for 2d speed.
Just because you don't understand how to build XFree86, and think it takes a long time, you claim that XFree itself is flawed?
Hmm, maybe I should stop using FreeBSD then, because compiling world on that takes a very long time and I don't understand all of what exactly happens.
Then you complain about the monolithic nature of the X build process and what you'd like to see happen. Well, the source is there, man. Make it better if you can. I dare you. Impress us. Oh, and while you're at it, split up teTeX as well, it's a whale too.
On the other hand, there are packages (.deb/.rpm/whathaveyou) or (heh) ports/pkgsrc/fink entries for most operating systems. Try installing just the X11 libs from packages, the development headers, the base fonts and the server you need, leave the contrib packages alone, have a coke and a smile, and shut the hell up.
I've seen Keith's code, and it's very tidy and neat (well, neater than the crap I usually pull). He might not like GNU autoconf/automake, I don't either. Just because an application doesn't use GNU autoconf to "aid" in it's build process, doesn't mean the app itself is crap.
[\rant reason="irritated by cluelessness"]
I don't agree with Havoc Pennington on many things (like usability matters), but I do agree with this. Keep the client-server model, it's virtually free (wrt resource costs). The real performance sink is in the rendering of fonts, opengl, window managing, redrawing et al. X11 just needs to catch up with the capabilities of current graphics hardware. There's really not much wrong with it, besides that it lags behind somewhat.
This fork might be just the kick in the arse XFree86 needs to get it up to speed again. Nothing like a little ruckus amongst the developers to get the creative blood flowing again. Go Keith!
In a perfect world, your vision would be useful and yes, I'd vouch for it, but it's a license minefield. :-(
Well, apache is not the be-all end-all of webserving. There are lots of webservers available for the *nix platform that are not based on or related to apache. One notable exception is roxen, although the development activity is a bit shady at the moment. Check freshmeat for more webservers. There are many.
Although there is a port of the FreeBSD nvidia drivers to NetBSD... Lemme dig up the uri...
Ah, here it is:
NVidia drivers on NetBSD
Have fun!
Has anyone reliably got a 2.4 kernel to work on a sun4m lately?
XML is overkill for most stuff that's in /etc
Oh, xml is also great to store general data that would normally be delimited bt tabs or colons, but another poster already commented on that.
Same goes for perl. You can do a lot with a well built regular expression. I'd handle the named.conf case by building a regexp that matches one zone, cut and parse everything neatly into a nice data structure (while ignoring whitespace and comments). Then I just regenerate the named.conf from the data I've gathered. Don't whine that that gobbles memory, because an XML parser does basically the same when modifying xml files.
In case of a forwarder entry, no problem, I've done it before, and no, it wasn't hard. I never needed XML to do it. I've done parsers in C too. It's just cutting the data up into convenient chunks and dealing with the data. Since the most basic config files in /etc have a simple structure, parsing them is really really easy.
I can see XML being used to create portable documents, or but I fail to see the use for it regarding simple config files. XML means eXtensible Markup Language, not I Will Build A Kitchen Sink With This language.
You mean like most other non-xml config files in /etc, like say hosts, DNS zone files, named.conf, passwd/shadow, hosts.allow/deny, sendmail.mc or resolv.conf (etc. etc.)? These have standard layouts, text-based, can be edited by hand and can be easily parsed.
My point: XML is over-used for a lot of things. In some places it makes sense, but in many places it doesn't.
well, the opengl screensavers in kde 3.1 are quite snazzy, yes. :-)
I only have to remember one passphrase to get to all my passwords, and I have to have my keychain umass device in the USB port (my private key is stored on that).
I've been using that system for quite some time now, and it works beautifully.
So, what do you people use?
Using the facilities in ELF to 'group' objects per architecture is a much better. Or bundling, like NeXTSTEP and Mac OS X do, which basically means that binaries for all arches are included, but it uses some OS framework to decide which binary gets run.
I have yet to play with multiplatform ELF binaries, it sounds like an interesting thing to play with. Has anyone out there ever merged binaries for different plaforms together with the framework ELF provides for it?
AMD is doing it right. They will have a cheap 64-bit platform for everyone. Of course, Torvalds is paid to like Hammer because his employer licensed the technology, but why would a chip manufacturer like Transmeta license it if it weren't any good?
From the elf(3) manual page:
[snip]
ELF provides a framework in which to define a family of object files, supporting multiple processors and architectures. An important distinction among object files is the class, or capacity, of the file. The 32-bit class supports architectures in which a 32-bit object can represent addresses, file sizes, etc., as in the following.
[snip]
So, basically it's possible with ELF. I don't know about PE. Otherwise, bundling is possible. Just look at Mac OS X/NeXTSTEP, which used fat bins with Bundles.
Well, the industry can always revert to what Apple did if it isn't possible. Make "Fat" executables. ia-64, ia-32 and x86-64 in one executable. Sure, the binaries will be bigger, but with harddisk prices nowadays I don't believe disk space is really an issue :)
The AMD x86-64 is the kick in the arse that Intel desperately needs. We all know Linus hates Itanium with a passion too. It's good for competition. Since x86 is almost a commodity, it should be good if Intel adopts somebody else's "standard" for a change. The whole IA-64/x86-64 split reeks a bit of NIH syndrome.
This clears up a lot of misconception a lot of people have about the 64 bit platform. Itanium sucks anyway. yay AMD! :)
Yes, so far no problems here with the drivers for nvidia in the FreeBSD ports.
Just a minor nitpick.
So does FreeBSD. They have virtual devices in /dev called /dev/dsp.{1..n} (for all the channels), and /dev/dsp just takes which ever one's free. In-kernel sound multiplexing. Is that cool or what. No matter what your desktop uses (arts, esd, whatever) it will always work.
Of course your audio card must support it. One card at least that I know off that can do it are the ESS/Maestro type cards.
Nah, that's when they open source the windows code base. This is just enough for a snowball fight in hell, if it were ever to happen :)
Maybe he means he's dyslexic (sp?). But hey, I don't see anything wrong with claiming you're a train. It's a free web, after all :)