The
software requirements require "60 libraries" because "The majority of the GNUCash 1.6.0 dependancies are satisfied by Gnome 1.4".
If major distros don't yet support the libraries of recent software releases, that's fine with me. The push for newer versions should come from bleeding edge software.
Aside from that, I personally commend the code reuse of GNUCash. Functionality needs to be reused as much as possible: We're working alongside giants. Let's stand on each other's shoulders.
I happened to have the mozilla 0.9 and linux kernel 2.4.5 sources on my hard drive. I decided to find out how big they are in comparison of each other. The command I used to test was: xargs cat | find -iname *.[ch] I used a slight modification of that for Mozilla which has.cpp sources. This doesn't even count any of that XUL stuff.
Here are the results:
Linux Kernel 2.4.5: 3,255,122 lines of source
Mozilla 0.9: 3,277,618 lines of source
Mozilla is currently some 22,000 lines of code bigger than the most recent kernel release.
Interesting that the author took the document that was initially available on GNUTella and moved it to the web, which defeats some of the security of having a peer to peer system. This was done, no doubt, for the ease of linkage.
Perhaps it would suit browsers well to have a plugin that queries GNUtella servers based on a URL. gnutella://metallica%20mp3 for instance.
Heh, I bet this keyboard would suck with Dvorak. One of it's goals is to get as many words to be typed with alternating hands as possible to cut down the number of sluggish singlehanded words. This keyboard makes for an extra keypress every time you switch over to the other side of the board.
Alternatively, there is something called the one handed Dvorak method (smirk now). It also allows people to type with one hand, and it can be done on a normal keyboard. What's more, your OS will probably already have software remapping for it. People who have lost the use of an arm and are forced to switch or give up decent typing forever have reported speeds up to 60-70wpm in this configuration.
I'm intrigued by it because of the time it takes me to move my hand from my keyboard to my mouse, and back to home row. But then, I'm awash with small efficiencies. I use dvorak and I'm very handy with emacs keystrokes.
How secure are the CVS trees? I assume sourceforge's CVS trees are backed up regularly. It would be horrendous if not, because any of the cvs trees on SF could have had backdoors added to them.
Perhaps the authors of the programs should check out their software to a different directory and do a diff.
I am happy to say I don't rely on sourceforge. It is a mistake for a large part of the community to rely on one site for this sort of thing. I run my own CVS server, and am about to pay a small amount ($10/m) for an ISP to host my hobbyist code. Granted, it doesn't have all the features of sourceforge, but I don't mind.
Perhaps now is the time to ask if anyone has had the same problem as myself. I'm not sure if it's related to the kernel, to X, or to software that runs under X, but there has been a serious problem with my system for around four months.
So I fire up X, and use it for a while. Within a short amount of time, the screen blanker starts to come on only in X within one second. This usually happens after heavy disk usage, perhaps after a run of mkisofs to create a CD image that I am about to burn. So I say what the hell, and fire up a terminal window and type 'xset off' to kill the blanker.
I decide to fire up a timer based video game. Quake 3 will suffice for an example. I enter a map, and the sky is moving very quickly. I fire a rocket and the explosion blinks at the end of the hallway immediately.
I have written code in the past with SDL's cross platform timer, and however they implement it in Linux is also broken, because code that I have written is no longer timed correctly.
The timing for my machine is broken. The only way I can fix this is to reboot. My system clock is running at a normal speed, and this doesn't happen in Windows 2000. This is a bug in the GNU/Linux system.
I'm going to try the new kernel version, but after reading the changelog, I don't have much hope for 2.4.5.
Has anyone else experienced this? It's VERY troubling.
X -version returns 4.0.2, though I have tested 4.0 and 4.0.1.
uname -r returns 2.4.4, though I have tried every kernel since 2.4.0.
/lib/libc.so.6 returns version 2.1.2 compiled by egcs.
I have a Quadro 2, however I have also tested a TNT2 Ultra.
hdparm is set to DMA on on my IDE drive.
I have an AMD/750 with a VIA chipset.
I'm using the NVidia binary-only drivers, though the problem persists with the stock NVidia drivers that come with XFree (tried 4.0 and 4.0.2)
Sure, a skilled programmer could cheat. It's been possible to look through walls in games since there was access to hack up openGL drivers to add 50% opacity to all surfaces.
This is about cheating for the masses. When users have to click a checkbox to enable a cheat, there is bound to be more cheaters because it is more accessible. In that respect, Asus opened the door to something new and bad.
Re:Little Known DOOM Feature
on
PanQuake
·
· Score: 4
People are calling this a troll. It did exist. Id took it out after Doom 1.1 when modem multiplayer (sersetup) was added in 1.2. It was never put back in, and no explanation was given.
Get a copy of Doom 1.1 (I'm not sure if the original 1.0 had it) if you want to try this.
Or, join a q1 server with a second machine and spectate third person, 180 degrees inverted.
I run debian on three other machines because of it's low maintenance packaging system. However, I like to configure my workstation system from scratch. Thanks for coming out.
The problem with Quake bots as an AI challenge is that you can give them perfect aim, making the challenge into one of who has the best gun when, which could then break down into deathmatch spawn points.
Also, it's impossible with Q3 to get clientside bots to connect to the server as the protocol is unknown. You'd have to edit the DLL source that Id released, and getting two bots in one source tree is more than a whim.
I would like to see an environment where the hardships in overcoming it would all lie on the programmer instead of a user, like with Quake's aiming. The general idea would be to have every decision be one of the type of 'no best answer' as opposed to Quake's aiming 'there is a best answer', at least for every hitscan weapon.
I don't use KDE, but I wouldn't mind entering this contest. My graphics tools haven't been used as much recently as I would have liked to use them.
So I ask you KDE users, what's the quickest way to get an install up and running? I have Slackware 7 with WindowMaker running and, hey, I've even got a fairly recent version of QT compiled.
I don't need a completely usable install, and I'll probably want to delete it afterwards, as I'm quite happy with the performance of my system at the moment. I just want to be able to test my theme out. Whadya say?
The original Legend Of Zelda was the game that got me into programming, or more specifically, game programming. The game itself was exciting and gave me a great feeling of vastness and it's engine (not that I called it that when I was seven) seemed the perfect way to describe a world.
I immediately started using my shallow C64 BASIC knowledge to imitate the gameplay, and by the time I was eight, I had a little graphic walking around a screen.
That's as far as it went back then, but even to this day, the key game design document that I want to create one day is strongly influenced by Zelda.
As a coincidence, my Zelda 1 cartridge that I ordered from E-Bay happened to arrive to my house this morning.
I originally started using SDL when I was seeking out a replacement for GLUT back in the SDL 1.0 days when I was starting to learn OpenGL. After a bit of playing around I found that that functionality was only available in the 1.1 dev series (1.2 as of last month!).
I believe I stumbled on something truly great. I've made small toys that compile in Windows with Visual C++ (gotta pay the bills, game developers) and in a GNU/Linux environment.
There is a lot of focus on the fact that SDL gives you low level access to a framebuffer. It's input handling routines should also be mentioned. Take a look af the port of Quake to SDL. The mouse and keyboard are handled quite well.
I examined the SDLQuake source code, and figured out how Sam got Quake style movement with SDL. I then used that to create a basic "framework" for OpenGL scenes. SDL lets me write easily cross platform code for moving around a scene Quake-style, which you couldn't do with the limited input commands that Glut gives you. Not bad for small experiments.
My only beef with this library so far is that major game companies don't use this tech in house as a replacement for DirectX (which it wraps around if it's available in Win32 anyway).
Back in highschool when I was in a particularly goof-off mood, a friend of mine called me "a piece of texas toast" as an insult. I hesitated for a second, then spun around to the nearest search engine and typed it in to find out what it was. It came up dry, except for a restaurant named, you guessed it, Texas Toast.
Loki is going to be releasing Tribes 2 in the nearish future. They're trying their darndest to get VoIP in the package as well. I am certainly going to wait for the Linux version (as I did with Quake 3) even though I'm only mildly excited about the game.
Sure, we have OpenGL, but with the release of DirectX 8, the cross-platform API just doesn't cut it anymore. Lacking universal support for vertex and pixel shaders, developers are forced into the situation where they can either reduce the quality of their titles by ignoring the improved features that the newer releases of DirectX offer, or by ignoring Linux.
OpenGL extensions ARE a viable way to access the pixel shaders. For game programming, a lot of the OpenGL API is obsolete. Using glLight* calls to light a scene is just not done. People commonly prefer to use GL_ARB_MULTITEXTURE and blend another texture pass with lighting.
Likewise, the GL calls for the new pixel shaders are reputedly supported by the Nvidia drivers under Linux already. John Carmack stated that when Doom 3 comes out, it's going to only work with all it's features under Nvidia's drivers. However, he's going to lend some code to get the other drivers for the operating system up to speed.
OpenGL is not a lost cause. Dx8 is getting a lot of hype right now. Lots of developers are preferring it because, imo, Microsoft has very timely, large and helpful responses to game develpers, whereas OpenGL has to also cater to those CAD guys.
For a list and description of all the OpenGL extensions, see
this URL.
I started downloading this. Then, I realised that I don't know who I'm getting it from, or what could have been changed in the source tree. Sorry Diclophis, next time sign the archive with GPG so people like myself can download it.
I grew up to Double Dragon, Pole Position and Super Sprint. If I wasn't so damned young, I would have spent even more money on those games. As it stood, I would go very far out of my way to play those arcade games. In the time when the NES regined, they had SNES quality graphics. The games seemed to be about the most exciting around.
Fast forward to any time in the last five years. Arcade games can be broken down into three categories, in my experiences: Racing, Shooting (gun to monitor) and fighting. It's my experience that when the gaming industry finds a hit, it takes years to recover, and it's a damned shame. I believe the gaming industry (as well as other industries) calls this phenomenon "genres".
After Street Fighter 2, for instance, most arcades became a waste of wood and paint with all the cloned games out there. I remember games like NeoGeo's Fatal Fury adding a few new features to the gametype and calling it a day. Some say Mortal Kombat came close, but let's face it. The game lost out big because there was no real decent aerial action compared to Street Fighter with the likes of Vega and Ryu/Ken's Shoryuken attacks.
I'd like to see a truly original game for arcade systems. As for the newer arcade games out there today, well, goodbye. We never really loved you.
Interesting find. Perhaps straight anti aliasing isn't the best solution. I haven't used QT or seen this anti-aliasing is action, but perhaps it would be best to increase the pixels intensity after anti aliasing them so that the brightness of the source colour would be visible in the most intense part of the destination anti aliased text.
I've heard BeOS has an implementation of a feature that's been around for a relatively long time. It dumps all of the system's memory to the disk on shutdown, and then just reads it when you boot up again.
I don't know much about what has or has not done- low level OS stuff hasn't really been an interest of mine, but I do know the way fork() works in GNU/Linux. With fork() in this environment, you don't actually do a copy of the entire data segment of the program, you just reference it and make copies of each bit as it's needed. Would it not be possible to do this upon booting of a BeOS system? ( and of course any other operating system that implements the system memory dump feature)
It seems to me that you'd only have to boot the very core features and just load the rest off the memory dump on the drive as you need them, as opposed to reading the whole thing on startup.
I've seen a few posts to this story that seem like they assume a computer with more memory would take longer to boot up with the RAM-image system. This way wouldn't. However, it would give you more sluggish performance. It might make other things feasible, like 'undoing' your system back to a certain state (although you'd have to consider data persistance because you couldn't undo changes that have already been written to storage devices)
Storage space per square cm always make me think of the same thing: What happens when there is a nanoscratch on the surface of my 18 terabytes-in-twelve-centimeter storage medium?
Tighter storage media also needs to safeguard the data on it better. Heaven help us all when we back up all our word processor documents to a tenth of a millimeter and a fly sneezes on it.
Slashdot Mirror
The software requirements require "60 libraries" because "The majority of the GNUCash 1.6.0 dependancies are satisfied by Gnome 1.4".
If major distros don't yet support the libraries of recent software releases, that's fine with me. The push for newer versions should come from bleeding edge software.
Aside from that, I personally commend the code reuse of GNUCash. Functionality needs to be reused as much as possible: We're working alongside giants. Let's stand on each other's shoulders.
\\\ SLUDGE
I can second this with the same board. Do not buy a used KA-7 Board for an Athlon.
\\\ SLUDGE
I happened to have the mozilla 0.9 and linux kernel 2.4.5 sources on my hard drive. I decided to find out how big they are in comparison of each other. The command I used to test was: xargs cat | find -iname *.[ch] I used a slight modification of that for Mozilla which has .cpp sources. This doesn't even count any of that XUL stuff.
Here are the results:
Mozilla is currently some 22,000 lines of code bigger than the most recent kernel release.
Holy hell that's a large project.
\\\ SLUDGE
Interesting that the author took the document that was initially available on GNUTella and moved it to the web, which defeats some of the security of having a peer to peer system. This was done, no doubt, for the ease of linkage.
Perhaps it would suit browsers well to have a plugin that queries GNUtella servers based on a URL. gnutella://metallica%20mp3 for instance.
\\\ SLUDGE
Heh, I bet this keyboard would suck with Dvorak. One of it's goals is to get as many words to be typed with alternating hands as possible to cut down the number of sluggish singlehanded words. This keyboard makes for an extra keypress every time you switch over to the other side of the board.
Alternatively, there is something called the one handed Dvorak method (smirk now). It also allows people to type with one hand, and it can be done on a normal keyboard. What's more, your OS will probably already have software remapping for it. People who have lost the use of an arm and are forced to switch or give up decent typing forever have reported speeds up to 60-70wpm in this configuration.
I'm intrigued by it because of the time it takes me to move my hand from my keyboard to my mouse, and back to home row. But then, I'm awash with small efficiencies. I use dvorak and I'm very handy with emacs keystrokes.
How secure are the CVS trees? I assume sourceforge's CVS trees are backed up regularly. It would be horrendous if not, because any of the cvs trees on SF could have had backdoors added to them.
Perhaps the authors of the programs should check out their software to a different directory and do a diff.
I am happy to say I don't rely on sourceforge. It is a mistake for a large part of the community to rely on one site for this sort of thing. I run my own CVS server, and am about to pay a small amount ($10/m) for an ISP to host my hobbyist code. Granted, it doesn't have all the features of sourceforge, but I don't mind.
So I fire up X, and use it for a while. Within a short amount of time, the screen blanker starts to come on only in X within one second. This usually happens after heavy disk usage, perhaps after a run of mkisofs to create a CD image that I am about to burn. So I say what the hell, and fire up a terminal window and type 'xset off' to kill the blanker.
I decide to fire up a timer based video game. Quake 3 will suffice for an example. I enter a map, and the sky is moving very quickly. I fire a rocket and the explosion blinks at the end of the hallway immediately.
I have written code in the past with SDL's cross platform timer, and however they implement it in Linux is also broken, because code that I have written is no longer timed correctly.
The timing for my machine is broken. The only way I can fix this is to reboot. My system clock is running at a normal speed, and this doesn't happen in Windows 2000. This is a bug in the GNU/Linux system.
I'm going to try the new kernel version, but after reading the changelog, I don't have much hope for 2.4.5.
Has anyone else experienced this? It's VERY troubling.
X -version returns 4.0.2, though I have tested 4.0 and 4.0.1.
uname -r returns 2.4.4, though I have tried every kernel since 2.4.0.
/lib/libc.so.6 returns version 2.1.2 compiled by egcs.
I have a Quadro 2, however I have also tested a TNT2 Ultra.
hdparm is set to DMA on on my IDE drive.
I have an AMD/750 with a VIA chipset.
I'm using the NVidia binary-only drivers, though the problem persists with the stock NVidia drivers that come with XFree (tried 4.0 and 4.0.2)
My distro is Slackware 7.0.
Sure, a skilled programmer could cheat. It's been possible to look through walls in games since there was access to hack up openGL drivers to add 50% opacity to all surfaces.
This is about cheating for the masses. When users have to click a checkbox to enable a cheat, there is bound to be more cheaters because it is more accessible. In that respect, Asus opened the door to something new and bad.
People are calling this a troll. It did exist. Id took it out after Doom 1.1 when modem multiplayer (sersetup) was added in 1.2. It was never put back in, and no explanation was given.
Get a copy of Doom 1.1 (I'm not sure if the original 1.0 had it) if you want to try this.
Or, join a q1 server with a second machine and spectate third person, 180 degrees inverted.
I run debian on three other machines because of it's low maintenance packaging system. However, I like to configure my workstation system from scratch. Thanks for coming out.
The problem with Quake bots as an AI challenge is that you can give them perfect aim, making the challenge into one of who has the best gun when, which could then break down into deathmatch spawn points.
Also, it's impossible with Q3 to get clientside bots to connect to the server as the protocol is unknown. You'd have to edit the DLL source that Id released, and getting two bots in one source tree is more than a whim.
I would like to see an environment where the hardships in overcoming it would all lie on the programmer instead of a user, like with Quake's aiming. The general idea would be to have every decision be one of the type of 'no best answer' as opposed to Quake's aiming 'there is a best answer', at least for every hitscan weapon.
I don't use KDE, but I wouldn't mind entering this contest. My graphics tools haven't been used as much recently as I would have liked to use them.
So I ask you KDE users, what's the quickest way to get an install up and running? I have Slackware 7 with WindowMaker running and, hey, I've even got a fairly recent version of QT compiled.
I don't need a completely usable install, and I'll probably want to delete it afterwards, as I'm quite happy with the performance of my system at the moment. I just want to be able to test my theme out. Whadya say?
- Black and White
- Diablo 2
- FAKK 2 (well, that was last summer)
- Counterstrike
I'd have to say that there have been some good games out there.The original Legend Of Zelda was the game that got me into programming, or more specifically, game programming. The game itself was exciting and gave me a great feeling of vastness and it's engine (not that I called it that when I was seven) seemed the perfect way to describe a world.
:)
I immediately started using my shallow C64 BASIC knowledge to imitate the gameplay, and by the time I was eight, I had a little graphic walking around a screen.
That's as far as it went back then, but even to this day, the key game design document that I want to create one day is strongly influenced by Zelda.
As a coincidence, my Zelda 1 cartridge that I ordered from E-Bay happened to arrive to my house this morning.
Pardon this self indulgence of reminsence...
A bit rambling, but hang on...
I originally started using SDL when I was seeking out a replacement for GLUT back in the SDL 1.0 days when I was starting to learn OpenGL. After a bit of playing around I found that that functionality was only available in the 1.1 dev series (1.2 as of last month!).
I believe I stumbled on something truly great. I've made small toys that compile in Windows with Visual C++ (gotta pay the bills, game developers) and in a GNU/Linux environment.
There is a lot of focus on the fact that SDL gives you low level access to a framebuffer. It's input handling routines should also be mentioned. Take a look af the port of Quake to SDL. The mouse and keyboard are handled quite well.
I examined the SDLQuake source code, and figured out how Sam got Quake style movement with SDL. I then used that to create a basic "framework" for OpenGL scenes. SDL lets me write easily cross platform code for moving around a scene Quake-style, which you couldn't do with the limited input commands that Glut gives you. Not bad for small experiments.
My only beef with this library so far is that major game companies don't use this tech in house as a replacement for DirectX (which it wraps around if it's available in Win32 anyway).
So yes, I have found a hole in the Internet.
Loki is going to be releasing Tribes 2 in the nearish future. They're trying their darndest to get VoIP in the package as well. I am certainly going to wait for the Linux version (as I did with Quake 3) even though I'm only mildly excited about the game.
OpenGL extensions ARE a viable way to access the pixel shaders. For game programming, a lot of the OpenGL API is obsolete. Using glLight* calls to light a scene is just not done. People commonly prefer to use GL_ARB_MULTITEXTURE and blend another texture pass with lighting.
Likewise, the GL calls for the new pixel shaders are reputedly supported by the Nvidia drivers under Linux already. John Carmack stated that when Doom 3 comes out, it's going to only work with all it's features under Nvidia's drivers. However, he's going to lend some code to get the other drivers for the operating system up to speed.
OpenGL is not a lost cause. Dx8 is getting a lot of hype right now. Lots of developers are preferring it because, imo, Microsoft has very timely, large and helpful responses to game develpers, whereas OpenGL has to also cater to those CAD guys.
For a list and description of all the OpenGL extensions, see this URL.
I started downloading this. Then, I realised that I don't know who I'm getting it from, or what could have been changed in the source tree. Sorry Diclophis, next time sign the archive with GPG so people like myself can download it.
I grew up to Double Dragon, Pole Position and Super Sprint. If I wasn't so damned young, I would have spent even more money on those games. As it stood, I would go very far out of my way to play those arcade games. In the time when the NES regined, they had SNES quality graphics. The games seemed to be about the most exciting around.
Fast forward to any time in the last five years. Arcade games can be broken down into three categories, in my experiences: Racing, Shooting (gun to monitor) and fighting. It's my experience that when the gaming industry finds a hit, it takes years to recover, and it's a damned shame. I believe the gaming industry (as well as other industries) calls this phenomenon "genres".
After Street Fighter 2, for instance, most arcades became a waste of wood and paint with all the cloned games out there. I remember games like NeoGeo's Fatal Fury adding a few new features to the gametype and calling it a day. Some say Mortal Kombat came close, but let's face it. The game lost out big because there was no real decent aerial action compared to Street Fighter with the likes of Vega and Ryu/Ken's Shoryuken attacks.
I'd like to see a truly original game for arcade systems. As for the newer arcade games out there today, well, goodbye. We never really loved you.
Interesting find. Perhaps straight anti aliasing isn't the best solution. I haven't used QT or seen this anti-aliasing is action, but perhaps it would be best to increase the pixels intensity after anti aliasing them so that the brightness of the source colour would be visible in the most intense part of the destination anti aliased text.
I don't know much about what has or has not done- low level OS stuff hasn't really been an interest of mine, but I do know the way fork() works in GNU/Linux. With fork() in this environment, you don't actually do a copy of the entire data segment of the program, you just reference it and make copies of each bit as it's needed. Would it not be possible to do this upon booting of a BeOS system? ( and of course any other operating system that implements the system memory dump feature)
It seems to me that you'd only have to boot the very core features and just load the rest off the memory dump on the drive as you need them, as opposed to reading the whole thing on startup.
I've seen a few posts to this story that seem like they assume a computer with more memory would take longer to boot up with the RAM-image system. This way wouldn't. However, it would give you more sluggish performance. It might make other things feasible, like 'undoing' your system back to a certain state (although you'd have to consider data persistance because you couldn't undo changes that have already been written to storage devices)
Just some food for thought.
Tighter storage media also needs to safeguard the data on it better. Heaven help us all when we back up all our word processor documents to a tenth of a millimeter and a fly sneezes on it.
Apollogies if this was on slashdot already, I must have missed it.
My URL went sour. Sorry. You can check out The Hunz here.