As with 99.9% of all memory benchmarking, it was done by someone who didn't totally understand how to measure memory use (and how Linux doesn't allow accurate measurements without a patched kernel). Just read the comments in the post which pointed at the original story.
I have a Thecus N2100, which is pretty neat. It also supports RAID 1, so with two disks in it doens't matter if one of them dies. Debian Etch even supports it out of the box.
I'm surprised you couldn't find anything for less than $1200, a few hours of searching gave me too much choice...
> 1) I don't believe (for xine at least) that wine is neccessary for asf (wmv) playback (the windows codec > dlls are required, but used by xine without wine's help)
Aside from the fact that distributing the DLLs is legally dubious at best, good luck using the Windows DLLs on a x86-64, PPC, Sparc, ARM, or MIPS Linux system...
Note how some of the fluendo plugins come in x86-32, x86-64, sparc and ppc versions.
Is there anything in that post which is correct? So what is OS X doens't have a known ARM port, the BSDs run on ARM so porting it would be trivial. Also, Apple own the source so can do anything, including making a private branch. The iPhone could be using a low power PPC chip.
I've been waiting for clue to finally disappear from/., and it appears that 2007 is the year it happens.
It's not an open source implementation, so it's probably the Adobe source licensed by some other company and ported. I can't recall what company offered binary Flash plugins for embedded devices though.
Remember that writing a compliant Flash implementation is very tricky, the rendering model is very precise and simply saying "I'll use Cairo/GL/X/etc to draw" results in an incorrect implementation.
Where "every" is "Tomboy", right? There is only one Mono application in GNOME, which has no hard dependencies with other parts of the desktop. This was on purpose, so you can just not install it if you want.
Re:Glad to see menu editing has been fixed
on
Gnome 2.14 Released
·
· Score: 1
Ubuntu Dapper and several other distros are shipping a slightly different menu editor (Dapper has Alacarte), in which you press File->New Entry. If your distribution doesn't ship Smeg or Alacarte, then file a bug.
It works today? Yeah, right. Xgl is just an abstraction, you need to use an implementation such as Xglx (Xgl on GLX), Xegl (Xgl on E-GL) and so on.
The only working implementation is Xglx, which runs a *nested X server* inside *another X server*. It's Xnest on steriods, and if you don't believe me do a ps and notice the two X servers, including Xorg running on:93. That is what is accessing the hardware, and the Xglx process has just opened a full-screen GLX window.
AIGLX is simply a normal Xorg X server, with an implementation on indirected GLX accleration. A feature that has been missing for ages has been implemented, and enables all of this eye-candy. Yes, in the long run Xegl will be super-fast on supported hardware, but there are *no* fully-featured EGL drivers on Linux at the moment.
So Google are producing a Ubuntu-based distribution. This isn't news as most large companies do this (hell, my last job had 10 staff and we were about to produce a Debian customisation). Google used to use a Red Hat distribution but are have been switching since at least November last year according to https://lists.dulug.duke.edu/pipermail/dulug/2005- November/016656.html.
I'll eat my dog if this ever is released to the world as a "consumer" distribution, designed to take Windows marketshare.
Are you seriously suggesting that we put drawing code into the kernel? Yes, it's in another process, and yes generally that's a good thing. There are plenty of Linux handheld devices out there which run X (our stand at LinuxWorld had 5 devices on, all running kdrive) and the IPC isn't a performance problem. Bad algorithms which result in register thrashing on ARM cores is a more serious problem, honestly!
As for your other arguments, the transports in X are compile-time pluggable. As you'd expect a kdrive X server designed for a handheld device doesn't have TCP connections built in, the only way to connect is via Unix sockets.
And an application that store copies of bitmaps on both client and server side is buggy, period. Once the server-side image is created the client copy can be destroyed.
2. What bothers me about an X system is that it is targetted at client-server, and the resultant code bloat may prove hazardous to an embedded implementation. I do however that an open-source-based solution should be used (why re-invent the wheel).
Sigh, this again. In X when the client and the server are on the same machine, communication is by local Unix sockets, which are the fastest form of IPC on Linux. Keith Packard wrote a new X server (kdrive) to demonstrate that X doesn't have to be slow, and he was right: the "overhead" of the client/server communication is nothing compared to the time it takes smaller systems to draw.
The Ubuntu and GNOME release cycles are in sync, which is what happens when the GNOME Release Manager was the same person as the Ubuntu Release Manager.
Now that GNOME 2.12 is stable, Ubuntu will release a preview of Breezy and in a month, ship it.
I've a Athlon 2000XP, nVidia 5700 and it's rocking along at 1024x768. Sure, I've no AA and the textures are only at middle quality, but IIRC you need more than 512M of video RAM before the high quality textures will fit.
Control-C/V will copy/paste the CLIPBOARD selection. Highlight/middle click will copy/paste the PRIMARY selection. No real applications use the SECONDAY selection, but it still exists.
There is no difference between any of these clipboards, GNOME and KDE don't have their own clipboards (though KDE does have a daemon to collect copied data so that it persists after the application closes), and all X clipboards can handle any content type: it's the applications which don't support it.
http://freedesktop.org/Standards/ClipboardsWiki is an excellent summary of the X clipboard.
Slashdot Mirror
As with 99.9% of all memory benchmarking, it was done by someone who didn't totally understand how to measure memory use (and how Linux doesn't allow accurate measurements without a patched kernel). Just read the comments in the post which pointed at the original story.
I have a Thecus N2100, which is pretty neat. It also supports RAID 1, so with two disks in it doens't matter if one of them dies. Debian Etch even supports it out of the box.
I'm surprised you couldn't find anything for less than $1200, a few hours of searching gave me too much choice...
I wonder if he has the source for his television...
GPE is based on GTK+. The Green Phone is qtopia, obviously.
> 1) I don't believe (for xine at least) that wine is neccessary for asf (wmv) playback (the windows codec > dlls are required, but used by xine without wine's help)
Aside from the fact that distributing the DLLs is legally dubious at best, good luck using the Windows DLLs on a x86-64, PPC, Sparc, ARM, or MIPS Linux system...
Note how some of the fluendo plugins come in x86-32, x86-64, sparc and ppc versions.
Is there anything in that post which is correct? So what is OS X doens't have a known ARM port, the BSDs run on ARM so porting it would be trivial. Also, Apple own the source so can do anything, including making a private branch. The iPhone could be using a low power PPC chip.
/., and it appears that 2007 is the year it happens.
I've been waiting for clue to finally disappear from
The 770 could do USB host, by running flasher --enable-usb-host-mode. I expect the N800 can do this too.
Of course the socket isn't powered and you need a weirdo adaptor to plug anything in, but it does work.
It's not an open source implementation, so it's probably the Adobe source licensed by some other company and ported. I can't recall what company offered binary Flash plugins for embedded devices though.
Remember that writing a compliant Flash implementation is very tricky, the rendering model is very precise and simply saying "I'll use Cairo/GL/X/etc to draw" results in an incorrect implementation.
The thing sticking out of the left is the camera, not the stand.
Where "every" is "Tomboy", right? There is only one Mono application in GNOME, which has no hard dependencies with other parts of the desktop. This was on purpose, so you can just not install it if you want.
Ubuntu Dapper and several other distros are shipping a slightly different menu editor (Dapper has Alacarte), in which you press File->New Entry. If your distribution doesn't ship Smeg or Alacarte, then file a bug.
It works today? Yeah, right. Xgl is just an abstraction, you need to use an implementation such as Xglx (Xgl on GLX), Xegl (Xgl on E-GL) and so on.
:93. That is what is accessing the hardware, and the Xglx process has just opened a full-screen GLX window.
The only working implementation is Xglx, which runs a *nested X server* inside *another X server*. It's Xnest on steriods, and if you don't believe me do a ps and notice the two X servers, including Xorg running on
AIGLX is simply a normal Xorg X server, with an implementation on indirected GLX accleration. A feature that has been missing for ages has been implemented, and enables all of this eye-candy. Yes, in the long run Xegl will be super-fast on supported hardware, but there are *no* fully-featured EGL drivers on Linux at the moment.
He may look adorable, but trust me, *he* is the monster!
Not that, my dog.
So Google are producing a Ubuntu-based distribution. This isn't news as most large companies do this (hell, my last job had 10 staff and we were about to produce a Debian customisation). Google used to use a Red Hat distribution but are have been switching since at least November last year according to https://lists.dulug.duke.edu/pipermail/dulug/2005- November/016656.html.
I'll eat my dog if this ever is released to the world as a "consumer" distribution, designed to take Windows marketshare.
Are you seriously suggesting that we put drawing code into the kernel? Yes, it's in another process, and yes generally that's a good thing. There are plenty of Linux handheld devices out there which run X (our stand at LinuxWorld had 5 devices on, all running kdrive) and the IPC isn't a performance problem. Bad algorithms which result in register thrashing on ARM cores is a more serious problem, honestly!
As for your other arguments, the transports in X are compile-time pluggable. As you'd expect a kdrive X server designed for a handheld device doesn't have TCP connections built in, the only way to connect is via Unix sockets.
And an application that store copies of bitmaps on both client and server side is buggy, period. Once the server-side image is created the client copy can be destroyed.
Sigh, this again. In X when the client and the server are on the same machine, communication is by local Unix sockets, which are the fastest form of IPC on Linux. Keith Packard wrote a new X server (kdrive) to demonstrate that X doesn't have to be slow, and he was right: the "overhead" of the client/server communication is nothing compared to the time it takes smaller systems to draw.
4 degrees celsius, surely.
Probably the version of Evolution which shipped with GNOME 2.12, i.e. 2.4.
The Ubuntu and GNOME release cycles are in sync, which is what happens when the GNOME Release Manager was the same person as the Ubuntu Release Manager.
Now that GNOME 2.12 is stable, Ubuntu will release a preview of Breezy and in a month, ship it.
The good news is that Ronald has been working at this pretty much non-stop for 2.12, and GStreamer is *way* better at playing DVDs than 2.10.
The RenderAccel option to the nVidia driver is experimental, not RENDER itself. GTK+ has been using Render directly for several years now.
Ah, maybe it's based on the AGP bus speed or something, and decided that it can shuffle them back and forth fast enough.
I've a Athlon 2000XP, nVidia 5700 and it's rocking along at 1024x768. Sure, I've no AA and the textures are only at middle quality, but IIRC you need more than 512M of video RAM before the high quality textures will fit.
Urr, all wrong.
Control-C/V will copy/paste the CLIPBOARD selection. Highlight/middle click will copy/paste the PRIMARY selection. No real applications use the SECONDAY selection, but it still exists.
There is no difference between any of these clipboards, GNOME and KDE don't have their own clipboards (though KDE does have a daemon to collect copied data so that it persists after the application closes), and all X clipboards can handle any content type: it's the applications which don't support it.
http://freedesktop.org/Standards/ClipboardsWiki is an excellent summary of the X clipboard.