There's several other options out there, but they're not as nice as these two, IMNSHO...
Both offer project management, class browsing C++, syntax highlighting, etc. KDevelop looks nearly like VisualC++, Code Crusader is more closely modeled after Code Warrior. These decisions dictate code choices.
KDevelop does class browsing in a way much like VisualC++ does. Code Crusader shows classes in a class inheritance tree.
Each of these environments have their own set of problems- you'll need to evaluate their offered functionalities and find out the drawbacks for your purposes and choose accordingly.
There's several other options out there, but they're not as nice as these two, IMNSHO...
Both offer project management, class browsing C++, syntax highlighting, etc. KDevelop looks nearly like VisualC++, Code Crusader is more closely modeled after Code Warrior. These decisions dictate code choices.
KDevelop does class browsing in a way much like VisualC++ does. Code Crusader shows classes in a class inheritance tree.
Each of these environments have their own set of problems- you'll need to evaluate their offered functionalities and find out the drawbacks for your purposes and choose accordingly.
I suspect that commercial interests will skip supporting things other than Linux (which is why I'm against binary only stuff!) and the open source people will work at making sure (or will have someone come along that will) that it works on anything anyone is interested in.
XiG and MetroX may not be interested in doing their stuff for anything other than Linux- but I know that the GLX acceleration project has at least one FreeBSD person working on the Matrox G200 support for *BSD.
Add to that support for the Matrox G400, NVidia TNT2, and several others I'm not quite yet at liberty to mention (Work on these chips have just begun, and I don't want to get false hopes up!)- all with open source code and no black magic that would keep someone from implementing it under *BSD, etc. under any chipset that will work with an adapter.
Seems you got lucky in Texas- I got scanned and there was no option for not getting it (not like they don't already have it; worked for a defense contractor for a time- they already know me probably better than I know myself...:-).
Recognition could be possible with some of the more advanced neural net engines, but you're right, it'd be hard. I think all that's on the stripe is an index id for your info in the state database and an authentication key to certify that the card's not bogus.
Yes, they do have drivers for each card that is different.
But OpenGL is NOT a driver. It's an API that is used to write 3D rendering applications with. It doesn't concern itself with drivers. Under Windows, there's only two different OpenGL layers to muck with- the Win95 one and the WinNT one. With Linux, you've got at least twice to three times as many. What they're asking for here is to make the OpenGL implementations identical as far as calls, behavior, etc. and to provide as common as is possible driver layer API.
The magstripes can't hold more than a couple of hundred bytes. It's got validation info and ID number in it. The rest is pulled from the state databases, I think. A wavelet encoded thumbprint MIGHT fit on there, but there'd be no room for anything else. By the way, Jonathan, did they make you digitize your right thumbprint when you got your last Texas license?
They started digitizing thumbprints lately and the stupid woman at the DMV had the unmitigated gall to tell me that they have ALWAYS taken thumbprints for a Texas license (they never did before) and that the info that they were collecting wouldn't be divulged outside of the Texas government (yeah, riiight- why in the hell are you scanning them then?)
Sadly, the bastards don't even pay attention to us, the people, anymore- they pay attention to the largest purse. Wouldn't do any damn good to write to them.
They don't want to alienate us too much- it could cost them everything. And, as it was put earlier, what in the hell do they propose that we call the distribution, pray tell?
This is not looking good folks. Guess we're going to find out how much Red Hat's going to push things- and how hard we're going to push back...
They've got some really cool stuff (they also have the CardPC which was being seriously considered for wearable use...).
As for power supplies, try the size of a notebook supply (which is all this really is, is a notebook motherboard in a tighter form factor...) Doesn't bulk it up too much and if you factor that these things are intended to be wedged into process control systems that don't have a lot of space but can source the power to the unit, these things are a godsend.
The Parvus corporation is a reseller of these things and they've integrated the CardPC (the predecessor to this new toy) into their PC/104 line. Why do I mention this? Because they're going to be selling a substantial portion of their product line at Fry's to allow anyone interested to do embedded systems easily.
If memory serves they were showing this toy at LWE on the expo floor; it was playing the role of a server... I was suitably impressed. If it weren't for the fact I don't need that much horsepower in a box and I need PC/104 support, I'd be using it. As it is, I've ordered the predecessor, the CardPC and a MightyMite carrier.
GTK+ and Fltk both work cross-platform. Both are under very usable licenses for both proprietary and open sourced projects (unlike Qt...) and are easy to use.
Which is EXACTLY what you've described. And please, while RMS is the guy who kick-started the whole thing, and I appreciate his advice- HE DOES NOT SPEAK FOR EACH AND EVERY ONE OF US.
You still have to pony up the $1200-1500 from what I understand if you're doing ANY Windows development. It's my understanding that the QPL only applies to Linux/UNIX development. If this is the case, then if I want to do true Open Source development (meaning NO restriction on which platform it's running on) I can't use Qt. If the QPL applies to Linux/UNIX use, then using the version under the QPL for Windows development violates the license because it was not licensed for that use under the QPL.
In the case of a GPLed or LGPLed library, I could do Windows development. If you do Windows development with the QPLed version of Qt, you are in violation of the licensing because it's not licensed for that use under Windows. While in the case of the person in question, you're right- the larger case, it's not even CLOSE to acceptable.
Mother nature herself dumped more Chlorine into the upper atmosphere than we did throughout all of Freon's life in one massive eruption of mount Penitubo (SP?) years back. Enough, using the theories given about Freon to eradicate the Ozone layer once and for all- no hole, just no Ozone layer. Guess what- no eradication. No massive enlargement of the "hole". What does that do to the Freon theories? Why did nobody tell you all about this eruption or what it did? Vested interests.
Clue 1: Freon is heavier than air. How in the hell does it get up to the Ozone layer?
Clue 2: The international ban on Freon production goes into effect the very second DuPont's international patents run out on Freon.
In the case of TIFFs, there are alternative formats- ZIP in TIFF is the prominent one. Sounds like to me that this will merely get the companies that are providing TIFF file engines to "standardize" on ZIP in TIFF just to get the monkey off their back.
Try boosting enough fuel up there to move the thing out of orbit- it'd cost as much as it did to put the thing there in the first place. It's cheaper to try to dump it into the ocean.
Some of the stuff we did at Diamond Head Software had that same kind o' feel to it- we did high-end document imaging components so that VB could do insane things like drive a 60ppm document scanner at full speed on a low-end Pentium computer. Some of those controls had...features...
Anyhow, any unofficial word as to when we should be looking for a playable demo from you all? It looks awesome and I'd love to see a Linux demo as soon as it becomes available.
The previous comment is central- if it's true, that Apple failed to file one year after publishing, it's not a valid patent (Even if the USPTO issued one to Apple. The examiners may not have noticed (or even worse, cared) that the deadline had expired on their right to file for patents.).
'That said, graphics performance is critical to games. Unfortunately, Linux support for contemporary Apple graphics hardware, which is based on ATI's Rage Pro and Rage 128 chips, is nonexistent. So I was hugely pleased to hear from ATI last week that it is working with select external developers to create accelerated drivers for PowerPC-based Linux.
Being the paranoid sort, I asked whether ATI would permit the resulting drivers, whose development would be based on detailed -- and presumably NDA'd -- information, to be open source. The answer was a definite "yes." '
I don't know about you all, but it's finally happening- all of the 3D vendors are getting clues by the bushel load and they're making drivers happen.
The closest things that are available are Code Crusader and KDevelop.
There's several other options out there, but they're not as nice as these two, IMNSHO...
Both offer project management, class browsing C++, syntax highlighting, etc. KDevelop looks nearly like VisualC++, Code Crusader is more closely modeled after Code Warrior. These decisions dictate code choices.
KDevelop does class browsing in a way much like VisualC++ does. Code Crusader shows classes in a class inheritance tree.
Each of these environments have their own set of problems- you'll need to evaluate their offered functionalities and find out the drawbacks for your purposes and choose accordingly.
The closest things that are available are Code Crusader and KDevelop.
There's several other options out there, but they're not as nice as these two, IMNSHO...
Both offer project management, class browsing C++, syntax highlighting, etc. KDevelop looks nearly like VisualC++, Code Crusader is more closely modeled after Code Warrior. These decisions dictate code choices.
KDevelop does class browsing in a way much like VisualC++ does. Code Crusader shows classes in a class inheritance tree.
Each of these environments have their own set of problems- you'll need to evaluate their offered functionalities and find out the drawbacks for your purposes and choose accordingly.
I suspect that commercial interests will skip supporting things other than Linux (which is why I'm against binary only stuff!) and the open source people will work at making sure (or will have someone come along that will) that it works on anything anyone is interested in.
XiG and MetroX may not be interested in doing their stuff for anything other than Linux- but I know that the GLX acceleration project has at least one FreeBSD person working on the Matrox G200 support for *BSD.
Add to that support for the Matrox G400, NVidia TNT2, and several others I'm not quite yet at liberty to mention (Work on these chips have just begun, and I don't want to get false hopes up!)- all with open source code and no black magic that would keep someone from implementing it under *BSD, etc. under any chipset that will work with an adapter.
I knew that you're in California. :-)
:-).
Seems you got lucky in Texas- I got scanned and there was no option for not getting it (not like they don't already have it; worked for a defense contractor for a time- they already know me probably better than I know myself...
Recognition could be possible with some of the more advanced neural net engines, but you're right, it'd be hard. I think all that's on the stripe is an index id for your info in the state database and an authentication key to certify that the card's not bogus.
Yes, they do have drivers for each card that is different.
But OpenGL is NOT a driver. It's an API that is used to write 3D rendering applications with. It doesn't concern itself with drivers. Under Windows, there's only two different OpenGL layers to muck with- the Win95 one and the WinNT one. With Linux, you've got at least twice to three times as many. What they're asking for here is to make the OpenGL implementations identical as far as calls, behavior, etc. and to provide as common as is possible driver layer API.
The magstripes can't hold more than a couple of hundred bytes. It's got validation info and ID number in it. The rest is pulled from the state databases, I think. A wavelet encoded thumbprint MIGHT fit on there, but there'd be no room for anything else. By the way, Jonathan, did they make you digitize your right thumbprint when you got your last Texas license?
They started digitizing thumbprints lately and the stupid woman at the DMV had the unmitigated gall to tell me that they have ALWAYS taken thumbprints for a Texas license (they never did before) and that the info that they were collecting wouldn't be divulged outside of the Texas government (yeah, riiight- why in the hell are you scanning them then?)
Sadly, the bastards don't even pay attention to us, the people, anymore- they pay attention to the largest purse. Wouldn't do any damn good to write to them.
Much better....
They don't want to alienate us too much- it could cost them everything . And, as it was put earlier, what in the hell do they propose that we call the distribution, pray tell?
This is not looking good folks. Guess we're going to find out how much Red Hat's going to push things- and how hard we're going to push back...
It's http://www.cellcomputing.com. The link works fine, I just typoed the text for the link.
Hit http://www.cellcomuting.com and follow the stuff from there.
They've got some really cool stuff (they also have the CardPC which was being seriously considered for wearable use...).
As for power supplies, try the size of a notebook supply (which is all this really is, is a notebook motherboard in a tighter form factor...) Doesn't bulk it up too much and if you factor that these things are intended to be wedged into process control systems that don't have a lot of space but can source the power to the unit, these things are a godsend.
The Parvus corporation is a reseller of these things and they've integrated the CardPC (the predecessor to this new toy) into their PC/104 line. Why do I mention this? Because they're going to be selling a substantial portion of their product line at Fry's to allow anyone interested to do embedded systems easily.
If memory serves they were showing this toy at LWE on the expo floor; it was playing the role of a server... I was suitably impressed. If it weren't for the fact I don't need that much horsepower in a box and I need PC/104 support, I'd be using it. As it is, I've ordered the predecessor, the CardPC and a MightyMite carrier.
GTK+ and Fltk both work cross-platform. Both are under very usable licenses for both proprietary and open sourced projects (unlike Qt...) and are easy to use.
GTK+ is available at http://www.gtk.org.
Fltk is available at http://www.fltk.org.
Go check them out. I think you might find what you're looking for there- I know I have.
Which is EXACTLY what you've described. And please, while RMS is the guy who kick-started the whole thing, and I appreciate his advice- HE DOES NOT SPEAK FOR EACH AND EVERY ONE OF US.
You still have to pony up the $1200-1500 from what I understand if you're doing ANY Windows development. It's my understanding that the QPL only applies to Linux/UNIX development. If this is the case, then if I want to do true Open Source development (meaning NO restriction on which platform it's running on) I can't use Qt. If the QPL applies to Linux/UNIX use, then using the version under the QPL for Windows development violates the license because it was not licensed for that use under the QPL.
In the case of a GPLed or LGPLed library, I could do Windows development. If you do Windows development with the QPLed version of Qt, you are in violation of the licensing because it's not licensed for that use under Windows. While in the case of the person in question, you're right- the larger case, it's not even CLOSE to acceptable.
Has nothing to do with Freon.
Mother nature herself dumped more Chlorine into the upper atmosphere than we did throughout all of Freon's life in one massive eruption of mount Penitubo (SP?) years back. Enough, using the theories given about Freon to eradicate the Ozone layer once and for all- no hole, just no Ozone layer. Guess what- no eradication. No massive enlargement of the "hole". What does that do to the Freon theories? Why did nobody tell you all about this eruption or what it did? Vested interests.
Clue 1: Freon is heavier than air. How in the hell does it get up to the Ozone layer?
Clue 2: The international ban on Freon production goes into effect the very second DuPont's international patents run out on Freon.
But do you want to prove it? They could threaten you and you'd have to choke up the $5000 or the effort to exonerate yourself.
Those of the law enforcement profession call this extortion.
In the case of TIFFs, there are alternative formats- ZIP in TIFF is the prominent one. Sounds like to me that this will merely get the companies that are providing TIFF file engines to "standardize" on ZIP in TIFF just to get the monkey off their back.
Try boosting enough fuel up there to move the thing out of orbit- it'd cost as much as it did to put the thing there in the first place. It's cheaper to try to dump it into the ocean.
Some of the stuff we did at Diamond Head Software had that same kind o' feel to it- we did high-end document imaging components so that VB could do insane things like drive a 60ppm document scanner at full speed on a low-end Pentium computer. Some of those controls had...features...
Anyhow, any unofficial word as to when we should be looking for a playable demo from you all? It looks awesome and I'd love to see a Linux demo as soon as it becomes available.
The previous comment is central- if it's true, that Apple failed to file one year after publishing, it's not a valid patent (Even if the USPTO issued one to Apple. The examiners may not have noticed (or even worse, cared) that the deadline had expired on their right to file for patents.).
'That said, graphics performance is critical to games. Unfortunately, Linux support for contemporary Apple graphics hardware, which is based on ATI's Rage Pro and Rage 128 chips, is nonexistent. So I was hugely pleased to hear from ATI last week that it is working with select external developers to create accelerated drivers for PowerPC-based Linux.
Being the paranoid sort, I asked whether ATI would permit the resulting drivers, whose development would be based on detailed -- and presumably NDA'd -- information, to be open source. The answer was a definite "yes." '
I don't know about you all, but it's finally happening- all of the 3D vendors are getting clues by the bushel load and they're making drivers happen.
They're due out shortly and they are powered by Ethanol- imagine something that weighs about 1lb and runs for that 15 hours or more...