Well, I switched to Debian (potato) just recently, and I couldn't be happier. Having used RH for as long as I can remember, I was very impressed by Debian's attention to detail. The security setup, for example--/dev/fd0 is chown'ed to root.floppy with mode 660, so if I want floppy access, I just have to add myself to group "floppy." Similar for "adm" (if I want to read logs), "disk" (if I want raw access to/dev/hd?), "dialout" (if I want to use the serial ports or ISDN devices).
The review dumps on the install, but that was no big deal. If you've been using Linux for more than a year, and bash doesn't scare you, neither will dbootstrap. (Btw, I have to agree that dbootstrap looks like FreeBSD's installer-- almost exactly. They do say Debian is the most BSD-like of the distros...)
Oh, yeah, and apt-get/dpkg are sweet. They are very intelligent, almost dauntingly so. Debian's package system keeps a lot of state about packages going in and out. Just yesterday, I wanted to upgrade Esound from the normal "esound" version to "esound-alsa," and the process was something like this:
dpkg -i esound-alsa.deb (can't do; conflicts with esound)
dpkg -r esound (can't do; several packages depend on esound)
dpkg -i esound-alsa.deb (hmmm, esound is being considered for removal, and esound-alsa also satisfies the dependency for those packages, so install it)
There was probably a better way to do that, but that it could do that sure threw me for a loop. One thing I don't like about dpkg is that it doesn't index files; if you're used to doing rpm -qf <file> a lot, then you'll have to switch to dpkg -S <file> and waiting for the package manager to search for which package the file belongs to, usually taking a few seconds (whereas rpm does it instantly).
One other pet peeve was that no binary Pine/Pico.deb is available (where apt-get can get at it), but that's because of license restrictions (Pine disallows distributing modified binaries). This was annoying, but it made me think about the licensing. I was going to try following the steps to build a Pine.deb, but instead, I think I'm going to give Mutt a try. It'll probably be better in the long run. (Oh, and nano is better than pico anyway;-)
If you're an idealistic-in-thought/pragmatic-in-practice guy like me, Debian's non-free section is nice, in that it reminds you what software doesn't quite meet the ideals that spawned the whole thing. Nothing obtrusive, just a tiny reminder...
Anyway, I'm very happy with my new Debian system. The extensive testing really shows, and makes the system feel much more solid than your typical RH setup. If Linux is just Linux to you, then it's no big deal, but if you want to build your system into perfection, Debian is probably the best starting point. I'm well on my way;-)
VA is currently working on an XFree4.0 driver for the new Radeon cards. It's being developed under contract from ATI themselves, it'll use the DRI, and it'll be open-source.
Check out the adjacent article on Tom's, about the Radeon. It performs slightly slower than the GeForce in 16-bit mode, and at lower resolutions, but at high-res 32-bit modes the Radeon edges out the GeForce.
The GeForce numbers may be impressive, but me, I'm going to wait until the Radeon driver is ready. And then I'm going to show ATI just how much I appreciate an open solution.
I looked around the site, but couldn't find the magical PDF files. I don't suppose they'd link those in from the brochureware pages.
Just how much in the way of specs are they releasing? Does it go above and beyond the 2D core? Will people actually be able to write full OpenGL drivers for this thing without an NDA?
Because, if ATI really is being that open with the specs, the beauty of it is that everyone who's been burned by NVidia not releasing theirs will finally have the chance to hit them where it counts: by moving to a competitor's product.
The Radeon looks awesome, and if a level of support for it similar to that of the G400 can come around, Linux and a whole host of non-x86 systems will finally have an open path to cutting-edge 3D support!
Aye, and it can produce absolutely second-to-none-quality documents with almost no effort. All the formatting can be encoded into templates. Also, you have pdfTeX, so DVI isn't the only target format available.
As others have mentioned, there's some issues with industry support, popularity with programmers, etc. Considering FP in an open-source context, however-- where the tools are free and languages like Scheme are alive and kicking-- there are still technical issues that make for abnormally high activation energy.
(These points apply to some variants of Haskell and ML I investigated a while back. I don't remember specifics, but these were the salient observations that resulted):
For one, the compilers are incredibly complex beasts. This wouldn't be so bad, if they weren't so ambitious as to generate native binaries themselves. Myself, I'm leery of anything that generates native machine code, that doesn't use a GCC backend. Maintaining a native code generator is a lot of never-ending work (machine architectures evolve constantly) and IMHO, not using GCC for that is a lost cause, in the long term.
More significantly, if the compiler's native code generator is the only way to get a native binary, you're basically requiring users to go through a MAJOR hassle (installing a full-blown compiler) just to run your program non-interpreted, if at all.
(If you want to know what I mean, try building the CVSup program-- written in Modula3-- from scratch. I almost had to do this, on IRIX. Let me just say: was I ever *GLAD* I managed to find a precompiled binary)
That's why I'm partial to compilers that generate C code (like SmallEiffel). It makes things easier for users, while still allowing them to generate binaries fully optimized for their architectures. And it works perfectly in a source package. You put in Makefile rules to convert Haskell/ML/etc. to C, and then the usual C->O rules, and distribute both the FP sources and C sources. Users will need the FP setup if they want to hack program code, but at least they need nothing more than a C compiler to get it up and running.
On a related note, there's also the issue of run-time libraries. Requiring anything that isn't the C library, or that can't be statically linked (without making hugeass binaries) is a lost cause. Again, it's an activation-energy thing. If you can't just download a binary and run it, then you're asking your users to do too much.
So, the ideal alternate language system would have to have at least the following bullets:
Native code generation through a GCC backend. That way, the compiler maintainers only have to track GCC, and not the three or four machine architectures they happen to have in their lab. Not to mention, I know my stuff will run on anything GCC runs on, which would be just about every computer architecture in the known universe <g>
Compilation to C. Java bytecode output a plus. Natively generated code could run faster, as the FP compiler would be better suited to the language features, but the C code should come in a close second.
No run-time library, or at most nothing too formidable. It *must* be statically-linkable.
Execution speed on the order of C/C++ code (not a problem for many implementations)
Non-ugly interface to C/C++ libraries.
Not many alternate language implementations have all those features. SmallEiffel was one, I recall. I think there was one for Haskell, though I never got around to checking it out...
(Disclaimer: I haven't actually gotten into FP yet. I like what I've heard of it, and I do intend to delve into it sometime. I just don't want my non-C code to be a PITA for users because of technical issues like this. If it gives them grief, it should be because they can't think functionally, not because they can't build the damn thing!)
right? (I'm only sure about the first one-- at least that's how big ints are on Alpha)
ObWonder: Why don't 64-bit platforms have 64-bit ints? I mean, int has historically gone from 16 to 32 bits (was 16 in DOS, at least), so why not 32 to 64?
Ummm... I'm no chem major, but H2O is already a low-energy molecule, i.e. you can't react water with [something in the] air to produce an exothermic reaction, because it doesn't have any energy to release.
Now, if you're talking about electrolyzing the water first (separating it into H2 and O2), and then reacting the hydrogen and oxygen together, then you have something that works. Hydrogen power.
The idea being, you can electrolyze water in a large, stationary facility, and load up vehicles with hydrogen as fuel. In theory, the vehicles burn the H2 + O2 from the air, and give off nothing more than water vapor as exhaust. In practice, N2 in the air screws things up royally (makes nitrous oxides in the exhaust, IIRC), and storing hydrogen is a whole issue unto itself (since it tends to be explosive and all...)
Still, it's a cool idea, and it's being worked on. I believe H2 engines are supposed to be quite strong, even compared to gasoline ones. At least the H2-O2 reaction is *incredibly* powerful.
. . . check out this file, on the Samhain project. This is basically a polymorphic-stealth worm system, that was developed as a proof-of-concept (and was never finished).
It's cross-platform (as in, Unix and NON-Unix), it goes really far to evade detection and analysis (not to mention removal), and the freakiest part of it is, the whole system was designed to work in a distributed, intercommunicable fashion ("wormnet"). It's scary shit. Especially an observation the lead programmer makes near the end-- "sure, we didn't release this, but what if some other intelligent but deranged programmer out there has?"
I saw this article a while back linked from here. Incredibly cool stuff . . . the part about "blueprinting software" and "how we design software in the future" was especially cool. It makes one aspire to code to a higher standard.
That said, something I was curious about that the article didn't answer, and that I don't see mentioned here yet-- what language is all of this done in? Ada would be my guess, or is there something even better than that?
If you check the site, the entry-level machine is only about $2800. Sure, it's pricey if you compare it to an eMachines, but for an SGI workstation? Where prices usually go north of $6000? These boxes are a bargain!!
This is part of the new direction SGI has been moving in . . . not only to an open software architecture (Linux) but also to a new level of price-consciousness. Expensive, powerful workstations just don't sell anymore; Nvidia's hardware can make a lowly Dell PC push more pixels than an Octane. So SGI's rolling with that, and is moving toward making the best damn non-outrageously-priced graphics workstations on the market.
This kicks serious tail. The free-software world will finally gain a next-generation alternative to MPEG. Completely free and nonproprietary . . . at least I hope patents don't cause a problem (I understand there are many surrouding MPEG-4).
The future of free, high-quality A/V codecs looks bright. First Ogg Vorbis, and now this. Goodbye xanim binary modules, hello fully open-source SDL-accelerated DVD-quality full-screen video player!
I think the open source community needs to spend more time in the software design phase. Where I work, we don't code until we have TONS of diagrams/description of logic done. Overall, I think it leads to a much better product.
Documentation and DOL are extremely important... reminds me of a development tool that I have used that would compile psuedo code... haha. Funny stuff.
Have to agree. As it happens, I've been looking around lately for some higher-level design tools, and unfortunately, there's not a lot out there in the free-software realm. freshmeat lists Libero and TCM, which look good, but probably aren't the ultimate in software design.
Speaking of doc, what do you guys feel is the best tool for managing it. I mean something akin to doc++ or Doxygen. Are there any other better solutions?
I haven't really used any of the doc-generating programs out there-- but let me mention gtkdoc, which for C API's is probably the best of them all. (See here for an example-- ain't it beautiful?) It works through Docbook SGML and the Jade processor to produce HTML, TeX, man, and anything else you have a stylesheet for. Unfortunately, the whole thing is a b**** to get working. It's a huge mess of Perl scripts and weird Makefile rules, I tried it one day and barely made it out alive:-(
(But man, results like that GLib documentation would be worth it!)
Of course, however, all those tools assume that your approach to documentation is placing specially formatted comments (Javadoc-style or otherwise) above each of your module/type/function definitions. I don't know of a better way to go about it-- tying the implementation and documentation together makes it hard to neglect keeping the docs up to date-- but it surely isn't the only approach.
They now have their development environment setup so that their windows and linux drivers use nearly the same code base( methinks ), so that whenever they fix a bug/add a feature to the windows or linux driver the improvement shows up in both. I think this is very ingenius.
Yes, I agree. But as often as the cries of "open source!" have been raised here, it's not the source code that really matters. It's the programming specs. Source means you can get a really good driver for XFree86. Specs means you get a really good driver for XFree86, BeOS, OS/2, GGI, SVGAlib, and any other OS/graphics system people care enough about. After all, if you want to write a driver for a system other than the one supported by the released source, you have to grok the specs from that source first. Published specs save you that big first step.
Come on, do you see Intel telling amd "here are the circuit layouts for our IA-64 architecure"
No, but Intel does publish the register and instruction interfaces. They tell you how to actually use their hardware.
Imagine if that weren't the case. Say that x86 Linux systems couldn't use gcc, because no docs are available to write up a machine specification. Instead, they bundle icc (Intel C compiler), which is available in binary-only form from Intel's FTP site. All binaries on the system are built with it. You can't program the CPU directly (in assembler) because the information necessary to do that is protected IP.
Does that not strike you as an utterly preposterous situation?
Should the register interface to a video card be any different?
I think a lot of people have lost sight of what sheer folly it is to sell computer hardware components without making available information on how to interface with them at the hardware level. That's not protected IP. That's something one ought to be able to take for granted!
Yes, it's true that Nvidia's register specs may contain trade secrets. It's actually the case that their driver implements a lot of functionality that would normally either be in firmware or silicon (Nvidia cards don't have a clean "register interface" in the usual sense, or at least they haven't). But what does that mean? That means they did not design the hardware correctly. They got careless. And 9 out of 10 says it's because they've been used to shipping only Windows drivers, where binary-only is not only a non-issue, it's the norm. There was no concrete reason to keep the interface IP-clean, or even publicly documented, so both those goals were dropped as soon as it was convenient.
in the meantime I'll be enjoying my nvidia cards, closed-source drivers and all. If nvidia is willing to maintain linux drivers for you, what are you complaining about?
Alpha and PPC users have plenty to complain about. BeOS and OS/2 users have plenty to complain about. GeForce on Linux users might very possibly have something to complain about when the GeForce 4 rolls around, and Nvidia wants to boost sales.
The real kicker, however, is that if Nvidia did things correctly, all those users could be made happy at no additional expense-- if only Nvidia would allow it!
A line needs to be drawn somewhere. What should be free, what shouldn't be free? The guys at nvidia put a lot of hard work into their designs and can't afford to give them away. They have to make _a_living_ off of this and I don't think they'll jeopardize their livelihood in the name of open-source.
There's a lot of information there about their (lack of) support for free OS's, issues with the DRI, etc. It was put together shortly after the Nvidia and Linux Troubles article on/. by PI's Frank LaMonica.
Have to add, of course, that if ATI's new Radeon hardware really does outdo the GeForce 2, and ATI releases programming specs for that puppy-- Nvidia is toast.
Heh. I wonder how good are the aerodynamics and handling }:-)
Kinda reminds me of Airwolf. Y'all remember how it's basically a Bell 222 chopper with a major body job? Somewhere (some AW fan site, forgot URL) is mentioned that the modifications actually improved the flight characteristics of the aircraft. Which is really neat, when you consider the thing probably wasn't designed by an engineer . . .
Well, this is only a minor setback. Of course books are going to be digitized; it's not a matter of if but when.
I've been wondering, however . . . what would be the best long-term stable format for book-encoding? I imagine it would be some flavor of SGML (IIRC, long-term library data storage is its raison d'etre). But, which particular flavor? Does a suitable one already exist? Are there DTD's and stylesheets available?
Unlike the approach Project Gutenberg has taken (ASCII text ONLY) this has definite potential. Imagine taking an SGML-encoded book, running it through Jade with the appropriate stylesheet, and generating a.tex file, and then a beautifully typeset.dvi or.pdf . . . or just as easily generating HTML. Heck, you could have embedded hyperlinks all over the place. Ahh, the possibilities!
If you release the algorithm under the GPL, commercial software interests won't touch it with a ten-foot pole. It makes a rather effective, and quite free-software-friendly way of protecting your IP, while keeping your options open to alternate licensing schemes (that are more agreeable to said software interests).
Look at FFTW for a case study of this approach. It's a library for performing Fourier transforms, distinguished for being faster than anything out there. They have it available as a free, GPL'ed download, and sell commercial licenses for a pretty penny.
I cut data from file A, and paste it into file B. I can then control who has access to the information in file A by allowing them access to file B (which contains all the information from file A). This would be the case for ACL's, and all unix style permissions. MAC control on the other hand stops this.
Whoa. That's tight. But is that really possible? You could stop someone from doing 'cat A >> B', but what if I, say, load up a text editor, import A, and write to B? Or if anything, write a small program that does open(A); open(B); fread(A); fwrite(B);? Or just looked at A, switched to another virtual terminal, and typed the text verbatim into B?
I see how you could make changing the security level of particular data (not just the file) inconvenient, but how can you make it impossible?
If this thing were to ever become a full-blown BSD distribution, think of all the fun possibilities for the CD cover art. If you thought the OpenBSD one was good, wait till they show big bad crackers who think they're "The One" };-)
Slashdot Mirror
D'oh! Guess the ISO is the way to go, then :-)
Tucows doesn't seem to be running slow at all, but if others disagree, here's a little something that should help:
File: qnxrtp.iso
Size: 95911936
MD5 sum: 75c8dc3a42f80a85ef8c733a317d8ebd
Anyone know what (duuuh heck) this is?
skunk:~$ file qnxrtp.tar.F
qnxrtp.tar.F: frozen file 2.1
skunk:~$
Anyway, for the sake of Tucow's bandwidth, I'm mirroring the file here. MD5 sum = 316236554639edf717a94026ee940812.
Having been accustomed to RH's non-human-readable /var/lib/rpm/*.rpm database files, all I can say is:
/var/lib/dpkg/info/${pkg-name}.list ;-)
That kicks ass.
Thanks for passing the tip!
(P.S.: It's actually
The review dumps on the install, but that was no big deal. If you've been using Linux for more than a year, and bash doesn't scare you, neither will dbootstrap. (Btw, I have to agree that dbootstrap looks like FreeBSD's installer-- almost exactly. They do say Debian is the most BSD-like of the distros...)
Oh, yeah, and apt-get/dpkg are sweet. They are very intelligent, almost dauntingly so. Debian's package system keeps a lot of state about packages going in and out. Just yesterday, I wanted to upgrade Esound from the normal "esound" version to "esound-alsa," and the process was something like this:
(can't do; conflicts with esound)
(can't do; several packages depend on esound)
(hmmm, esound is being considered for removal, and esound-alsa also satisfies the dependency for those packages, so install it)
There was probably a better way to do that, but that it could do that sure threw me for a loop. One thing I don't like about dpkg is that it doesn't index files; if you're used to doing rpm -qf <file> a lot, then you'll have to switch to dpkg -S <file> and waiting for the package manager to search for which package the file belongs to, usually taking a few seconds (whereas rpm does it instantly).
One other pet peeve was that no binary Pine/Pico
If you're an idealistic-in-thought/pragmatic-in-practice guy like me, Debian's non-free section is nice, in that it reminds you what software doesn't quite meet the ideals that spawned the whole thing. Nothing obtrusive, just a tiny reminder...
Anyway, I'm very happy with my new Debian system. The extensive testing really shows, and makes the system feel much more solid than your typical RH setup. If Linux is just Linux to you, then it's no big deal, but if you want to build your system into perfection, Debian is probably the best starting point. I'm well on my way
VA is currently working on an XFree4.0 driver for the new Radeon cards. It's being developed under contract from ATI themselves, it'll use the DRI, and it'll be open-source.
Check out the adjacent article on Tom's, about the Radeon. It performs slightly slower than the GeForce in 16-bit mode, and at lower resolutions, but at high-res 32-bit modes the Radeon edges out the GeForce.
The GeForce numbers may be impressive, but me, I'm going to wait until the Radeon driver is ready. And then I'm going to show ATI just how much I appreciate an open solution.
I looked around the site, but couldn't find the magical PDF files. I don't suppose they'd link those in from the brochureware pages.
Just how much in the way of specs are they releasing? Does it go above and beyond the 2D core? Will people actually be able to write full OpenGL drivers for this thing without an NDA?
Because, if ATI really is being that open with the specs, the beauty of it is that everyone who's been burned by NVidia not releasing theirs will finally have the chance to hit them where it counts: by moving to a competitor's product.
The Radeon looks awesome, and if a level of support for it similar to that of the G400 can come around, Linux and a whole host of non-x86 systems will finally have an open path to cutting-edge 3D support!
LaTeX is, in my opinion, a far superior product
Aye, and it can produce absolutely second-to-none-quality documents with almost no effort. All the formatting can be encoded into templates. Also, you have pdfTeX, so DVI isn't the only target format available.
(These points apply to some variants of Haskell and ML I investigated a while back. I don't remember specifics, but these were the salient observations that resulted):
For one, the compilers are incredibly complex beasts. This wouldn't be so bad, if they weren't so ambitious as to generate native binaries themselves. Myself, I'm leery of anything that generates native machine code, that doesn't use a GCC backend. Maintaining a native code generator is a lot of never-ending work (machine architectures evolve constantly) and IMHO, not using GCC for that is a lost cause, in the long term.
More significantly, if the compiler's native code generator is the only way to get a native binary, you're basically requiring users to go through a MAJOR hassle (installing a full-blown compiler) just to run your program non-interpreted, if at all.
(If you want to know what I mean, try building the CVSup program-- written in Modula3-- from scratch. I almost had to do this, on IRIX. Let me just say: was I ever *GLAD* I managed to find a precompiled binary)
That's why I'm partial to compilers that generate C code (like SmallEiffel). It makes things easier for users, while still allowing them to generate binaries fully optimized for their architectures. And it works perfectly in a source package. You put in Makefile rules to convert Haskell/ML/etc. to C, and then the usual C->O rules, and distribute both the FP sources and C sources. Users will need the FP setup if they want to hack program code, but at least they need nothing more than a C compiler to get it up and running.
On a related note, there's also the issue of run-time libraries. Requiring anything that isn't the C library, or that can't be statically linked (without making hugeass binaries) is a lost cause. Again, it's an activation-energy thing. If you can't just download a binary and run it, then you're asking your users to do too much.
So, the ideal alternate language system would have to have at least the following bullets:
- Native code generation through a GCC backend. That way, the compiler maintainers only have to track GCC, and not the three or four machine architectures they happen to have in their lab. Not to mention, I know my stuff will run on anything GCC runs on, which would be just about every computer architecture in the known universe <g>
- Compilation to C. Java bytecode output a plus. Natively generated code could run faster, as the FP compiler would be better suited to the language features, but the C code should come in a close second.
- No run-time library, or at most nothing too formidable. It *must* be statically-linkable.
- Execution speed on the order of C/C++ code (not a problem for many implementations)
- Non-ugly interface to C/C++ libraries.
Not many alternate language implementations have all those features. SmallEiffel was one, I recall. I think there was one for Haskell, though I never got around to checking it out...(Disclaimer: I haven't actually gotten into FP yet. I like what I've heard of it, and I do intend to delve into it sometime. I just don't want my non-C code to be a PITA for users because of technical issues like this. If it gives them grief, it should be because they can't think functionally, not because they can't build the damn thing!)
So, Itanium being 64-bit, that would mean:
sizeof(int) == 4
sizeof(float) == 4
sizeof(double) == 8
sizeof(void *) == 8
right? (I'm only sure about the first one-- at least that's how big ints are on Alpha)
ObWonder: Why don't 64-bit platforms have 64-bit ints? I mean, int has historically gone from 16 to 32 bits (was 16 in DOS, at least), so why not 32 to 64?
Ummm... I'm no chem major, but H2O is already a low-energy molecule, i.e. you can't react water with [something in the] air to produce an exothermic reaction, because it doesn't have any energy to release.
Now, if you're talking about electrolyzing the water first (separating it into H2 and O2), and then reacting the hydrogen and oxygen together, then you have something that works. Hydrogen power.
The idea being, you can electrolyze water in a large, stationary facility, and load up vehicles with hydrogen as fuel. In theory, the vehicles burn the H2 + O2 from the air, and give off nothing more than water vapor as exhaust. In practice, N2 in the air screws things up royally (makes nitrous oxides in the exhaust, IIRC), and storing hydrogen is a whole issue unto itself (since it tends to be explosive and all...)
Still, it's a cool idea, and it's being worked on. I believe H2 engines are supposed to be quite strong, even compared to gasoline ones. At least the H2-O2 reaction is *incredibly* powerful.
. . . check out this file, on the Samhain project. This is basically a polymorphic-stealth worm system, that was developed as a proof-of-concept (and was never finished).
It's cross-platform (as in, Unix and NON-Unix), it goes really far to evade detection and analysis (not to mention removal), and the freakiest part of it is, the whole system was designed to work in a distributed, intercommunicable fashion ("wormnet"). It's scary shit. Especially an observation the lead programmer makes near the end-- "sure, we didn't release this, but what if some other intelligent but deranged programmer out there has?"
I saw this article a while back linked from here. Incredibly cool stuff . . . the part about "blueprinting software" and "how we design software in the future" was especially cool. It makes one aspire to code to a higher standard.
That said, something I was curious about that the article didn't answer, and that I don't see mentioned here yet-- what language is all of this done in? Ada would be my guess, or is there something even better than that?
If you check the site, the entry-level machine is only about $2800. Sure, it's pricey if you compare it to an eMachines, but for an SGI workstation? Where prices usually go north of $6000? These boxes are a bargain!!
This is part of the new direction SGI has been moving in . . . not only to an open software architecture (Linux) but also to a new level of price-consciousness. Expensive, powerful workstations just don't sell anymore; Nvidia's hardware can make a lowly Dell PC push more pixels than an Octane. So SGI's rolling with that, and is moving toward making the best damn non-outrageously-priced graphics workstations on the market.
Not to mention the coolest-looking };-)
How well does DivX compare to Sorenson? }:-)
This kicks serious tail. The free-software world will finally gain a next-generation alternative to MPEG. Completely free and nonproprietary . . . at least I hope patents don't cause a problem (I understand there are many surrouding MPEG-4).
The future of free, high-quality A/V codecs looks bright. First Ogg Vorbis, and now this. Goodbye xanim binary modules, hello fully open-source SDL-accelerated DVD-quality full-screen video player!
I think the open source community needs to spend more time in the software design phase. Where I work, we don't code until we have TONS of diagrams/description of logic done. Overall, I think it leads to a much better product.
:-(
Documentation and DOL are extremely important... reminds me of a development tool that I have used that would compile psuedo code... haha. Funny stuff.
Have to agree. As it happens, I've been looking around lately for some higher-level design tools, and unfortunately, there's not a lot out there in the free-software realm. freshmeat lists Libero and TCM, which look good, but probably aren't the ultimate in software design.
Speaking of doc, what do you guys feel is the best tool for managing it. I mean something akin to doc++ or Doxygen. Are there any other better solutions?
I haven't really used any of the doc-generating programs out there-- but let me mention gtkdoc, which for C API's is probably the best of them all. (See here for an example-- ain't it beautiful?) It works through Docbook SGML and the Jade processor to produce HTML, TeX, man, and anything else you have a stylesheet for. Unfortunately, the whole thing is a b**** to get working. It's a huge mess of Perl scripts and weird Makefile rules, I tried it one day and barely made it out alive
(But man, results like that GLib documentation would be worth it!)
Of course, however, all those tools assume that your approach to documentation is placing specially formatted comments (Javadoc-style or otherwise) above each of your module/type/function definitions. I don't know of a better way to go about it-- tying the implementation and documentation together makes it hard to neglect keeping the docs up to date-- but it surely isn't the only approach.
They now have their development environment setup so that their windows and linux drivers use nearly the same code base( methinks ), so that whenever they fix a bug/add a feature to the windows or linux driver the improvement shows up in both. I think this is very ingenius.
Yes, I agree. But as often as the cries of "open source!" have been raised here, it's not the source code that really matters. It's the programming specs. Source means you can get a really good driver for XFree86. Specs means you get a really good driver for XFree86, BeOS, OS/2, GGI, SVGAlib, and any other OS/graphics system people care enough about. After all, if you want to write a driver for a system other than the one supported by the released source, you have to grok the specs from that source first. Published specs save you that big first step.
Come on, do you see Intel telling amd "here are the circuit layouts for our IA-64 architecure"
No, but Intel does publish the register and instruction interfaces. They tell you how to actually use their hardware.
Imagine if that weren't the case. Say that x86 Linux systems couldn't use gcc, because no docs are available to write up a machine specification. Instead, they bundle icc (Intel C compiler), which is available in binary-only form from Intel's FTP site. All binaries on the system are built with it. You can't program the CPU directly (in assembler) because the information necessary to do that is protected IP.
Does that not strike you as an utterly preposterous situation?
Should the register interface to a video card be any different?
I think a lot of people have lost sight of what sheer folly it is to sell computer hardware components without making available information on how to interface with them at the hardware level. That's not protected IP. That's something one ought to be able to take for granted!
Yes, it's true that Nvidia's register specs may contain trade secrets. It's actually the case that their driver implements a lot of functionality that would normally either be in firmware or silicon (Nvidia cards don't have a clean "register interface" in the usual sense, or at least they haven't). But what does that mean? That means they did not design the hardware correctly. They got careless. And 9 out of 10 says it's because they've been used to shipping only Windows drivers, where binary-only is not only a non-issue, it's the norm. There was no concrete reason to keep the interface IP-clean, or even publicly documented, so both those goals were dropped as soon as it was convenient.
in the meantime I'll be enjoying my nvidia cards, closed-source drivers and all. If nvidia is willing to maintain linux drivers for you, what are you complaining about?
Alpha and PPC users have plenty to complain about. BeOS and OS/2 users have plenty to complain about. GeForce on Linux users might very possibly have something to complain about when the GeForce 4 rolls around, and Nvidia wants to boost sales.
The real kicker, however, is that if Nvidia did things correctly, all those users could be made happy at no additional expense-- if only Nvidia would allow it!
A line needs to be drawn somewhere. What should be free, what shouldn't be free? The guys at nvidia put a lot of hard work into their designs and can't afford to give them away. They have to make _a_living_ off of this and I don't think they'll jeopardize their livelihood in the name of open-source.
Since chromatic doesn't seem to be around today, I may as well mention a helpful little page he's put together, for those who haven't seen it yet:
/. by PI's Frank LaMonica.
What is Nvidia doing?
There's a lot of information there about their (lack of) support for free OS's, issues with the DRI, etc. It was put together shortly after the Nvidia and Linux Troubles article on
Have to add, of course, that if ATI's new Radeon hardware really does outdo the GeForce 2, and ATI releases programming specs for that puppy-- Nvidia is toast.
Heh. I wonder how good are the aerodynamics and handling }:-)
Kinda reminds me of Airwolf. Y'all remember how it's basically a Bell 222 chopper with a major body job? Somewhere (some AW fan site, forgot URL) is mentioned that the modifications actually improved the flight characteristics of the aircraft. Which is really neat, when you consider the thing probably wasn't designed by an engineer . . .
Well, this is only a minor setback. Of course books are going to be digitized; it's not a matter of if but when.
.tex file, and then a beautifully typeset .dvi or .pdf . . . or just as easily generating HTML. Heck, you could have embedded hyperlinks all over the place. Ahh, the possibilities!
I've been wondering, however . . . what would be the best long-term stable format for book-encoding? I imagine it would be some flavor of SGML (IIRC, long-term library data storage is its raison d'etre). But, which particular flavor? Does a suitable one already exist? Are there DTD's and stylesheets available?
Unlike the approach Project Gutenberg has taken (ASCII text ONLY) this has definite potential. Imagine taking an SGML-encoded book, running it through Jade with the appropriate stylesheet, and generating a
Was it just me, or was that bit (from Being John Malkovich) only the most bizarre scene in movie history??
(Awesome movie, btw, though the ending kinda sucked)
If you release the algorithm under the GPL, commercial software interests won't touch it with a ten-foot pole. It makes a rather effective, and quite free-software-friendly way of protecting your IP, while keeping your options open to alternate licensing schemes (that are more agreeable to said software interests).
Look at FFTW for a case study of this approach. It's a library for performing Fourier transforms, distinguished for being faster than anything out there. They have it available as a free, GPL'ed download, and sell commercial licenses for a pretty penny.
For anyone too lazy to even bother . . .
. dll s sr.dll
...... [100%]
skunk:~$
skunk:~$
skunk:~$ wget http://www.sivertsen.com/_vti_bin/_vti_aut/dvwssr
--12:06:28-- http://www.sivertsen.com:80/_vti_bin/_vti_aut/dvw
=> `dvwssr.dll'
Connecting to www.sivertsen.com:80... connected!
HTTP request sent, fetching headers... done.
Length: 6,416 [text/html]
0K ->
12:06:28 (59.11 KB/s) - `dvwssr.dll' saved [6416/6416]
skunk:~$ file dvwssr.dll
dvwssr.dll: MS Windows PE 32-bit Intel 80386 GUI DLL
skunk:~$ strings dvwssr.dll
!This program cannot be run in DOS mode.
.text
`.rdata
@.data
.idata
.rsrc
@.reloc
>%u:
D$4h
D$4j
]_^[
t*;5
D$4j
D$<"
DVWSSR.DLL
DllMain
GetExtensionVersion
HttpExtensionProc
/global.asa
.asp
!seineew era sreenigne epacsteN
HTTP/1.0 404 Object Not Found
XWebScope Source Retriever
_refresh_acls_
Content-type: text/html
KERNEL32.dll
lstrcmpiA
lstrcpynA
CloseHandle
ReadFile
CreateFileA
lstrlenA
lstrcpyA
GetModuleFileNameA
lstrcmpA
1!1-141H1O1
2q2}2
`0d0
dvwssr.dbg
ssr.dll
skunk:~$
Yah, if you were able to buy one, you could put your time in just designing the perfect form factor for it. TNG-style tricorder, anyone? :-)
I cut data from file A, and paste it into file B. I can then control who has access to the information in file A by allowing them access to file B (which contains all the information from file A). This would be the case for ACL's, and all unix style permissions.
MAC control on the other hand stops this.
Whoa. That's tight. But is that really possible? You could stop someone from doing 'cat A >> B', but what if I, say, load up a text editor, import A, and write to B? Or if anything, write a small program that does open(A); open(B); fread(A); fwrite(B);? Or just looked at A, switched to another virtual terminal, and typed the text verbatim into B?
I see how you could make changing the security level of particular data (not just the file) inconvenient, but how can you make it impossible?
That "Agent Beastie" logo kicks tail!
If this thing were to ever become a full-blown BSD distribution, think of all the fun possibilities for the CD cover art. If you thought the OpenBSD one was good, wait till they show big bad crackers who think they're "The One" };-)