I'm really curious to see how things are going to work out on x86-64 and IA-64 with regards to mixed 32/64-bit systems. I assume both platforms are going to provide some sort of thunking interface so 32-bit code can call 64-bit libraries, etc, but it's a non-trivial problem, especially for developers, since you have to devise some system for building and keeping both versions of libraries and executables around.
Sun and IRIX people have been dealing with this for a long time, but I'm interested to see how most other developers will adapt (since I'm guessing there are 20-30x more x86-only developers than Sun and IRIX developers =).
I agree that Qt is quite well put-together, but after working with it for a little while (I'm mostly a GTK/PyGTK fan) I've found it has an annoying flaw that really prevents me from using it effectively: its memory-management system is restrictive, and it only works in C++.
The "restrictive" part is due to the fact that Qt takes a simplistic hierarchical view of resource ownership - parent objects own their children, and delete them when they are deleted. This forces you to implement most of your own code as subclasses of Qt toolkit classes. Aside from being aesthetically icky, this can get you into trouble when the rest of your own code has different ideas about object ownership and lifetimes. At the very least you need to write extra adaptor code or invent weak references for Qt objects.
The other problem of course is that Qt "only works from" C++. I've long since left static languages behind for GUI development; Python and friends are the way of the future. Sure there are bindings like PyQt, but PyQt has some serious memory management problems (since Python objects are reference counted, and can't easily mesh with Qt's object hierarchy). The result is segfaults and/or memory leaks even for simple PyQt programs.
Using Qt was an interesting and worthwhile experiment, but I much prefer Gtk's more reasonable resource management scheme (which has been designed from the ground up to cooperate with scripting language bindings).
I've heard lots of reports from reputable sources that cheaper Athlon XP's do work in multi-CPU systems. (Even the original Thunderbird supposedly works, although not at top speed due to some cache interactions). I've heard that the Athlon XP uses the same Palomino core as the Athlon MP, so there is really no difference at the hardware level.
Can anyone confirm this? Is this new, higher-priced series of Athlon MP's simply a marketing gimmick, a la NVIDIA's Quadro cards? (which are the same as a Geforce hardware-wise - save one tiny resistor that tells the driver to un-cripple certain optimizations - but cost 2-3 times as much a Geforce)
A much more ambitious comet flyby mission, CONTOUR, will be launched by NASA less than a year from now. CONTOUR will approach 2 or 3 comets to within ~100km of the nucleus.
I must finish with a shameless plug for the exciting computer animation I created to illustrate CONTOUR's mission, available at the CONTOUR website
Secondly, the idea of running EVERYTHING through OpenGL is particularly bothering. Most video hardware has some very specific optimisations for 2D work and by going through a specific 3D interface you are tossing all those performance advantages out the window
Let me put it this way: my Geforce 2 can render complex Quake 3 and Halflife scenes, with thousands of polygons and megabytes of textures, at well over the refresh rate of my monitor (100Hz). So don't you think it would be able to draw a couple opaque windows and some text that fast too?*
*(Yes, on a typical GUI desktop you'll have much more overdraw than in a game. So for a real implementation you'd render each window into its own mini-framebuffer, then have the graphics server blit them onto the desktop lazily)
The fact is, when you see python, there is'nt "one magic application" that suddenly jumps out as "the perfect thing" to use python for. I think that's because sucn an application does not exist
I would say Zope (and persistent object databases in general) might be Python's "killer app." I've been doing a bit of work on a similar database system, and certain aspects of Python make it very well suited for this kind of stuff... e.g. a very clean object model, override-able __getattr__() and __setattr()__ methods, consistent reference semantics throughout, etc. Python is the perfect toolbox for building persistent and distributed OO systems.
About the only extra things I've been wishing for are optional static type-checking and C-like syntax (I like my curly braces, so shoot me =). Static type-checking is really necessary because I'm finding that I make just as many type errors in Python as memory management errors in C =).
By binding Direct3D so tightly to the Win32 API, they make porting the appliation to a non-Windows API much more difficult.
This used to be the case - early D3D was clearly an attempt to de-throne OpenGL by locking developers into a radically different API. Since then, however, both APIs have evolved dramatically to support modern graphics hardware (e.g. everyone has transitioned to vertex buffers for communicating with the card, multitexturing and texture-combination operations have been standardized, and vertex shaders are coming next).
The beautiful thing is, today Direct3D 8 and OpenGL (with extensions, especially Nvidia's) present very similar interfaces! In fact it would be quite simple to implement both as backends to a single renderer without sacrificing clean design or performance!
BTW you have to thank Nvidia for all this... They are currently driving the development of both D3D and OpenGL, so it's no wonder the interfaces have evolved towards each other.
I'd definitely recommend looking at the latest kernel. You'll learn neat stuff like:
o How to do OOP in C (including virtual functions; see any of the *_ops structs)
o How to write macros that inline well (eg the spinlock macros)
o How to arrange structs for better cache performance (eg the network-related structs)
o How to write portable code that configures itself via macros; the final results compile to very efficient platform-specific code without a hint of overhead
For a higher-level view of software, I'd also encourage you to examine glib and gtk.
o These expose a large, industrial-strength API; you'll see how a modern large-scale package is organized, and how it deals with complex issues like character sets
o You'll learn one approach to event-driven programming; glib and gtk make extensive use of callbacks and reference counting since order of execution is impossible to predict in an interactive program
o Along the way you'll pick up Gtk programming, which is quite a useful skill if you need a GUI sometime
If you're interested in scripting languages, definitely check out Python; it's very well-organized and cleanly designed. Plus knowing how to embed/integrate scripts with a C/C++ package is very valuable.
While carefully studying these packages, I'm sure you'll even find a bug or two to fix - giving you an opportunity to contribute as well as learn =)
Please note that due to the inaccessibility of www.microsoft.com, all installations of Windows 2001, Office 2002, and Internet Explorer 6 will cease to function until service is restored. We thank you for your patience in this matter.
Step back for a second and think through the possibilities:
1) Write a library of good-looking, wickedly fast GUI widgets using the EVAS API (rip some code from Gtk to get this going quickly)
2) Invent a high-level network protocol for creating, manipulating, and responding to events on these widgets. Heck, write one on top of CORBA if you must. Now client applications will connect directly to Enlightenment and build GUI interfaces using its facilities.
3) Give Enlightenment direct access to input devices through a library like SDL
4) Finally, RM -RF THAT CRUFTY PIECE OF JUNK CALLED X11!
Please, Rasterman, realize that this technology won't just enable window managers to have fast eye-candy. It could form the basis for a completely independent, hardware-accelerated display server (not even OSX's Quartz is hardware-accelerated yet)! By managing and rendering widgets at the server, you will blow Windows, OSX, etc out of the water performance-wise, and keep X11-style network transparency!
No human finger will actually pull a trigger. Onboard computers will decide when to fire the beam." I find this to be a bit disconcerting.
This is a fairly common thing for time-critical weapons. The human operator controls the system with an "enable" button -- holding down the button signals that it's OK to fire the laser or drop the bomb or whatever. It's the computer that decides the precise moment to shoot. If the enable button is not held, the weapon can't go off.
How would you react to the following scenario: say a medical researcher thinks of a new cancer or AIDS cure. In order to develop the drug, she needs several million dollars worth of equipment and assistant labor, none of which she can remotely afford.
A businessperson offers the researcher a deal - he will provide the required funding, in return for a portion of the revenues the drug creates. Some form of "intellectual property protection" (ie a patent) will be necessary for this deal to happen -- otherwise the drug would be copied by others, and most of its profit potential would evaporate in the ensuing price war.
I claim that this hypothetical situation demonstrates a need for patents that can be applied beyond the individual inventor. Yes, the best societal outcome would be for the drug to be released at very low cost, but without the prospect of a lucrative temporary monopoly, the funding to develop it wouldn't be provided in the first place!
In a world with much more limited IP protections, how could this miracle drug become a reality?
(I do agree with your sentiment; basically I'm just playing Devil's advocate here...)
Outlook Express is not free in the sense Miguel is talking about (free as in speech). The cost of development was absorbed from the profits from Windows & Office, same as Internet Explorer.
Right but by this definition Evolution is not "free" either, because the cost of development will be absorbed by Helix's profits from their for-pay services. Miguel and company have to eat =). (Not that there's anything wrong with that; after all, you can only accomplish so much with donated spare-time labor...)
64-bit registers and instructions to natively and atomically handle 64-bit values are not a gain, they are a loss. My reasoning here is that on a desktop-type machine, most (90%+??) of the numbers traversing the registers are will within the 32-bit range...
Having a 64-bit register doesn't necessarily mean you must work with 64-bit types. You could also operate on eight 8-bit values at once, and see a commersurate speed gain over a narrower system. (remember rep stosb vs. rep stosd, assembly coders?)
This kind of thing already happens on today's systems, thanks to the hordes of Vector Instruction Sets With Silly Names™. In some ways, you could get away with calling a Pentium III with SSE a "128-bit" procesor...
I know that the main thinking here on/. seems to be, IP=bad, patents=bad, business=bad. I would tend to disagree. Patents, when applied correctly, help innovation, rather than stifle it.
I agree with you in principle, but there are severe problems with today's implementation of patents. Mainly, the time scale is way, way off.
Instead of giving innovative companies a small head-start to recoup their R&D costs, 17-year patents give them a competition-crushing, innovation-stifling monopoly for the entire lifetime of their products.
Consider that if Apple had patented the windowed GUI back in 1985, the patent would still be in effect today. That means not only no Windows as we know it, but no GNOME, no KDE, no BeOS, no 4DWM, etc. Un-licensed GUI efforts would have been utterly stifled until two years from now! I guarantee you that in such a world, graphical interfaces would not have advanced anywhere near where they are today. (Also note that Apple continues to make a hefty profit from its inventions without patent protection)
I say we should return the patent system to its original purpose. Restrict patent terms to half of a product's projected useful lifetime: enough to give companies an incentive to invest in R&D, but not enough to stifle innovation in vital areas. Terms could vary according to the type of patent; I'd have no qualms with, say, two-year software patents, or six-month business model patents.
You can't combine Open Source (which is a protected term, mind you) with selling the same product for thousands of dollars
There is nothing mutually exclusive about Open Source and charging for the software... For one, you can capitalize on the fact that the vast majority of people wouldn't know what to do with a source tarball if one it them in the face. People want vendor-certified officially-supported pre-compiled software, and they'll pay dearly for that...
Say I write a useful GPL utility for Linux. I make the.tar.gz freely available to whoever wants it. But I charge a nominal fee for downloading an.rpm or a.deb; the price might reflect e.g. similarly capable Windows shareware. If people don't want to pay, they are free to figure out how to compile the thing themselves. But do not underestimate the number of consumers who would rather spend a quick $20 than do battle with your configure script... (note also that only my "blessed" binaries are eligible for tech support/bug tracking...).
Anyone know when the Linux driver is coming out? I bought one of these in expectation of dumping my nVidia hardware when the DRI driver becomes available. I heard Precision Insight was working on it, but I'm getting antsy.
Where is the code? Can we actually get a DRI driver for *modern* hardware? Instead of two-year-old pieces of junk like the G400 and Voodoo3?
Dan
Re:One good point -- too much C in open software
on
KDE Strikes Back
·
· Score: 1
You are absolutely right... WAY the hell too much software is written in C/C++ these days. It pains me to browse some of the GNOME sources (not that they are the only guilty party) and see page after page of the repetitive, long-winded, hard-to-read code that inevitably takes over a large ANSI C application.
Unless you are writing something that absolutely MUST be wicked fast (e.g. a game engine), save yourself the trouble and use Python, Perl, or Java. And if something DOES have to be wickedly fast, write that one function in C then plug it into your scripting language... Computers are so fast these days that a GUI application written in Python/Perl/Tcl isn't noticeably slower than one written in C. The speed critical part - the widget library - is probably C, but your application logic still benefits from the nice scripting language features (e.g. first-class function objects/lambdas, which can be emulated in C, but only with many lines of redundant code - try it)
I've always said we need a faster bus than PCI. That puny 100MB/sec bus can't stand up much longer, what with 160MB/sec SCSI and 80MB/sec Gigabit ethernet cards coming into wide use...
Perhaps an entirely USB-based system is the answer. 480MB/sec should be ample bandwidth for tomorrow's PCs (especially if switched). Your basic "system" would be nothing more than a USB backplane, to which you'd attach CPU modules, RAM modules, I/O modules, etc. Thanks to USB's forward-thinking design, neat tricks like adding and removing RAM, graphics cards, and hard drives from a running sytem should be trivially possible...
I have a feeling what he meant was, "The other OS ports will be available 2 weeks after the Win32 release."
(The UNIX ports of earlier id software came well after the main release. Quake 3 was released on everything simultaneously, but distributors held back the non-Windows versions)
Um, a "triumph of open source" would be if you fixed it yourself and distributed a patch immediately; no waiting until 1.3, when it may or may not be fixed by Sun...
Slashdot Mirror
I'm really curious to see how things are going to work out on x86-64 and IA-64 with regards to mixed 32/64-bit systems. I assume both platforms are going to provide some sort of thunking interface so 32-bit code can call 64-bit libraries, etc, but it's a non-trivial problem, especially for developers, since you have to devise some system for building and keeping both versions of libraries and executables around.
Sun and IRIX people have been dealing with this for a long time, but I'm interested to see how most other developers will adapt (since I'm guessing there are 20-30x more x86-only developers than Sun and IRIX developers =).
I agree that Qt is quite well put-together, but after working with it for a little while (I'm mostly a GTK/PyGTK fan) I've found it has an annoying flaw that really prevents me from using it effectively: its memory-management system is restrictive, and it only works in C++.
The "restrictive" part is due to the fact that Qt takes a simplistic hierarchical view of resource ownership - parent objects own their children, and delete them when they are deleted. This forces you to implement most of your own code as subclasses of Qt toolkit classes. Aside from being aesthetically icky, this can get you into trouble when the rest of your own code has different ideas about object ownership and lifetimes. At the very least you need to write extra adaptor code or invent weak references for Qt objects.
The other problem of course is that Qt "only works from" C++. I've long since left static languages behind for GUI development; Python and friends are the way of the future. Sure there are bindings like PyQt, but PyQt has some serious memory management problems (since Python objects are reference counted, and can't easily mesh with Qt's object hierarchy). The result is segfaults and/or memory leaks even for simple PyQt programs.
Using Qt was an interesting and worthwhile experiment, but I much prefer Gtk's more reasonable resource management scheme (which has been designed from the ground up to cooperate with scripting language bindings).
I've heard lots of reports from reputable sources that cheaper Athlon XP's do work in multi-CPU systems. (Even the original Thunderbird supposedly works, although not at top speed due to some cache interactions). I've heard that the Athlon XP uses the same Palomino core as the Athlon MP, so there is really no difference at the hardware level.
Can anyone confirm this? Is this new, higher-priced series of Athlon MP's simply a marketing gimmick, a la NVIDIA's Quadro cards? (which are the same as a Geforce hardware-wise - save one tiny resistor that tells the driver to un-cripple certain optimizations - but cost 2-3 times as much a Geforce)
I must finish with a shameless plug for the exciting computer animation I created to illustrate CONTOUR's mission, available at the CONTOUR website
Check out his rap albums - http://www.mchawking.com/music.html. You definitely shouldn't miss "F*ck the Creationists."
Let me put it this way: my Geforce 2 can render complex Quake 3 and Halflife scenes, with thousands of polygons and megabytes of textures, at well over the refresh rate of my monitor (100Hz). So don't you think it would be able to draw a couple opaque windows and some text that fast too?*
*(Yes, on a typical GUI desktop you'll have much more overdraw than in a game. So for a real implementation you'd render each window into its own mini-framebuffer, then have the graphics server blit them onto the desktop lazily)
I would say Zope (and persistent object databases in general) might be Python's "killer app." I've been doing a bit of work on a similar database system, and certain aspects of Python make it very well suited for this kind of stuff... e.g. a very clean object model, override-able __getattr__() and __setattr()__ methods, consistent reference semantics throughout, etc. Python is the perfect toolbox for building persistent and distributed OO systems.
About the only extra things I've been wishing for are optional static type-checking and C-like syntax (I like my curly braces, so shoot me =). Static type-checking is really necessary because I'm finding that I make just as many type errors in Python as memory management errors in C =).
Dan
This used to be the case - early D3D was clearly an attempt to de-throne OpenGL by locking developers into a radically different API. Since then, however, both APIs have evolved dramatically to support modern graphics hardware (e.g. everyone has transitioned to vertex buffers for communicating with the card, multitexturing and texture-combination operations have been standardized, and vertex shaders are coming next).
The beautiful thing is, today Direct3D 8 and OpenGL (with extensions, especially Nvidia's) present very similar interfaces! In fact it would be quite simple to implement both as backends to a single renderer without sacrificing clean design or performance!
BTW you have to thank Nvidia for all this... They are currently driving the development of both D3D and OpenGL, so it's no wonder the interfaces have evolved towards each other.
We're gonna visit three comets... (but this time we won't be trying to hit one =)
I'd definitely recommend looking at the latest kernel. You'll learn neat stuff like:
o How to do OOP in C (including virtual functions; see any of the *_ops structs)
o How to write macros that inline well (eg the spinlock macros)
o How to arrange structs for better cache performance (eg the network-related structs)
o How to write portable code that configures itself via macros; the final results compile to very efficient platform-specific code without a hint of overhead
For a higher-level view of software, I'd also encourage you to examine glib and gtk.
o These expose a large, industrial-strength API; you'll see how a modern large-scale package is organized, and how it deals with complex issues like character sets
o You'll learn one approach to event-driven programming; glib and gtk make extensive use of callbacks and reference counting since order of execution is impossible to predict in an interactive program
o Along the way you'll pick up Gtk programming, which is quite a useful skill if you need a GUI sometime
If you're interested in scripting languages, definitely check out Python; it's very well-organized and cleanly designed. Plus knowing how to embed/integrate scripts with a C/C++ package is very valuable.
While carefully studying these packages, I'm sure you'll even find a bug or two to fix - giving you an opportunity to contribute as well as learn =)
Dan
Please note that due to the inaccessibility of www.microsoft.com, all installations of Windows 2001, Office 2002, and Internet Explorer 6 will cease to function until service is restored. We thank you for your patience in this matter.
- Microsoft Press Release
See what you're buying into?
1) Write a library of good-looking, wickedly fast GUI widgets using the EVAS API (rip some code from Gtk to get this going quickly)
2) Invent a high-level network protocol for creating, manipulating, and responding to events on these widgets. Heck, write one on top of CORBA if you must. Now client applications will connect directly to Enlightenment and build GUI interfaces using its facilities.
3) Give Enlightenment direct access to input devices through a library like SDL
4) Finally, RM -RF THAT CRUFTY PIECE OF JUNK CALLED X11!
Please, Rasterman, realize that this technology won't just enable window managers to have fast eye-candy. It could form the basis for a completely independent, hardware-accelerated display server (not even OSX's Quartz is hardware-accelerated yet)! By managing and rendering widgets at the server, you will blow Windows, OSX, etc out of the water performance-wise, and keep X11-style network transparency!
This is a fairly common thing for time-critical weapons. The human operator controls the system with an "enable" button -- holding down the button signals that it's OK to fire the laser or drop the bomb or whatever. It's the computer that decides the precise moment to shoot. If the enable button is not held, the weapon can't go off.
How would you react to the following scenario: say a medical researcher thinks of a new cancer or AIDS cure. In order to develop the drug, she needs several million dollars worth of equipment and assistant labor, none of which she can remotely afford.
A businessperson offers the researcher a deal - he will provide the required funding, in return for a portion of the revenues the drug creates. Some form of "intellectual property protection" (ie a patent) will be necessary for this deal to happen -- otherwise the drug would be copied by others, and most of its profit potential would evaporate in the ensuing price war.
I claim that this hypothetical situation demonstrates a need for patents that can be applied beyond the individual inventor. Yes, the best societal outcome would be for the drug to be released at very low cost, but without the prospect of a lucrative temporary monopoly, the funding to develop it wouldn't be provided in the first place!
In a world with much more limited IP protections, how could this miracle drug become a reality?
(I do agree with your sentiment; basically I'm just playing Devil's advocate here...)
Right but by this definition Evolution is not "free" either, because the cost of development will be absorbed by Helix's profits from their for-pay services. Miguel and company have to eat =). (Not that there's anything wrong with that; after all, you can only accomplish so much with donated spare-time labor...)
Having a 64-bit register doesn't necessarily mean you must work with 64-bit types. You could also operate on eight 8-bit values at once, and see a commersurate speed gain over a narrower system. (remember rep stosb vs. rep stosd, assembly coders?)
This kind of thing already happens on today's systems, thanks to the hordes of Vector Instruction Sets With Silly Names™. In some ways, you could get away with calling a Pentium III with SSE a "128-bit" procesor...
I agree with you in principle, but there are severe problems with today's implementation of patents. Mainly, the time scale is way, way off.
Instead of giving innovative companies a small head-start to recoup their R&D costs, 17-year patents give them a competition-crushing, innovation-stifling monopoly for the entire lifetime of their products.
Consider that if Apple had patented the windowed GUI back in 1985, the patent would still be in effect today. That means not only no Windows as we know it, but no GNOME, no KDE, no BeOS, no 4DWM, etc. Un-licensed GUI efforts would have been utterly stifled until two years from now! I guarantee you that in such a world, graphical interfaces would not have advanced anywhere near where they are today. (Also note that Apple continues to make a hefty profit from its inventions without patent protection)
I say we should return the patent system to its original purpose. Restrict patent terms to half of a product's projected useful lifetime: enough to give companies an incentive to invest in R&D, but not enough to stifle innovation in vital areas. Terms could vary according to the type of patent; I'd have no qualms with, say, two-year software patents, or six-month business model patents.
Dan
There is nothing mutually exclusive about Open Source and charging for the software... For one, you can capitalize on the fact that the vast majority of people wouldn't know what to do with a source tarball if one it them in the face. People want vendor-certified officially-supported pre-compiled software, and they'll pay dearly for that...
Say I write a useful GPL utility for Linux. I make the .tar.gz freely available to whoever wants it. But I charge a nominal fee for downloading an .rpm or a .deb; the price might reflect e.g. similarly capable Windows shareware. If people don't want to pay, they are free to figure out how to compile the thing themselves. But do not underestimate the number of consumers who would rather spend a quick $20 than do battle with your configure script... (note also that only my "blessed" binaries are eligible for tech support/bug tracking...).
*Bought* the SDK? Jeez, even MS gives away its headers, libraries and extensive API docs...
Like the BeOS group, apparently these Amigans are still under the impression that people will pay for a non-Microsoft OS + dev tools. Hah!
Dan
Knock yourself out =)
Anyone know when the Linux driver is coming out? I bought one of these in expectation of dumping my nVidia hardware when the DRI driver becomes available. I heard Precision Insight was working on it, but I'm getting antsy.
Where is the code? Can we actually get a DRI driver for *modern* hardware? Instead of two-year-old pieces of junk like the G400 and Voodoo3?
Dan
You are absolutely right... WAY the hell too much software is written in C/C++ these days. It pains me to browse some of the GNOME sources (not that they are the only guilty party) and see page after page of the repetitive, long-winded, hard-to-read code that inevitably takes over a large ANSI C application.
Unless you are writing something that absolutely MUST be wicked fast (e.g. a game engine), save yourself the trouble and use Python, Perl, or Java. And if something DOES have to be wickedly fast, write that one function in C then plug it into your scripting language... Computers are so fast these days that a GUI application written in Python/Perl/Tcl isn't noticeably slower than one written in C. The speed critical part - the widget library - is probably C, but your application logic still benefits from the nice scripting language features (e.g. first-class function objects/lambdas, which can be emulated in C, but only with many lines of redundant code - try it)
I've always said we need a faster bus than PCI. That puny 100MB/sec bus can't stand up much longer, what with 160MB/sec SCSI and 80MB/sec Gigabit ethernet cards coming into wide use...
Perhaps an entirely USB-based system is the answer. 480MB/sec should be ample bandwidth for tomorrow's PCs (especially if switched). Your basic "system" would be nothing more than a USB backplane, to which you'd attach CPU modules, RAM modules, I/O modules, etc. Thanks to USB's forward-thinking design, neat tricks like adding and removing RAM, graphics cards, and hard drives from a running sytem should be trivially possible...
"It comes out in 2 weeks."
I have a feeling what he meant was, "The other OS ports will be available 2 weeks after the Win32 release."
(The UNIX ports of earlier id software came well after the main release. Quake 3 was released on everything simultaneously, but distributors held back the non-Windows versions)
Um, a "triumph of open source" would be if you fixed it yourself and distributed a patch immediately; no waiting until 1.3, when it may or may not be fixed by Sun...