I actually used to do it all the time in college. If you have a touring bike with front and back panniers, it's no challenge at all. Got funny looks at the checkout counter though...
no, that's what's new - these features have been merged from the kdrive experimental work into an x.org release. So they'll actually be appearing in wide deployment now.
The DRM (kernel) bits are in the DRI-trunk cvs (and probably snapshots) now, so you can build for any kernel you want. Thus no need for the 'approved' distro.
unichrome.sf.net has the 2d driver (sources, and binary snapshots) and is much more up-to-date than what VIA distributes.
The 3d bits source is floating around for, but I've not attempted to build - the via_dri.o as shipped works fine with the unichrome 2d driver and the DRI-trunk modules.
Unfortunately getting all this checked in seems to have gotten waylaid by the xfree86 implosion, so distros aren't doing very well at having it all, but the pieces exist.
I'll agree the 3d is fairly useless though, just because it's so underpowered. But I've been extremely happy with mine (M10000 in a fanless case from scythe) - as a second, non-gaming machine that sits in a place where I wanted no noise.
That, and you are (presumably) above room temperature - given that the human body temp is 37C or so - either well above room temperature, or a pretty hot room. So the other thing the fan accomplishes is to keep you from forming a bubble of warmed-up air around you, by replacing it with other (not yet warmed-up) air.
But only with evaporation (or significant compression, so that you can cool with expansion - this is how AC works) can it get you below ambient.
it's basically the same system (architecturally, obviously it's quite a bit smaller physically) as the existing epia-ME6000/M10000 (nehemia processor, unichrome video, etc), so you ought to be able to find plenty of reviews for performance comparison.
probably - many of the mini-itx cases are have a case exhaust fan, probably many of the nano-itx ones will too. So it makes sense to still provide one fan header even if the CPU doesn't need its own.
there's at least one - the lindows mobile PC (which is really an eNote OEM rebadged). Dunno i there are any others. This is based on the VIA eden chips, though I don't recall whether it is the ezra-t core or the newer antuar/nehemiah core.
http://info.lindows.com/mobilepc/mobilepc.htmhttp://www.sub300.com/port.htm
Although the KDE implementation of the dcopserver and the kdelibs client libs both use Qt data types, dcop data is carried over libICE (which is an X lib), and the wire protocol is also quite easy to deal with from C-only - unless you want to send a complicated Qt object to a KDE app (ie, something more complex than a simple string/int/bool/struct of such - QPixmap is the one that occasionally comes up). It would not be terribly hard to write a C-only client lib (instead of the existing C bindings that still indirectly use the KDE implementation) that didn't use Qt at all, and writing a C-only dcopserver would be easier than something entirely new.
Nothing fundamental about DCOP relies on Qt, just the current implementation (understandable since it came from KDE - same as it would use glib if it had come from GNOME). Rewriting things that your toolkit provides for free is bad practice, though keeping them out of your wire protocol is good for compatibility and future-proofing.
On the other hand, freeing DCOP from X would be harder, since libICE is a more fundamental dependency. And one of the cooler possibilities of dbus is the prospect of hooking in kernel events, events from other system daemons, etc. So on the whole dbus looks like it has some promise, if enough of the new possibilities it opens up for integration between GUI and non-GUI tasks actually materialize..
There are lots of pieces to the recent work that's been happening on X under the freedesktop banner. Here's my understanding of what the pices are...
Xouvert was/is also working on build changes (and quite possibly this release is based on their work - I don't really know). In any case. the freedesktop.org xlibs announced here (http://xlibs.freedesktop.org/) release has actually got them all made (quite possibly based on contributions from xouvert) and is a full set of 'split' xlibs which build with autoconf/pkg-config.
Additionally, freedesktop has at least two other major X-related projects going (some of the same people, some different). One of these is the xcb/xcl to replace xlibs, the other is a kdrive-based xserver. Neither of these projects has yet made a full release, though both have code that works and is making excellent progress
xcb (http://xcb.freedesktop.org/) is a new API targeted toward letting toolkit authors handle asyncronous events more effectively, without some of the compromises xlib made to ease writing apps directly to it. The rise of high-level toolkits (Qt, GTK, wxWindows, Tk, etc) has definitely changed the way the xlib API is typically used. For compatibility with existing apps and for easier programming of apps which (for whatever reason) do not want to use a high-level toolkit, xcl is a an xlib-compatible API sitting on top of xcb. Think of it as a minimal 'toolkit' which provides the 'wait-for-reply' API to error handling and return-values that xlib uses today.
The new kdrive xserver's primary features are the DAMAGE and COMPOSITE extensions (allowing multiple apps to coordinate and share in painting what actually appears on the screen. It also features a much smaller&simpler codebase from the XFree86 server, allowing easier experimentation with still other new ideas.
The linux ivtv drivers also support direct YUV capture, which AIUI eliminates the delay. However, the actual pixel format the card uses is somewhat odd (designed for use by it's compression engine, not for external apps), so not all tuner apps can use this mode. I'm pretty sure mplayer's tuner mode does, and I think there are some others as well.
However, if you aren't going to use the compression, the card is rather spendy for a live-capture only card:-) Better to buy an el-cheapo BTTV if you just plan to connect a game system instead of a tv input.
well, there are several answers. One, it will be a whole lot more efficient than a rocket, because you don't have to carry the fuel up with you, you can pull transport the needed energy via the supporting structure. Given that most of the mass of a rocket is the fuel, that's huge.
Secondly, it just takes less energy. Besides getting rid of the fuel weight, even the mass of the climber you don't really have to pay for - you get it back when the thing comes back down. You have to devise some way of storing the energy, though one reasonable approach would be to just let the whole thing ride up and down a little bit and store the surplus in the potential energy of the huge orbiting mass.
Thus, the only energy you actually spend is the actual mass of the cargo times the height to which you lift it. Weigh a shuttle crew & cargo. Now weigh the shuttle, fully fueled, on the pad. Which one is going to take more energy to get to orbit? With a space elevator, only the cargo counts, and even that only if you leave it up there...
Re:Good start, but not useful yet
on
Qt On DirectFB
·
· Score: 5, Insightful
many KDE programmers have, because of QT/Embedded (and the zaurus).
Konqueror, KHTML et all already have releases built to not need X (kdenox cvs module).
Now, for the more desktop-ish apps this is certainly true, and X11 usage is (unfortunately) rather sprinkled about.
The biggest single piece is probably replacing kwin, followed by the dcopserver.
not quite. You still can't fill all the FU's usually (because the main bottleneck in the P4 is, and even with HT remains, the instruction decoding). You genererally can't get enough instructions decoded to stuff all the FU's full unless one of the tasks is really, really doing well in the trace cache (which is like an L1 instruction cache, only it stores already decoded instructions).
normal task switching can't take advantage of 100-cycle holes though - that's not long enough to justify the cost of a context switch to another task. HT can, as the second task is also already loaded up on the chip. So it can grab idle decoder slots, FU's, memory access cycles, etc and use them when they would otherwise have been wasted, where a traditional task-switch would have been too expensive and they would simply have been wasted. But the net gain is generally less than 10%, and it's quite possible for it to be negative (as the two tasks that are trying to share the CPU compete for cache space).
HT is pretty cool when it works, and I'm sure it's going to be more and more common as pipelines deepen (increasing the amount of resources available for this sort of use) and caches get bigger (which reduces the penalty). But it's absolutely not a second CPU.
Re:Call me crazy, but I still like fvwm.
on
fvwm Turns Ten
·
· Score: 1
well, XFree86 itself supports panning - just set a big virtual resolution for your monitor. so the WM doesn't really need to do this, the Xserver that most of us use can
vwm == virtual window manager - aka, it's a window manager, and has the virtual desktops we've all come to know and love (and miss when using non-X11 systems)
on the plus side, I just found out about http://desktopian.org/bb4win. My windows dev box is now much more tolerable:-)
Re:NO grease for you; you MUST use grease!!
on
AMD: No Grease For You!
·
· Score: 2, Informative
Athlon 64 has a integral heat spreader (like the P4 and opteron) instead of an exposed die. This means the core is well shielded, and has nothing exposed to short out. Athlon has the die exposed, and bridges on the top of the chip exposed, which conductive greases sometimes short out. So, the mounting configuration is pretty different, and it doesn't surprise me in the least that the recommended way to mount the heatsink is different.
the nf2 had dual channel memory, but still only a single channel link to the CPU (the second channel of memory bandwidth could help with things like AGP transfers were going, as otherwise device DMA and other non-CPU memory usage would have to cut into the memory bandwidth available to the CPU. With a second channel, it has its own. Since the NForce2 has integrated shared-memory video there's a big user for the extra non-CPU bandwidth, and it makes sense to have it even if the CPU can't use it. But the chip didn't really get to benefit directly from the second channel, only from the lack of contention.
The Athlon64 has only a single channel memory controller because such things cost money, and this is the budget version. Operon gets two.
well, widespread piracy would surely be bad forcruise lines:-)
Re:Does linux support hypertrheading?
on
Linux SMP Round-Up
·
· Score: 3, Informative
yes, linux 'supports' hyperthreading - that took no changes at all, since they just show who up as more CPU targets. 2.5 kernels, and (I think) some of the 2.4 scheduler patchsets, also have some special tuning to avoid some of the worse behaviors hyperthreading can cause (when processes hop back and forth between physical images cores, or end up overcrowded on one virtual image).
if you don't think the GPL protects your rights, don't use GNOME either.
Furthermore, the Free KDE Foundation http://www.kde.org/whatiskde/kdefreeqtfoundation.p hp must approve any changes by trolltech to the Free QT license - if they do not like the changes, or trolltech allows the free edition to be more than 12 months out of date w.r.t. the commercial edition, they can take the last-released Free Edition they have and relicense it under BSD terms.
So our asses are covered. We don't have to trust them blindly, we have all the protections we need to know they can't screw us (and, since they agreed to grant such protection to the free software community, the odds that their intentions were anything bad are very slim).
winex is somewhat proprietary (it's aladdin public license, which makes it the same as AFPL ghostscript) with some additional truly proprietary (binary only) bits provided only to subscribers which handle licensed things like copy protection. No idea whether you need these for MOO3 or not, if they didn't use messy copy protection probably not.
And it certainly has no need of windows dll's at all (or rather less than stock wine, since transgaming has been more willing to band-aid specific app problems even when fixing the problem right is hard.
Basically, winex is a lot messier (mixed licenses, bad hacks) and works a bit better for the apps it has been hacked up for. but you can get most of the source (under AFPL, for non-commercial use) even as a non-subscriber they have pushed things back to rewind fairly regularly (when they aren't just awful hacks)
bingo - you can separate the kernel and give the space back to the app, but it's very significantly slower. Not as bad as swapping, but far too much to make sense as a general trade.
Slashdot Mirror
I actually used to do it all the time in college. If you have a touring bike with front and back panniers, it's no challenge at all. Got funny looks at the checkout counter though...
no, that's what's new - these features have been merged from the kdrive experimental work into an x.org release. So they'll actually be appearing in wide deployment now.
The DRM (kernel) bits are in the DRI-trunk cvs (and probably snapshots) now, so you can build for any kernel you want. Thus no need for the 'approved' distro.
unichrome.sf.net has the 2d driver (sources, and binary snapshots) and is much more up-to-date than what VIA distributes.
The 3d bits source is floating around for, but I've not attempted to build - the via_dri.o as shipped works fine with the unichrome 2d driver and the DRI-trunk modules.
Unfortunately getting all this checked in seems to have gotten waylaid by the xfree86 implosion, so distros aren't doing very well at having it all, but the pieces exist.
I'll agree the 3d is fairly useless though, just because it's so underpowered. But I've been extremely happy with mine (M10000 in a fanless case from scythe) - as a second, non-gaming machine that sits in a place where I wanted no noise.
That, and you are (presumably) above room temperature - given that the human body temp is 37C or so - either well above room temperature, or a pretty hot room. So the other thing the fan accomplishes is to keep you from forming a bubble of warmed-up air around you, by replacing it with other (not yet warmed-up) air.
But only with evaporation (or significant compression, so that you can cool with expansion - this is how AC works) can it get you below ambient.
that's a gimp2 feature - just grab the label of the separate window, drag to an appropriate edge/tab strip and it will dock
it never referred to the driver - it was 'rice' boy at first because the car in question was always a (Japanese) Honda Civic.
it's basically the same system (architecturally, obviously it's quite a bit smaller physically) as the existing epia-ME6000/M10000 (nehemia processor, unichrome video, etc), so you ought to be able to find plenty of reviews for performance comparison.
probably - many of the mini-itx cases are have a case exhaust fan, probably many of the nano-itx ones will too. So it makes sense to still provide one fan header even if the CPU doesn't need its own.
there's at least one - the lindows mobile PC (which is really an eNote OEM rebadged). Dunno i there are any others. This is based on the VIA eden chips, though I don't recall whether it is the ezra-t core or the newer antuar/nehemiah core. http://info.lindows.com/mobilepc/mobilepc.htm http://www.sub300.com/port.htm
Although the KDE implementation of the dcopserver and the kdelibs client libs both use Qt data types, dcop data is carried over libICE (which is an X lib), and the wire protocol is also quite easy to deal with from C-only - unless you want to send a complicated Qt object to a KDE app (ie, something more complex than a simple string/int/bool/struct of such - QPixmap is the one that occasionally comes up). It would not be terribly hard to write a C-only client lib (instead of the existing C bindings that still indirectly use the KDE implementation) that didn't use Qt at all, and writing a C-only dcopserver would be easier than something entirely new.
Nothing fundamental about DCOP relies on Qt, just the current implementation (understandable since it came from KDE - same as it would use glib if it had come from GNOME). Rewriting things that your toolkit provides for free is bad practice, though keeping them out of your wire protocol is good for compatibility and future-proofing.
On the other hand, freeing DCOP from X would be harder, since libICE is a more fundamental dependency. And one of the cooler possibilities of dbus is the prospect of hooking in kernel events, events from other system daemons, etc. So on the whole dbus looks like it has some promise, if enough of the new possibilities it opens up for integration between GUI and non-GUI tasks actually materialize..
There are lots of pieces to the recent work that's been happening on X under the freedesktop banner. Here's my understanding of what the pices are...
Xouvert was/is also working on build changes (and quite possibly this release is based on their work - I don't really know). In any case. the freedesktop.org xlibs announced here (http://xlibs.freedesktop.org/) release has actually got them all made (quite possibly based on contributions from xouvert) and is a full set of 'split' xlibs which build with autoconf/pkg-config.
Additionally, freedesktop has at least two other major X-related projects going (some of the same people, some different). One of these is the xcb/xcl to replace xlibs, the other is a kdrive-based xserver. Neither of these projects has yet made a full release, though both have code that works and is making excellent progress
xcb (http://xcb.freedesktop.org/) is a new API targeted toward letting toolkit authors handle asyncronous events more effectively, without some of the compromises xlib made to ease writing apps directly to it. The rise of high-level toolkits (Qt, GTK, wxWindows, Tk, etc) has definitely changed the way the xlib API is typically used. For compatibility with existing apps and for easier programming of apps which (for whatever reason) do not want to use a high-level toolkit, xcl is a an xlib-compatible API sitting on top of xcb. Think of it as a minimal 'toolkit' which provides the 'wait-for-reply' API to error handling and return-values that xlib uses today.
The new kdrive xserver's primary features are the DAMAGE and COMPOSITE extensions (allowing multiple apps to coordinate and share in painting what actually appears on the screen. It also features a much smaller&simpler codebase from the XFree86 server, allowing easier experimentation with still other new ideas.
The linux ivtv drivers also support direct YUV capture, which AIUI eliminates the delay. However, the actual pixel format the card uses is somewhat odd (designed for use by it's compression engine, not for external apps), so not all tuner apps can use this mode. I'm pretty sure mplayer's tuner mode does, and I think there are some others as well.
:-) Better to buy an el-cheapo BTTV if you just plan to connect a game system instead of a tv input.
However, if you aren't going to use the compression, the card is rather spendy for a live-capture only card
well, there are several answers. One, it will be a whole lot more efficient than a rocket, because you don't have to carry the fuel up with you, you can pull transport the needed energy via the supporting structure. Given that most of the mass of a rocket is the fuel, that's huge.
Secondly, it just takes less energy. Besides getting rid of the fuel weight, even the mass of the climber you don't really have to pay for - you get it back when the thing comes back down. You have to devise some way of storing the energy, though one reasonable approach would be to just let the whole thing ride up and down a little bit and store the surplus in the potential energy of the huge orbiting mass.
Thus, the only energy you actually spend is the actual mass of the cargo times the height to which you lift it. Weigh a shuttle crew & cargo. Now weigh the shuttle, fully fueled, on the pad. Which one is going to take more energy to get to orbit? With a space elevator, only the cargo counts, and even that only if you leave it up there...
many KDE programmers have, because of QT/Embedded (and the zaurus).
Konqueror, KHTML et all already have releases built to not need X (kdenox cvs module).
Now, for the more desktop-ish apps this is certainly true, and X11 usage is (unfortunately) rather sprinkled about.
The biggest single piece is probably replacing kwin, followed by the dcopserver.
not quite. You still can't fill all the FU's usually (because the main bottleneck in the P4 is, and even with HT remains, the instruction decoding). You genererally can't get enough instructions decoded to stuff all the FU's full unless one of the tasks is really, really doing well in the trace cache (which is like an L1 instruction cache, only it stores already decoded instructions).
normal task switching can't take advantage of 100-cycle holes though - that's not long enough to justify the cost of a context switch to another task. HT can, as the second task is also already loaded up on the chip. So it can grab idle decoder slots, FU's, memory access cycles, etc and use them when they would otherwise have been wasted, where a traditional task-switch would have been too expensive and they would simply have been wasted. But the net gain is generally less than 10%, and it's quite possible for it to be negative (as the two tasks that are trying to share the CPU compete for cache space).
HT is pretty cool when it works, and I'm sure it's going to be more and more common as pipelines deepen (increasing the amount of resources available for this sort of use) and caches get bigger (which reduces the penalty). But it's absolutely not a second CPU.
well, XFree86 itself supports panning - just set a big virtual resolution for your monitor. so the WM doesn't really need to do this, the Xserver that most of us use can
vwm == virtual window manager - aka, it's a window manager, and has the virtual desktops we've all come to know and love (and miss when using non-X11 systems)
:-)
on the plus side, I just found out about http://desktopian.org/bb4win. My windows dev box is now much more tolerable
Athlon 64 has a integral heat spreader (like the P4 and opteron) instead of an exposed die. This means the core is well shielded, and has nothing exposed to short out. Athlon has the die exposed, and bridges on the top of the chip exposed, which conductive greases sometimes short out. So, the mounting configuration is pretty different, and it doesn't surprise me in the least that the recommended way to mount the heatsink is different.
the nf2 had dual channel memory, but still only a single channel link to the CPU (the second channel of memory bandwidth could help with things like AGP transfers were going, as otherwise device DMA and other non-CPU memory usage would have to cut into the memory bandwidth available to the CPU. With a second channel, it has its own. Since the NForce2 has integrated shared-memory video there's a big user for the extra non-CPU bandwidth, and it makes sense to have it even if the CPU can't use it. But the chip didn't really get to benefit directly from the second channel, only from the lack of contention.
The Athlon64 has only a single channel memory controller because such things cost money, and this is the budget version. Operon gets two.
well, widespread piracy would surely be bad forcruise lines :-)
yes, linux 'supports' hyperthreading - that took no changes at all, since they just show who up as more CPU targets. 2.5 kernels, and (I think) some of the 2.4 scheduler patchsets, also have some special tuning to avoid some of the worse behaviors hyperthreading can cause (when processes hop back and forth between physical images cores, or end up overcrowded on one virtual image).
:-)
So linux support for HT is pretty good
it. is. GPL.
p hp must approve any changes by trolltech to the Free QT license - if they do not like the changes, or trolltech allows the free edition to be more than 12 months out of date w.r.t. the commercial edition, they can take the last-released Free Edition they have and relicense it under BSD terms.
if you don't think the GPL protects your rights, don't use GNOME either.
Furthermore, the Free KDE Foundation http://www.kde.org/whatiskde/kdefreeqtfoundation.
So our asses are covered. We don't have to trust them blindly, we have all the protections we need to know they can't screw us (and, since they agreed to grant such protection to the free software community, the odds that their intentions were anything bad are very slim).
it's a quake3 bug, not an X bug - id fixed it some time ago (patch 1.32b)
winex is somewhat proprietary (it's aladdin public license, which makes it the same as AFPL ghostscript) with some additional truly proprietary (binary only) bits provided only to subscribers which handle licensed things like copy protection. No idea whether you need these for MOO3 or not, if they didn't use messy copy protection probably not.
And it certainly has no need of windows dll's at all (or rather less than stock wine, since transgaming has been more willing to band-aid specific app problems even when fixing the problem right is hard.
Basically, winex is a lot messier (mixed licenses, bad hacks) and works a bit better for the apps it has been hacked up for. but you can get most of the source (under AFPL, for non-commercial use) even as a non-subscriber they have pushed things back to rewind fairly regularly (when they aren't just awful hacks)
bingo - you can separate the kernel and give the space back to the app, but it's very significantly slower. Not as bad as swapping, but far too much to make sense as a general trade.