From what it looks like, the alpha channel was controlled by an xresource or some property on an ap by app basis. But they don't tell if they actually made an extension to the X protocal to implement this or if it's just a server side thing. And if it is an actual laid out protocal extension.....who's the first to make XF86 4.0 module to implement it!?
From what I've seen, most mpeg programs now use the SMPEG library (except for those that implement the codec internally). The way things are going, that'll probably be the standard. Now if only distributions would include it....
The post shows complete understanding of what you just said. He didn't want to make it lgpl just because it was a library but because he thinks that a closed source program like a game should be able to use it without opening the code. Personally, although I support the GPL, I don't think that binaries linking to a piece of code should be a derivative work, but I'm not GNU so I don't call that shot.
no that just gives you an app switcher in a menu bar at the top, and the "foo bar" built into gnome 1.1 already does that.
What this guy is asking about is something that actually takes the menubar from the application currently in the foreground, being as it's already tearable, and puts it in the menubar at the top of the screen. I'd kind of like this feature too but it would be somewhat hard to do. There would either have to be some kind of communication between all running apps and a menupanel (possibly through ORBit, though that would mean making ALL gnome apps have to link to libORBit, which they currently aren't, breaking binary compatibility) or have the apps themselves put their menubar up there, which introduces problems when one program freezes up taking control of the menubar (since there's no menubar program to reliquish its control) and it also means that libgnomeui needs to know how to deal with the WM hints which previously only a couple applets had to deal with (ie, bloat). Either way it'll take large changes to libgnomeui. I guess the best way would be to just go with the menupanel thing and save that feature for gnome 2.0, since you're going to need to break binary compatibility anyways...
This looks fairly nice, I haven't tried it personally but if its as close to VC++ as they say it is then its probably a decent interface to program in. I won't use it though. No matter how nice they make the editors/class browsers/project managers all these ides seem to slack on the debugger. They always have what looks like just a little arrow in the source window that follows the output of gdb, maybe a table of variables, maybe breakpoints. Nothing else. No real use of the power an integrated environment like this COULD give them. The best debugger I have ever used (on any platform) is the Data Display Debugger. I've made a few converts to unix just by showing people what this thing could do. And no I'm not affiliated with the developers of this in any way, I just like the thing. So for me it's still going to be vim/xemacs (depending on my mood) ddd and a makefile for my devel environment.
Not exactly. Devices already look like files (thats part of the whole UNIX thing that we all know and love). This is basically a virtual filesystem (kind of like/proc) that gets mounted on/dev that has all the device files for the devices in your system in it and no more. This means no more mknoding when you add a new device to your system and no more random cruft in/dev (like hdg27) to confuse programs. There was some concern a long time ago about performance but the fact that the device lookup table is smaller and the fact that the device files no longer have anything on the harddrive to represent them (ie no hard drive lookup to find the major and minor num) more than makes up for the dynamic creation of the devices. Only problem I had heard of was maintaining the permissions on the devices after a reboot (since theres nothing written to disk there's nothing preserved), and someone said this was going to be done with a userspace daemon. But oh well. There was also bitching about straying from the unix standards, but personally I think this is outdoing the unix standard and is a feature that could push linux past the status of being a "unix-like os". Ok I've babled enough.
Even though this processor was designed for mobile use, couldn't you take this wonderfull vliw 1 watt low heat disipation processor core and just....up the juice on it? I mean an athlon uses what 30 watts (or something ridiculous like that), what clock speed do you think it would run at if you took it down to 1 watt. Is this 700 mhz processor possibly overclockable? (I don't know much about processor design...I'm purely a software geek)
No...the overhead isn't in the fact that the for loop is used. The overhead is in the fact that in a language like this guy describes, A and B aren't necesarily always arrays. They may be normal integers. And the compiler doesn't know, this is determined at runtime. If the compiler did know then most of the benifit of the logic model in this new language is useless, all it is is a typing shortcut (ala myInt++ as apposed to myInt = myInt +1....just a convenience thing). Since this is runtime determined, the code generated by this compiler ether uses a for loop whether you need it or not, wasting cycles on the vast majority of additions which are single numbers, or it determines whether it needs the for loop before hand with an if statement, wasting cycles all around. Abstraction does have a price.
AHA! I knew it! Newton really is the true Messiah! No one believed me when I said that someone who could singlehandedly figure out all the laws of mechanics (within one frame of reference, yes...but still), invent higher math, and still have time to insert razors in his eye has to have some sort of divine intervention.....
You don't need to worry about the afterspin. You don't need to worry about the spin at all. If all you were using the beads for was to keep the user from moving when he walks then all you'd need for the computer to generate walking data would be a pressure sensor on each bead to tell whether the user is standing on it. From that alone you can tell if the user is walking (and an on/off switch for each bead is alot easier to keep track of than a velocity vector for each). Also in response to the momentum correction that all humans do instinctively, just have them be fixed at the body's pivot point, the waist. That way you get full upper body movement for all sorts of user interaction (most consious forms of interaction are done above the waist...below the waist is almost solely for walking)...this will however keep the user from being able to duck, but I don't know how that would be sensed anyways. As for inner ear acceleration/deceleration problem, just tilt the whole assembly. The inner ear is used by the brain to sense both angle in relation to the ground and accel/decel. Thats because angle is really just sensing the accel due to gravity. The computer could take the accel due to gravity of what ever angle the terrain was at, add it to the accel of the moving person, and then set the angle of the machine to simulate that. And whoever said that you can't simulate decel, bullshit. Just tilt them forward. The only problem you have is total accel exceeding 1g, which I doubt is going to happen.
First of all, winelib and wine are the same project. The "emulator" that is wine is just a loader for windows binaries (pretty much just hacks windows symbols to look like elf symbols) and then links it with winelib, the reimplementation of the windows apis. Thats why you can't run this "emulator" on non-intel machines. It's not emulating anything. Thats also why programs run at full speed (no emulation overhead)
Second. Don't make accusations about the project unless you've tried it seriously. Virtually all win3.1 apis work now. Win95 and WinNT are fairly close, so a "lets do this...then this" approach is not that great an idea. Second, from what I've seen, just about everything win32 thats not network related works (or is at least usable). I admit, I haven't found many winsock programs that work....but they're making more progress than anyone ever has in this area, even though this is completely cleanroom (unlike alot of others like the OS/2 win emulator).
Wine won't work for that. AOL uses some strange proprietary tcp/ip driver, but someone has reversed engineered it. I haven't tried it (I just saw it on freshmeat) but its worth a try.
Ok, yes, Intel put wierd liscencing terms on the slot 1 so no one could use it. But it did that for Socket370 too. Socket370 is a socket they came up with for celerons and future socket chips. The pentium pro went in the socket 8 (which was also under strange liscencing terms). AMD's former chips (the k6-2s and 3s) went in what they called the super socket 7 which was the 66mhz socket 7 used in pentiums raised to 100mhz (thank you via). The slot A is nothing at all like the slot 1 because it doesn't use intels GTL+ bus. They worked with digita^H^H^H^H^H^HCompaq to move the EV6 (alpha 21264) bus to an x86 compatible chipset. Which is where a good deal of their speed comes from (200mhz bus, better general architecture of the bus (especially for smp)). As for whether other companies can make slot A chips? I don't know...it depends on how compaq liscenced it to amd.
As for the music scene (while the 9:30 club is cool, and there's nothing like hfstival ANYWHERE), you're ignoring the local music scene. The D.C. Ska scene has been thriving for years, the dc hardcore scene is getting tons of attention now, and we've got the Maryland punk scene to draw off of. Oh, and I know how you feel. I'm stuck in Blacksburg at the moment.
Umm....the voodoo3 does support 32 bit color.....if it only supported 16 bit color that would be kind of extreme.....it doesn't support 32 bit TEXTURES!!!! much less important....its still rendered in 32 bit color....
Does this mean that the information from gnome hints will actually interact with those from kde hints? I mean, if you're running gnome with enlightenment and need the gnome hints (say for gnome pager) but instead of gmc you want to run kfm (which needs kde hints) would it work?
PS. Even though I've programmed gnome stuff before I've never even TOUCHED window manager stuff so if I don't know what I'm talking about......be nice....
First....where is linux's smp heading? 2.2 gave us major changes in that area.....any more comming with 2.4?
Second....how is the new quicker release cycle going to affect kernel development in your opinion? Is it going to slow down/speed up anything? Or is it just so suits realise that development IS being done....
Third....how is the whole linux-on-sgi thing going? You were originally the guy behind that....what's your opinion on the sgi embracing linux stuff happening now?
Hey, could this in any way signal the return of OS/2 PPC edition? I was really pissed at IBM when they dropped that system. I was actually ready to switch to a mac if they'd have a decent system on it (macos doesn't count). That was before the linuxppc days.
I agree. I had some fears about this movie (and the Anakin choice) but after reading that new screenplay I really have hope for this. And strangely enough, the way this one is set up, Anakin could probably pull this off.
exactly his point.....you have to do it yourself if the program package didn't do it.....its ALWAYS the program packager's responsibility to notify the OS which executable runs the app.....
Re:No X -- we need a media-savvy, compositing GUI
on
Is X The Future?
·
· Score: 1
Its not that its that hard to look things up in a manual, if you're not scared of your computer. You forget that half the users out there see the words "video chipset" and what registers in their mind is "something I don't understand and can possibly break". Yes people are stupid. We know. Thats why we have computers to pick up the slack for them. Why do we even need to rely on the stupidity of people when the information is right there in the hardware (dpmi for monitors, device identifiers for video cards (and yes I know, don't talk, code.....I'm working up to that:))
Another VaTech CS major here....the wierd thing is that in my two years here so far I've managed to actually have a social life outside of the CS department but never meet anyone in any of my classes....and you are right....there are cute CS girls....they just generally don't bother with CS guys....
Slashdot Mirror
no....hurd is a full kernel based off of mach. Its mach and a collection of servers that make a working system.
From what it looks like, the alpha channel was controlled by an xresource or some property on an ap by app basis. But they don't tell if they actually made an extension to the X protocal to implement this or if it's just a server side thing. And if it is an actual laid out protocal extension.....who's the first to make XF86 4.0 module to implement it!?
From what I've seen, most mpeg programs now use the SMPEG library (except for those that implement the codec internally). The way things are going, that'll probably be the standard. Now if only distributions would include it....
The post shows complete understanding of what you just said. He didn't want to make it lgpl just because it was a library but because he thinks that a closed source program like a game should be able to use it without opening the code. Personally, although I support the GPL, I don't think that binaries linking to a piece of code should be a derivative work, but I'm not GNU so I don't call that shot.
no that just gives you an app switcher in a menu bar at the top, and the "foo bar" built into gnome 1.1 already does that.
What this guy is asking about is something that actually takes the menubar from the application currently in the foreground, being as it's already tearable, and puts it in the menubar at the top of the screen. I'd kind of like this feature too but it would be somewhat hard to do. There would either have to be some kind of communication between all running apps and a menupanel (possibly through ORBit, though that would mean making ALL gnome apps have to link to libORBit, which they currently aren't, breaking binary compatibility) or have the apps themselves put their menubar up there, which introduces problems when one program freezes up taking control of the menubar (since there's no menubar program to reliquish its control) and it also means that libgnomeui needs to know how to deal with the WM hints which previously only a couple applets had to deal with (ie, bloat). Either way it'll take large changes to libgnomeui.
I guess the best way would be to just go with the menupanel thing and save that feature for gnome 2.0, since you're going to need to break binary compatibility anyways...
This looks fairly nice, I haven't tried it personally but if its as close to VC++ as they say it is then its probably a decent interface to program in. I won't use it though. No matter how nice they make the editors/class browsers/project managers all these ides seem to slack on the debugger. They always have what looks like just a little arrow in the source window that follows the output of gdb, maybe a table of variables, maybe breakpoints. Nothing else. No real use of the power an integrated environment like this COULD give them. The best debugger I have ever used (on any platform) is the Data Display Debugger. I've made a few converts to unix just by showing people what this thing could do. And no I'm not affiliated with the developers of this in any way, I just like the thing. So for me it's still going to be vim/xemacs (depending on my mood) ddd and a makefile for my devel environment.
Not exactly. Devices already look like files (thats part of the whole UNIX thing that we all know and love). This is basically a virtual filesystem (kind of like /proc) that gets mounted on /dev that has all the device files for the devices in your system in it and no more. This means no more mknoding when you add a new device to your system and no more random cruft in /dev (like hdg27) to confuse programs. There was some concern a long time ago about performance but the fact that the device lookup table is smaller and the fact that the device files no longer have anything on the harddrive to represent them (ie no hard drive lookup to find the major and minor num) more than makes up for the dynamic creation of the devices. Only problem I had heard of was maintaining the permissions on the devices after a reboot (since theres nothing written to disk there's nothing preserved), and someone said this was going to be done with a userspace daemon. But oh well. There was also bitching about straying from the unix standards, but personally I think this is outdoing the unix standard and is a feature that could push linux past the status of being a "unix-like os". Ok I've babled enough.
Even though this processor was designed for mobile use, couldn't you take this wonderfull vliw 1 watt low heat disipation processor core and just....up the juice on it? I mean an athlon uses what 30 watts (or something ridiculous like that), what clock speed do you think it would run at if you took it down to 1 watt. Is this 700 mhz processor possibly overclockable? (I don't know much about processor design...I'm purely a software geek)
No...the overhead isn't in the fact that the for loop is used. The overhead is in the fact that in a language like this guy describes, A and B aren't necesarily always arrays. They may be normal integers. And the compiler doesn't know, this is determined at runtime. If the compiler did know then most of the benifit of the logic model in this new language is useless, all it is is a typing shortcut (ala myInt++ as apposed to myInt = myInt +1....just a convenience thing). Since this is runtime determined, the code generated by this compiler ether uses a for loop whether you need it or not, wasting cycles on the vast majority of additions which are single numbers, or it determines whether it needs the for loop before hand with an if statement, wasting cycles all around. Abstraction does have a price.
got it here
AHA! I knew it! Newton really is the true Messiah! No one believed me when I said that someone who could singlehandedly figure out all the laws of mechanics (within one frame of reference, yes...but still), invent higher math, and still have time to insert razors in his eye has to have some sort of divine intervention.....
You don't need to worry about the afterspin. You don't need to worry about the spin at all. If all you were using the beads for was to keep the user from moving when he walks then all you'd need for the computer to generate walking data would be a pressure sensor on each bead to tell whether the user is standing on it. From that alone you can tell if the user is walking (and an on/off switch for each bead is alot easier to keep track of than a velocity vector for each). Also in response to the momentum correction that all humans do instinctively, just have them be fixed at the body's pivot point, the waist. That way you get full upper body movement for all sorts of user interaction (most consious forms of interaction are done above the waist...below the waist is almost solely for walking)...this will however keep the user from being able to duck, but I don't know how that would be sensed anyways. As for inner ear acceleration/deceleration problem, just tilt the whole assembly. The inner ear is used by the brain to sense both angle in relation to the ground and accel/decel. Thats because angle is really just sensing the accel due to gravity. The computer could take the accel due to gravity of what ever angle the terrain was at, add it to the accel of the moving person, and then set the angle of the machine to simulate that. And whoever said that you can't simulate decel, bullshit. Just tilt them forward. The only problem you have is total accel exceeding 1g, which I doubt is going to happen.
First of all, winelib and wine are the same project. The "emulator" that is wine is just a loader for windows binaries (pretty much just hacks windows symbols to look like elf symbols) and then links it with winelib, the reimplementation of the windows apis. Thats why you can't run this "emulator" on non-intel machines. It's not emulating anything. Thats also why programs run at full speed (no emulation overhead)
Second. Don't make accusations about the project unless you've tried it seriously. Virtually all win3.1 apis work now. Win95 and WinNT are fairly close, so a "lets do this...then this" approach is not that great an idea. Second, from what I've seen, just about everything win32 thats not network related works (or is at least usable). I admit, I haven't found many winsock programs that work....but they're making more progress than anyone ever has in this area, even though this is completely cleanroom (unlike alot of others like the OS/2 win emulator).
Wine won't work for that. AOL uses some strange proprietary tcp/ip driver, but someone has reversed engineered it. I haven't tried it (I just saw it on freshmeat) but its worth a try.
Go to http://www.foo.org/james/aol/aolip.html
Ok, yes, Intel put wierd liscencing terms on the slot 1 so no one could use it. But it did that for Socket370 too. Socket370 is a socket they came up with for celerons and future socket chips. The pentium pro went in the socket 8 (which was also under strange liscencing terms). AMD's former chips (the k6-2s and 3s) went in what they called the super socket 7 which was the 66mhz socket 7 used in pentiums raised to 100mhz (thank you via). The slot A is nothing at all like the slot 1 because it doesn't use intels GTL+ bus. They worked with digita^H^H^H^H^H^HCompaq to move the EV6 (alpha 21264) bus to an x86 compatible chipset. Which is where a good deal of their speed comes from (200mhz bus, better general architecture of the bus (especially for smp)). As for whether other companies can make slot A chips? I don't know...it depends on how compaq liscenced it to amd.
Joe
As for the music scene (while the 9:30 club is cool, and there's nothing like hfstival ANYWHERE), you're ignoring the local music scene. The D.C. Ska scene has been thriving for years, the dc hardcore scene is getting tons of attention now, and we've got the Maryland punk scene to draw off of. Oh, and I know how you feel. I'm stuck in Blacksburg at the moment.
Umm....the voodoo3 does support 32 bit color.....if it only supported 16 bit color that would be kind of extreme.....it doesn't support 32 bit TEXTURES!!!! much less important....its still rendered in 32 bit color....
Does this mean that the information from gnome hints will actually interact with those from kde hints? I mean, if you're running gnome with enlightenment and need the gnome hints (say for gnome pager) but instead of gmc you want to run kfm (which needs kde hints) would it work?
PS. Even though I've programmed gnome stuff before I've never even TOUCHED window manager stuff so if I don't know what I'm talking about......be nice....
First....where is linux's smp heading? 2.2 gave us major changes in that area.....any more comming with 2.4?
Second....how is the new quicker release cycle going to affect kernel development in your opinion? Is it going to slow down/speed up anything? Or is it just so suits realise that development IS being done....
Third....how is the whole linux-on-sgi thing going? You were originally the guy behind that....what's your opinion on the sgi embracing linux stuff happening now?
Hey, could this in any way signal the return of OS/2 PPC edition? I was really pissed at IBM when they dropped that system. I was actually ready to switch to a mac if they'd have a decent system on it (macos doesn't count). That was before the linuxppc days.
I agree. I had some fears about this movie (and the Anakin choice) but after reading that new screenplay I really have hope for this. And strangely enough, the way this one is set up, Anakin could probably pull this off.
exactly his point.....you have to do it yourself if the program package didn't do it.....its ALWAYS the program packager's responsibility to notify the OS which executable runs the app.....
Its not that its that hard to look things up in a manual, if you're not scared of your computer. You forget that half the users out there see the words "video chipset" and what registers in their mind is "something I don't understand and can possibly break". Yes people are stupid. We know. Thats why we have computers to pick up the slack for them. Why do we even need to rely on the stupidity of people when the information is right there in the hardware (dpmi for monitors, device identifiers for video cards (and yes I know, don't talk, code.....I'm working up to that:))
Umm.....email me....the address up there is correct....
Joe
Another VaTech CS major here....the wierd thing is that in my two years here so far I've managed to actually have a social life outside of the CS department but never meet anyone in any of my classes....and you are right....there are cute CS girls....they just generally don't bother with CS guys....
A recently dumped CS guy who's bored at work