<?xml version="1.0" encoding="UTF-8"?>

<rdf:RDF 
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns="http://purl.org/rss/1.0/"
  xmlns:dc="http://purl.org/dc/elements/1.1/"
  xmlns:syn="http://purl.org/rss/1.0/modules/syndication/"
>

  <channel rdf:about="http://lwn.net/headlines/338783/">
    <title>LWN: Comments on "Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)"</title>
    <link>http://lwn.net/Articles/338783/</link>
    <description>
This is a special feed containing comments posted
to the individual LWN article titled &quot;Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)&quot;.

    </description>

    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>2</syn:updateFrequency>
    <items>
      <rdf:Seq>
	<rdf:li resource="http://lwn.net/Articles/339766/rss" />
	<rdf:li resource="http://lwn.net/Articles/339764/rss" />
	<rdf:li resource="http://lwn.net/Articles/339334/rss" />
	<rdf:li resource="http://lwn.net/Articles/339325/rss" />
	<rdf:li resource="http://lwn.net/Articles/339105/rss" />
	<rdf:li resource="http://lwn.net/Articles/339064/rss" />
	<rdf:li resource="http://lwn.net/Articles/339063/rss" />
	<rdf:li resource="http://lwn.net/Articles/339055/rss" />
	<rdf:li resource="http://lwn.net/Articles/339053/rss" />
	<rdf:li resource="http://lwn.net/Articles/339050/rss" />
	<rdf:li resource="http://lwn.net/Articles/339051/rss" />
	<rdf:li resource="http://lwn.net/Articles/339043/rss" />
	<rdf:li resource="http://lwn.net/Articles/339036/rss" />
	<rdf:li resource="http://lwn.net/Articles/339035/rss" />
	<rdf:li resource="http://lwn.net/Articles/339018/rss" />
	<rdf:li resource="http://lwn.net/Articles/339019/rss" />
	<rdf:li resource="http://lwn.net/Articles/339012/rss" />
	<rdf:li resource="http://lwn.net/Articles/339009/rss" />
	<rdf:li resource="http://lwn.net/Articles/338950/rss" />
	<rdf:li resource="http://lwn.net/Articles/338910/rss" />
	<rdf:li resource="http://lwn.net/Articles/338909/rss" />
	<rdf:li resource="http://lwn.net/Articles/338878/rss" />
	<rdf:li resource="http://lwn.net/Articles/338891/rss" />
	<rdf:li resource="http://lwn.net/Articles/338883/rss" />
	<rdf:li resource="http://lwn.net/Articles/338890/rss" />
	<rdf:li resource="http://lwn.net/Articles/338889/rss" />
	<rdf:li resource="http://lwn.net/Articles/338887/rss" />
	<rdf:li resource="http://lwn.net/Articles/338888/rss" />
	<rdf:li resource="http://lwn.net/Articles/338885/rss" />
	<rdf:li resource="http://lwn.net/Articles/338881/rss" />
	<rdf:li resource="http://lwn.net/Articles/338880/rss" />
	<rdf:li resource="http://lwn.net/Articles/338879/rss" />
	<rdf:li resource="http://lwn.net/Articles/338874/rss" />
	<rdf:li resource="http://lwn.net/Articles/338873/rss" />
	<rdf:li resource="http://lwn.net/Articles/338872/rss" />
	<rdf:li resource="http://lwn.net/Articles/338871/rss" />
	<rdf:li resource="http://lwn.net/Articles/338868/rss" />
	<rdf:li resource="http://lwn.net/Articles/338863/rss" />
	<rdf:li resource="http://lwn.net/Articles/338852/rss" />
	<rdf:li resource="http://lwn.net/Articles/338851/rss" />
      
      </rdf:Seq>
    </items>

  </channel>
    <item rdf:about="http://lwn.net/Articles/339766/rss">
      <title>Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)</title>
      <link>http://lwn.net/Articles/339766/rss</link>
      <dc:date>2009-07-02T19:06:34+00:00</dc:date>
      <dc:creator>NRArnot</dc:creator>
      <description>
      &lt;div class=&quot;FormattedComment&quot;&gt;
Pleased to see it supports 4Gb, one of the annoyances with Intel Atom is that it supports only 2Gb. But does it have the x86-64 extensions? or PAE? &lt;br&gt;
&lt;p&gt;
And I wonder whether it can run VMware (which does NOT require the VT extentions, by the way).  &lt;br&gt;
&lt;/div&gt;

      
      </description>
    </item>
    <item rdf:about="http://lwn.net/Articles/339764/rss">
      <title>Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)</title>
      <link>http://lwn.net/Articles/339764/rss</link>
      <dc:date>2009-07-02T19:00:15+00:00</dc:date>
      <dc:creator>NRArnot</dc:creator>
      <description>
      &lt;div class=&quot;FormattedComment&quot;&gt;
They'll carry on selling halogen-incandescent bulbs, which are now widedly available in housings compatible with old-style bulbs. Halogen gives a better-quality light and about 25% more of it for the same wattage. I too don't like the quality of light from CFLs, but given halogen bulbs, there's no excuse for the other sort.&lt;br&gt;
&lt;p&gt;
Halogens cost more, but if you drop the wattage a bit you'll save much of the extra cost in electricity over 2000 hours life.&lt;br&gt;
&lt;p&gt;
&lt;p&gt;
&lt;/div&gt;

      
      </description>
    </item>
    <item rdf:about="http://lwn.net/Articles/339334/rss">
      <title>Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)</title>
      <link>http://lwn.net/Articles/339334/rss</link>
      <dc:date>2009-06-30T21:09:19+00:00</dc:date>
      <dc:creator>dlang</dc:creator>
      <description>
      &lt;div class=&quot;FormattedComment&quot;&gt;
in my case it was an electronic motion sensor, so that problem doesn't apply.&lt;br&gt;
&lt;p&gt;
this isn't just a case of CFL, normal FL have the same problem, power cycling them drasticly cuts down on their life &lt;br&gt;
&lt;/div&gt;

      
      </description>
    </item>
    <item rdf:about="http://lwn.net/Articles/339325/rss">
      <title>Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)</title>
      <link>http://lwn.net/Articles/339325/rss</link>
      <dc:date>2009-06-30T19:41:27+00:00</dc:date>
      <dc:creator>Wol</dc:creator>
      <description>
      &lt;div class=&quot;FormattedComment&quot;&gt;
Actually, it's not necessarily the cycle rate that does the damage. I put a CFL on a mechanical timer (which you are TOLD NOT to do, and it died in short order. I put the replacement on an electronic timer, and it was fine.&lt;br&gt;
&lt;p&gt;
Mechanical timers don't switch cleanly, I think, and cycling it while it's trying to power up doesn't seem to be the done thing ...&lt;br&gt;
&lt;p&gt;
Cheers,&lt;br&gt;
Wol&lt;br&gt;
&lt;/div&gt;

      
      </description>
    </item>
    <item rdf:about="http://lwn.net/Articles/339105/rss">
      <title>The Grand Guignol</title>
      <link>http://lwn.net/Articles/339105/rss</link>
      <dc:date>2009-06-29T16:59:10+00:00</dc:date>
      <dc:creator>dlang</dc:creator>
      <description>
      &lt;div class=&quot;FormattedComment&quot;&gt;
actually now that I think about it more, I think it's done by udev or the hotplug script. hotplug gets informed when something new gets plugged in and detected by the kernel, then it calls udev which mounts the device.&lt;br&gt;
&lt;p&gt;
the only place d-bus would get involved (and I'm not sure that it is) is in communication to desktop daemons, and while it's a nice touch to have the new device pop up automagicly, it's not that bad to have to hit refresh to see a new device that you just plugged in.&lt;br&gt;
&lt;/div&gt;

      
      </description>
    </item>
    <item rdf:about="http://lwn.net/Articles/339064/rss">
      <title>Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)</title>
      <link>http://lwn.net/Articles/339064/rss</link>
      <dc:date>2009-06-29T12:37:22+00:00</dc:date>
      <dc:creator>farnz</dc:creator>
      <description>
      &lt;p&gt;One thing to watch for - incandescent lights warm up almost instantly, whereas CFLs take ten to fifteen minutes to warm up.
&lt;p&gt;Note also that CFLs tend to be bluer than incandescents once running - if this bothers you, halogens are your best bet.
      
      </description>
    </item>
    <item rdf:about="http://lwn.net/Articles/339063/rss">
      <title>Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)</title>
      <link>http://lwn.net/Articles/339063/rss</link>
      <dc:date>2009-06-29T12:19:36+00:00</dc:date>
      <dc:creator>nye</dc:creator>
      <description>
      &lt;div class=&quot;FormattedComment&quot;&gt;
A 20W CFL is certainly toted as being equivalent to 100W incandescent, but  - I don't know if it's due to colour temperature, dimming over time, or what - I find them to be intolerable.&lt;br&gt;
&lt;p&gt;
I'd like to try a 30W but they're hard to find and cost around £10 which is a bit much. For the moment I'm soldiering on with this 20W thing and leaving it off until it's almost too dark to see, since it inexplicably feels like it makes the room *darker* until that point.&lt;br&gt;
&lt;/div&gt;

      
      </description>
    </item>
    <item rdf:about="http://lwn.net/Articles/339055/rss">
      <title>The Grand Guignol</title>
      <link>http://lwn.net/Articles/339055/rss</link>
      <dc:date>2009-06-29T10:35:13+00:00</dc:date>
      <dc:creator>eru</dc:creator>
      <description>
      &lt;i&gt;access to removable media is automounter plus a single app, again, not very involved with either gnome or kde&lt;/i&gt;
&lt;p&gt;
I have sometimes tried the automounter approach, but it has the
problem that the media is not noticed when you insert it, only when you
access it (and to do so you have to explicitly know where it gets mounted
in the directory hierarchy). It is also useful for the GUI to immediately
react to the inroduction of the new medium (like make the new medium appear
in a file manager). This is where I thought the D-BUS and related stuff
comes in. Or are there other ways to get the same effect?

      
      </description>
    </item>
    <item rdf:about="http://lwn.net/Articles/339053/rss">
      <title>The Grand Guignol</title>
      <link>http://lwn.net/Articles/339053/rss</link>
      <dc:date>2009-06-29T09:43:04+00:00</dc:date>
      <dc:creator>dlang</dc:creator>
      <description>
      &lt;div class=&quot;FormattedComment&quot;&gt;
very little of the huge amount of 'stuff' that is gnome or kde are actually relavent to the two features that you mention.&lt;br&gt;
&lt;p&gt;
the X configuration solutions are independant of the desktop (although there are tools available as part of the desktops to tweak the config)&lt;br&gt;
&lt;p&gt;
access to removable media is automounter plus a single app, again, not very involved with either gnome or kde&lt;br&gt;
&lt;p&gt;
both of these things are available if you the same windowmaker desktop that I ran many years ago with 128k of ram.&lt;br&gt;
&lt;p&gt;
the one thing i haven't been able to figure out a clean way to do it in windowmaker is to run multiple monitors, but I haven't really tried in the last year or so.&lt;br&gt;
&lt;/div&gt;

      
      </description>
    </item>
    <item rdf:about="http://lwn.net/Articles/339050/rss">
      <title>The Grand Guignol</title>
      <link>http://lwn.net/Articles/339050/rss</link>
      <dc:date>2009-06-29T09:35:31+00:00</dc:date>
      <dc:creator>eru</dc:creator>
      <description>
      The largest practical advance in desktop Linux environments during this decade has been that it is now usually possible to install and maintain a desktop Linux, and even access removable media (wow!), without frequent trips to the command line, or manually editing configuration files. This is very good! But I don't think this justifies the resource consumption increases. After all, Windows and Mac systems were doing it long ago, on much less powerful systems. This bloat problem is a bit like the cosmological problem of dark matter...

      
      </description>
    </item>
    <item rdf:about="http://lwn.net/Articles/339051/rss">
      <title>Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)</title>
      <link>http://lwn.net/Articles/339051/rss</link>
      <dc:date>2009-06-29T09:27:44+00:00</dc:date>
      <dc:creator>farnz</dc:creator>
      <description>
      &lt;p&gt;I've had no problems sourcing 20W CFLs (100W equivalent) in the UK. You might like to try DIY stores - my most consistent source is Homebase.
      
      </description>
    </item>
    <item rdf:about="http://lwn.net/Articles/339043/rss">
      <title>The Grand Guignol</title>
      <link>http://lwn.net/Articles/339043/rss</link>
      <dc:date>2009-06-29T07:30:15+00:00</dc:date>
      <dc:creator>dlang</dc:creator>
      <description>
      &lt;div class=&quot;FormattedComment&quot;&gt;
older versions of linux desktops also worked fine in less memory, but the gnome and kde advocates claim that their desktops do a lot more than the older desktops (linux or windows) did, and that's what needs the memory.&lt;br&gt;
&lt;p&gt;
for myself, I really don't need most of the extra 'desktop' features. If I couldpick and choose a couple of support daemons without dragging in the entire mini OS that the gnome and kde have become I would.&lt;br&gt;
&lt;/div&gt;

      
      </description>
    </item>
    <item rdf:about="http://lwn.net/Articles/339036/rss">
      <title>The Grand Guignol</title>
      <link>http://lwn.net/Articles/339036/rss</link>
      <dc:date>2009-06-29T05:35:07+00:00</dc:date>
      <dc:creator>eru</dc:creator>
      <description>
      &lt;i&gt;It seems to me that any system of similar complexity you are going to use about the same amount of RAM and resources and there isn't anything you can do about it.&lt;/i&gt;
&lt;p&gt;
Maybe that is true in the context of the X11 GUI architectures (I hope it is not...), but when you look at that Other OS, you find its older revisions run happily with 128M or less while providing as much (or more) user-friendliness as up-to-date Gnome or KDE. I wonder why. Some guesses, probably wrong:&lt;br&gt;
- Too much duplication of data, because of excessive layering? Eg. an icon on the screen lives in screen memory, an X server off-screen buffer, and also in some representation inside the app?&lt;br&gt;
- Too many GUI libraries doing more or less the same thing, and a lot of them in simultaneous use when typical desktop app combinations are loaded? In Windows, everything goes through the Win32 API. While not perfect, a simple app interacting with a user (eg. fill a form to set values for something) can be coded within it fairly easily, and it will have a very small code and data size.&lt;br&gt;
I really don't know, I'm no expert in GUIs. All I see is the GUI stuff consumes more and more resources in each revision, while NOT providing noticeably more value. And staying with old revisions is not really an option, because their support drops, and occasionally new apps or worthwhile new features for old apps do appear and are not compatible with an &quot;obsolete&quot; system (library revisions and so on). Linux has its own version of the &quot;upgrade treadmill&quot;, it just is powered in a bit different way from the Windows one.

      
      </description>
    </item>
    <item rdf:about="http://lwn.net/Articles/339035/rss">
      <title>Replace with halogens</title>
      <link>http://lwn.net/Articles/339035/rss</link>
      <dc:date>2009-06-29T04:51:20+00:00</dc:date>
      <dc:creator>eru</dc:creator>
      <description>
      &lt;i&gt;I put one in a a place that had high cycle rates (motion sensor controlled) and had it burn out in a few months.&lt;/i&gt;
&lt;p&gt;
I had a similar experience with an outdoor light. But my solution was not to replace it with an old-style bulb, but with one of the new &quot;compatible&quot; halogen bulbs that has a normal screw, looks just like a classic bulb, but consumes about 30% less energy. Here is a link to one vendor's explanation of the concept (there are others):
&lt;a href=&quot;http://www.osram.com/osram_com/Consumer/Home_Lighting/Halogen_lamps/Product_overview/Screw_bases/ENERGY_SAVER/HALOGEN_ENERGY_SAVER_Classic_A/index.html&quot;&gt;http://www.osram.com/osram_com/Consumer/Home_Lighting/Halogen_lamps/Product_overview/Screw_bases/ENERGY_SAVER/HALOGEN_ENERGY_SAVER_Classic_A/index.html&lt;/a&gt;
&lt;p&gt;
I also find the light from this kind of energy saving lamp is more pleasant than from fluorescents, not to mention those ghastly LEDs, which somehow manage to dazzle but not illuminate...


      
      </description>
    </item>
    <item rdf:about="http://lwn.net/Articles/339018/rss">
      <title>Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)</title>
      <link>http://lwn.net/Articles/339018/rss</link>
      <dc:date>2009-06-28T21:56:11+00:00</dc:date>
      <dc:creator>dlang</dc:creator>
      <description>
      &lt;div class=&quot;FormattedComment&quot;&gt;
and what is the fix for the problem that CF bulbs _really_ don't like to be turned on and off much? I put one in a a place that had high cycle rates &lt;br&gt;
(motion sensor controlled) and had it burn out in a few months.&lt;br&gt;
&lt;p&gt;
even incandescent lights last much longer than that, and it's _far_ 'greener' to run one incandescent light using 4x the power for a year than it is to run 4 CF bulbs and replace them when they burn out.&lt;br&gt;
&lt;p&gt;
eliminating the motion sensor and going to a manual switch means that the light is on lot longer, and that it's not always on when it's needed (safety issue)&lt;br&gt;
&lt;p&gt;
I use florescent lights in many locations, and LED lights in others, but I also recognise that they are not right for everywhere. &lt;br&gt;
&lt;/div&gt;

      
      </description>
    </item>
    <item rdf:about="http://lwn.net/Articles/339019/rss">
      <title>Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)</title>
      <link>http://lwn.net/Articles/339019/rss</link>
      <dc:date>2009-06-28T21:55:48+00:00</dc:date>
      <dc:creator>nix</dc:creator>
      <description>
      &lt;div class=&quot;FormattedComment&quot;&gt;
Yes indeed, and I'm seriously not looking forward to it. There appears to &lt;br&gt;
be no energy-efficient bulb on sale equivalent to the old 100W bulbs: they &lt;br&gt;
go up to 60W-equivalent and then stop.&lt;br&gt;
&lt;p&gt;
And 60W is not enough to read by :(&lt;br&gt;
&lt;p&gt;
&lt;/div&gt;

      
      </description>
    </item>
    <item rdf:about="http://lwn.net/Articles/339012/rss">
      <title>Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)</title>
      <link>http://lwn.net/Articles/339012/rss</link>
      <dc:date>2009-06-28T20:03:41+00:00</dc:date>
      <dc:creator>brother_rat</dc:creator>
      <description>
      &lt;div class=&quot;FormattedComment&quot;&gt;
I just did a similar survey here (although nobody has porches on my street, so even harder to tell) &lt;br&gt;
and I reckon there's at least 80% energy efficient bulbs. Most of the remaining incandescent bulbs &lt;br&gt;
are spot lights or &quot;candle&quot; type bulbs, which I guess makes sense. For reference I'm in Bath, UK. &lt;br&gt;
&lt;p&gt;
I'm guessing that a &quot;porch light&quot; is normally left on all evening in your part of the world? I'd say we &lt;br&gt;
started using efficient fluorescent bulbs for those kind of things 10-15 years ago.&lt;br&gt;
&lt;p&gt;
Incidentally, they are due to stop selling 60W light bulbs in January 2010 here, and also in the rest &lt;br&gt;
of Europe on a similar timescale.&lt;br&gt;
&lt;/div&gt;

      
      </description>
    </item>
    <item rdf:about="http://lwn.net/Articles/339009/rss">
      <title>Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)</title>
      <link>http://lwn.net/Articles/339009/rss</link>
      <dc:date>2009-06-28T19:36:58+00:00</dc:date>
      <dc:creator>sbergman27</dc:creator>
      <description>
      &lt;div class=&quot;FormattedComment&quot;&gt;
Not really. I live in Oklahoma City, OK USA. And I've taken a very active interest in promoting the use of efficient lighting. I provide energy efficient bulbs, to anyone, for free, in the common areas of the apartment complex in which I live. And despite my best efforts, a &quot;porch light&quot; survey shows only a few percent of people in the complex use them. On their porches, anyway.&lt;br&gt;
&lt;/div&gt;

      
      </description>
    </item>
    <item rdf:about="http://lwn.net/Articles/338950/rss">
      <title>Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)</title>
      <link>http://lwn.net/Articles/338950/rss</link>
      <dc:date>2009-06-27T14:14:10+00:00</dc:date>
      <dc:creator>ariveira</dc:creator>
      <description>
      &lt;div class=&quot;FormattedComment&quot;&gt;
Build yourself one of this&lt;br&gt;
&lt;p&gt;
&lt;a rel=&quot;nofollow&quot; href=&quot;http://lwn.net/Articles/332961/&quot;&gt;http://lwn.net/Articles/332961/&lt;/a&gt;&lt;br&gt;
&lt;p&gt;
;P&lt;br&gt;
&lt;/div&gt;

      
      </description>
    </item>
    <item rdf:about="http://lwn.net/Articles/338910/rss">
      <title>Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)</title>
      <link>http://lwn.net/Articles/338910/rss</link>
      <dc:date>2009-06-26T18:14:52+00:00</dc:date>
      <dc:creator>drag</dc:creator>
      <description>
      &lt;div class=&quot;FormattedComment&quot;&gt;
There are a lot of shared libraries used in Gnome. So how Linux deals with that is that it loads up the libraries once in ram and then that portion of ram is re-used for multiple applicaitons.&lt;br&gt;
&lt;p&gt;
The RSS size is what it would be if you were to use that particular application in a completely stand-alone manner. (which isn't really accurate either since most programs depend on something like gnome-keyring or whatever to work properly).&lt;br&gt;
&lt;p&gt;
So if you were to try to run gnome-panel in KDE with no other gnome stuff then that it would really use up that 30MB of RAM. But in Gnome at least 1/3 of the application is shared among other applications so the overal memory usage will be much less then it originally seems.&lt;br&gt;
&lt;p&gt;
This is why you will see relatively low real-world games by using a 'lite' system like XFCE over Gnome. Even though XFCE avoids gnome libs applications still tend to need the same sort of functionality and instead  of using shared libraries they invent that functionality on their own. So depending on your applications you can actually end up using MORE resources in a 'lite' environment rather then just sticking with Gnome and using pure gnome* stuff.&lt;br&gt;
&lt;p&gt;
*Of course pure gnome stuff is rarely used. Ubuntu, Fedora, et al ship with configurations that use a lot of non-gnome stuff like OpenOffice.org or Firefox, which duplicate a hell of a lot of the functionality provided by gnome/gtk libraries. With the simple addition of those two programs, running simultanously, you will effectively double the memory requirements of your desktop.&lt;br&gt;
&lt;p&gt;
&lt;/div&gt;

      
      </description>
    </item>
    <item rdf:about="http://lwn.net/Articles/338909/rss">
      <title>Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)</title>
      <link>http://lwn.net/Articles/338909/rss</link>
      <dc:date>2009-06-26T18:06:45+00:00</dc:date>
      <dc:creator>drag</dc:creator>
      <description>
      &lt;div class=&quot;FormattedComment&quot;&gt;
&lt;font class=&quot;QuotedText&quot;&gt;&amp;gt; I thought that required support from the kernel?&lt;/font&gt;&lt;br&gt;
&lt;p&gt;
&lt;font class=&quot;QuotedText&quot;&gt;&amp;gt; If not, then, well, great.&lt;/font&gt;&lt;br&gt;
&lt;p&gt;
&lt;p&gt;
I don't know. I know that the kernel certainly has padlock modules and that openssl does work with padlock in Linux.  It doesn't require any patching of a modern kernel, but may need a recompile of openssl depending on how your distro has it setup. (It does not need a recompile in Ubuntu, but it does in Fedora)&lt;br&gt;
&lt;p&gt;
Beyond that I don't know.&lt;br&gt;
&lt;/div&gt;

      
      </description>
    </item>
    <item rdf:about="http://lwn.net/Articles/338878/rss">
      <title>Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)</title>
      <link>http://lwn.net/Articles/338878/rss</link>
      <dc:date>2009-06-26T16:43:06+00:00</dc:date>
      <dc:creator>ballombe</dc:creator>
      <description>
      &lt;div class=&quot;FormattedComment&quot;&gt;
openssl support padlock in userspace since 4 years for AES and RNG. (yes I have such box, and yes it works). There is no need for /dev/crypto.&lt;br&gt;
&lt;p&gt;
padlock is a set of unpriviledged CPU instructions and does not require kernel support. However there is a kernel module via_rng to use padlock RNG generator for /dev/random, and others for in-kernel crypto.&lt;br&gt;
&lt;p&gt;
SHA1 support is a different story. Note that SHA 256 is also supported by the hw.&lt;br&gt;
&lt;/div&gt;

      
      </description>
    </item>
    <item rdf:about="http://lwn.net/Articles/338891/rss">
      <title>Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)</title>
      <link>http://lwn.net/Articles/338891/rss</link>
      <dc:date>2009-06-26T16:35:12+00:00</dc:date>
      <dc:creator>drag</dc:creator>
      <description>
      &lt;div class=&quot;FormattedComment&quot;&gt;
There is some sort of kernel problem with some versions of Intel driver that cases the kernel to use large amounts of RAM in a way that does not show up on typical userspace tools.&lt;br&gt;
&lt;p&gt;
I don't know what the hell was going on. &lt;br&gt;
&lt;p&gt;
I was confused on how to deal with it and tried to file a bug report, to which I was informed I did not know what I was talking about and was left with no explanation as to why 'free' was reporting only 400 megs of a 2GB system was used while the system was swapping heavily. &lt;br&gt;
&lt;p&gt;
So I gave up. &lt;br&gt;
&lt;p&gt;
It seems that later versions of the kernel some how magically fixed this problem, but I have no idea.&lt;br&gt;
&lt;/div&gt;

      
      </description>
    </item>
    <item rdf:about="http://lwn.net/Articles/338883/rss">
      <title>Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)</title>
      <link>http://lwn.net/Articles/338883/rss</link>
      <dc:date>2009-06-26T16:30:25+00:00</dc:date>
      <dc:creator>drag</dc:creator>
      <description>
      &lt;div class=&quot;FormattedComment&quot;&gt;
You can get a rough estimate though. &lt;br&gt;
&lt;p&gt;
The easiest way to look at it is to use the gnome-system-monitor, although you can get similar by using the ps and playing around with the &quot;-o %format&quot; output options.&lt;br&gt;
&lt;p&gt;
So according to the gnome-system-monitor I am using about 399MB of ram for active processes. Which is about 10% of the total amount that I have on this system.&lt;br&gt;
&lt;p&gt;
when you take a look at gnome-panel it has a 348MB 'Virtual Memory' used. But the actual amount of memory that it is using is 30.5MB. Out of that 11.4MB is shared with other applications. &lt;br&gt;
&lt;p&gt;
So in fact the penalty for me running Gnome-panel on a Gnome desktop is about 19MB.  Which is quite a bit for a normally static set of pixels, but the utility of it for me it is a nice trade off.&lt;br&gt;
&lt;p&gt;
-------------------&lt;br&gt;
&lt;p&gt;
&lt;p&gt;
From experience you need to have about a 800-1ghz Pentium-III processor with 512MB of RAM to run Gnome comfortably. &lt;br&gt;
&lt;p&gt;
XFCE does a little bit better, but it's not so much better that you can comfortably run it in 256MB. You can, but I would not want to use such a system.&lt;br&gt;
&lt;p&gt;
And it's similar for KDE. &lt;br&gt;
&lt;p&gt;
It seems to me that any system of similar complexity you are going to use about the same amount of RAM and resources and there isn't anything you can do about it. &lt;br&gt;
&lt;p&gt;
If you want simplier system then LXDE provides a familiar desktop environment for most folks and can run comfortably on a 128MB PC, of course then your resources are dictated by the applications your running.. basically if you want to run both Firefox and OO.org side by side your going to want more then that.&lt;br&gt;
&lt;/div&gt;

      
      </description>
    </item>
    <item rdf:about="http://lwn.net/Articles/338890/rss">
      <title>Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)</title>
      <link>http://lwn.net/Articles/338890/rss</link>
      <dc:date>2009-06-26T16:29:58+00:00</dc:date>
      <dc:creator>nix</dc:creator>
      <description>
      &lt;div class=&quot;FormattedComment&quot;&gt;
I thought that required support from the kernel?&lt;br&gt;
&lt;p&gt;
If not, then, well, great.&lt;br&gt;
&lt;p&gt;
(I also have an AMD Geode, a now-moribund CPU which has in-hardware AES support with kernel support in the crypto layer. I'm fairly sure OpenSSL engine support for *that* *does* require /dev/crypto...)&lt;br&gt;
&lt;p&gt;
&lt;/div&gt;

      
      </description>
    </item>
    <item rdf:about="http://lwn.net/Articles/338889/rss">
      <title>Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)</title>
      <link>http://lwn.net/Articles/338889/rss</link>
      <dc:date>2009-06-26T16:27:57+00:00</dc:date>
      <dc:creator>NAR</dc:creator>
      <description>
      &lt;div class=&quot;FormattedComment&quot;&gt;
I don't know, but my computer tends to swap even with 2 GB RAM, so I really do think there are memory leaks in those particular applications. I also do think that if they can't write/release a simple clock applet without memory leaks, then there are serious problems with the development process.&lt;br&gt;
&lt;/div&gt;

      
      </description>
    </item>
    <item rdf:about="http://lwn.net/Articles/338887/rss">
      <title>Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)</title>
      <link>http://lwn.net/Articles/338887/rss</link>
      <dc:date>2009-06-26T16:27:34+00:00</dc:date>
      <dc:creator>cortana</dc:creator>
      <description>
      &lt;div class=&quot;FormattedComment&quot;&gt;
VIRT sure, but I thought RES was the portion of the process' virtual memory that is resident in physical RAM?&lt;br&gt;
&lt;p&gt;
Of course there are other resources to consider such as memory-mapped files, memory allocated on behalf of a process by the X server, etc. But the RES column doesn't sound too wrong on my system:&lt;br&gt;
&lt;p&gt;
208M epiphany-browser&lt;br&gt;
62776 X&lt;br&gt;
45600 evolution&lt;br&gt;
39204 emapthy&lt;br&gt;
34104 gnome-panel&lt;br&gt;
31388 tomboy&lt;br&gt;
25228 nautilus&lt;br&gt;
24292 xchat&lt;br&gt;
23364 gnome-power-manager&lt;br&gt;
22800 nm-applet&lt;br&gt;
21908 gnome-terminal&lt;br&gt;
20248 vim&lt;br&gt;
&lt;p&gt;
and so on&lt;br&gt;
&lt;/div&gt;

      
      </description>
    </item>
    <item rdf:about="http://lwn.net/Articles/338888/rss">
      <title>Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)</title>
      <link>http://lwn.net/Articles/338888/rss</link>
      <dc:date>2009-06-26T16:26:54+00:00</dc:date>
      <dc:creator>ledow</dc:creator>
      <description>
      &lt;div class=&quot;FormattedComment&quot;&gt;
Not only that, but a lot of programs self-adjust to the installed memory.  If you were to run on a 512Mb machine, it would still work, it would just use less for certain tasks and/or heavily optimise certain caches.&lt;br&gt;
&lt;/div&gt;

      
      </description>
    </item>
    <item rdf:about="http://lwn.net/Articles/338885/rss">
      <title>Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)</title>
      <link>http://lwn.net/Articles/338885/rss</link>
      <dc:date>2009-06-26T16:21:51+00:00</dc:date>
      <dc:creator>cortana</dc:creator>
      <description>
      &lt;p&gt;To be fair, you appear to be running some &lt;a href=&quot;http://www.gnome.org/~federico/news-2007-11.html#16&quot;&gt;comedy fork&lt;/a&gt; of the GNOME panel that includes an SVG image with an incredibly detailed outline of the planet's continents that is rendered at a huge size and then shaded with a ray tracer, before being scaled down to be 200 pixels wide...

&lt;p&gt;I believe these features were merged into the GNOME panel for version 2.22, and the GNOME developers did a much better job: on my system (Debian applies no substantial patches to GNOME packages, so this is practically as good as using upstream's version directly), gnome-panel has 33.3 MiB resident. This is still too high IMO, but it is far more reasonable than the 900 MiB that it consumes on your system!
      
      </description>
    </item>
    <item rdf:about="http://lwn.net/Articles/338881/rss">
      <title>Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)</title>
      <link>http://lwn.net/Articles/338881/rss</link>
      <dc:date>2009-06-26T15:42:11+00:00</dc:date>
      <dc:creator>drag</dc:creator>
      <description>
      &lt;div class=&quot;FormattedComment&quot;&gt;
That's not true. &lt;br&gt;
&lt;p&gt;
Openssl can happily use the padlock engine. Its a combination of a compile time then a run time configuration option, then it'll take advantage of it.&lt;br&gt;
&lt;p&gt;
Then from OpenSSL you can get it supported in OpenVPN and in OpenSSH.&lt;br&gt;
&lt;p&gt;
Probably not as nice as having a 'crypto device' or whatever, but it is supported by a number of applications.&lt;br&gt;
&lt;/div&gt;

      
      </description>
    </item>
    <item rdf:about="http://lwn.net/Articles/338880/rss">
      <title>Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)</title>
      <link>http://lwn.net/Articles/338880/rss</link>
      <dc:date>2009-06-26T15:27:48+00:00</dc:date>
      <dc:creator>drag</dc:creator>
      <description>
      &lt;div class=&quot;FormattedComment&quot;&gt;
&lt;font class=&quot;QuotedText&quot;&gt;&amp;gt; It always amazes me when someone reviews some piece of low-powered tech and marvels at how it can &quot;load multiple applications&quot; or &quot;play DVD's flawlessly&quot;, etc. My 233MHz/64Mb could do that, my 500MHz/128Mb certainly could, my 600MHz/384Mb IBM laptop did it spectacularly. How is it shocking that a 1.3Ghz/1Gb device can? Yes, the apps are bloating all the time but really - running more than one app smoothly in 1Gb of RAM is hardly news.&lt;/font&gt;&lt;br&gt;
&lt;p&gt;
It's news if your a Windows user. XP will be fast for a while and it'll be like that until you start using it and installing software in order to get stuff done. &lt;br&gt;
&lt;p&gt;
After that then only very fast computer is a fast computer.&lt;br&gt;
&lt;/div&gt;

      
      </description>
    </item>
    <item rdf:about="http://lwn.net/Articles/338879/rss">
      <title>Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)</title>
      <link>http://lwn.net/Articles/338879/rss</link>
      <dc:date>2009-06-26T15:22:22+00:00</dc:date>
      <dc:creator>kieran</dc:creator>
      <description>
      &lt;div class=&quot;FormattedComment&quot;&gt;
incorrect. openssl has an engine for it.&lt;br&gt;
&lt;p&gt;
~$ openssl version&lt;br&gt;
OpenSSL 0.9.8k 25 Mar 2009&lt;br&gt;
&lt;p&gt;
~$ openssl engine&lt;br&gt;
(padlock) VIA PadLock (no-RNG, ACE)&lt;br&gt;
(dynamic) Dynamic engine loading support&lt;br&gt;
&lt;p&gt;
&lt;a rel=&quot;nofollow&quot; href=&quot;http://www.logix.cz/michal/devel/padlock/&quot;&gt;http://www.logix.cz/michal/devel/padlock/&lt;/a&gt;&lt;br&gt;
&lt;/div&gt;

      
      </description>
    </item>
    <item rdf:about="http://lwn.net/Articles/338874/rss">
      <title>some circumstances</title>
      <link>http://lwn.net/Articles/338874/rss</link>
      <dc:date>2009-06-26T15:02:59+00:00</dc:date>
      <dc:creator>tialaramex</dc:creator>
      <description>
      &lt;div class=&quot;FormattedComment&quot;&gt;
That's partly due to the fact that 4Gb is a limit in some circumstances&lt;br&gt;
&lt;p&gt;
For the Windows gamers who make up Steam's audience, Win64 is generally not an option, both in the sense that there's a good chance it is missing a driver or incompatible with some of their software, and because it probably wasn't offered to them with the PC, and they're surely not going to upgrade to it afterwards.&lt;br&gt;
&lt;p&gt;
I think this will look like a blip on long term charts, with Windows PC buyers getting no extra RAM for a few years through to say 2010, and then suddenly it shoots up - once you /can/ put 8GiB into a desktop PC and expect it to work (ie most PCs come with Win64) the prices for the larger DIMM sizes come down, and suddenly 4GiB is &quot;entry level&quot; ie not enough.&lt;br&gt;
&lt;p&gt;
I certainly haven't seen any sign that the DRAM industry expects people to decide that for some reason 2^32 is enough forever and they'll stick with that. If not for Microsoft's difficult relationship with ISVs and hardware vendors, I think 6GiB would already be commonplace.&lt;br&gt;
&lt;/div&gt;

      
      </description>
    </item>
    <item rdf:about="http://lwn.net/Articles/338873/rss">
      <title>Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)</title>
      <link>http://lwn.net/Articles/338873/rss</link>
      <dc:date>2009-06-26T14:49:00+00:00</dc:date>
      <dc:creator>tzafrir</dc:creator>
      <description>
      &lt;div class=&quot;FormattedComment&quot;&gt;
But until the real world can use it, it is pretty useless (by definition).&lt;br&gt;
&lt;p&gt;
An optimized hardware implementation tends to use its own unique interface. Even if two years later a standard has emerged, you can't simply modify existing units.&lt;br&gt;
&lt;p&gt;
E.g.: Wouldn't you like to see SHA-512? Well, by the time they finish adding it, we'll already have a SHA-3 out.&lt;br&gt;
&lt;/div&gt;

      
      </description>
    </item>
    <item rdf:about="http://lwn.net/Articles/338872/rss">
      <title>Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)</title>
      <link>http://lwn.net/Articles/338872/rss</link>
      <dc:date>2009-06-26T14:44:39+00:00</dc:date>
      <dc:creator>timschmidt</dc:creator>
      <description>
      &lt;div class=&quot;FormattedComment&quot;&gt;
You're not reading top's output properly.  The RES and VIRT columns do not accurately represent the true physical amount of memory used by a process.  In fact, measuring the actual amount of memory used by a process on a modern OS (Linux and Windows at least) is a _very_ hard thing to do.  AFAIK, nothing short of running said process with valgrind will do.&lt;br&gt;
&lt;/div&gt;

      
      </description>
    </item>
    <item rdf:about="http://lwn.net/Articles/338871/rss">
      <title>Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)</title>
      <link>http://lwn.net/Articles/338871/rss</link>
      <dc:date>2009-06-26T14:13:49+00:00</dc:date>
      <dc:creator>nix</dc:creator>
      <description>
      &lt;div class=&quot;FormattedComment&quot;&gt;
Of course Linux userspace can't use it, because the Linux equivalent of the BSD /dev/crypto is *still* not merged, three or so years after initial implementation.&lt;br&gt;
&lt;p&gt;
So it's useless for e.g. OpenSSL.&lt;br&gt;
&lt;p&gt;
&lt;/div&gt;

      
      </description>
    </item>
    <item rdf:about="http://lwn.net/Articles/338868/rss">
      <title>Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)</title>
      <link>http://lwn.net/Articles/338868/rss</link>
      <dc:date>2009-06-26T13:31:28+00:00</dc:date>
      <dc:creator>ballombe</dc:creator>
      <description>
      &lt;div class=&quot;FormattedComment&quot;&gt;
The VIA C7 already had hardware SHA1 and was released 4 year ago.&lt;br&gt;
However support for this hardware feature in software is much more recent.&lt;br&gt;
&lt;/div&gt;

      
      </description>
    </item>
    <item rdf:about="http://lwn.net/Articles/338863/rss">
      <title>Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)</title>
      <link>http://lwn.net/Articles/338863/rss</link>
      <dc:date>2009-06-26T12:18:03+00:00</dc:date>
      <dc:creator>NAR</dc:creator>
      <description>
      &lt;I&gt;1GB is more than enough for a good desktop to run lots of large applications simultaneously.&lt;/I&gt;
&lt;P&gt;
Well, I happen to run a not so good desktop called GNOME 2.12.2 and top show me this:
&lt;CODE&gt;&lt;BR&gt;
  PID USER PR  NI  RES  VIRT  SHR S %CPU %MEM    TIME+  COMMAND&lt;BR&gt;
 4799 e    16   0 451m  582m 7180 S    0 22.3  11:51.47 intlclock-apple&lt;BR&gt;
 4793 e    16   0 447m  559m 9412 S    0 22.1  14:50.55 gnome-panel&lt;BR&gt;
&lt;/CODE&gt;
&lt;P&gt;
My English is not sufficient to describe my feelings about this.
      
      </description>
    </item>
    <item rdf:about="http://lwn.net/Articles/338852/rss">
      <title>Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)</title>
      <link>http://lwn.net/Articles/338852/rss</link>
      <dc:date>2009-06-26T10:43:37+00:00</dc:date>
      <dc:creator>ledow</dc:creator>
      <description>
      &lt;div class=&quot;FormattedComment&quot;&gt;
&quot;The system seemed to handle multiple applications loaded at the same time even with just 1 GB of memory.&quot;&lt;br&gt;
&lt;p&gt;
Considering they are discussing Firefox, Open Office, the GIMP and VLC - I should bloody hope so.  1GB is more than enough for a good desktop to run lots of large applications simultaneously.  One of my home PC's running KDE4 does all of the above (except Opera instead of Firefox) and never shows a real problem and that's a cobbled-together thing with the cheapest memory chips I could buy about five years ago.&lt;br&gt;
&lt;p&gt;
Some people just assume that they have to have more in their PC than they actually do.  I can't tell you the number of people who *still* slate laptops for not being &quot;3D gaming&quot; machines and then play on their PC's which have a PCIe card vastly inferior to their laptops onboard graphics.  My current laptop actually does widescreen 3D and PhysX better than the PC's of most of the &quot;gamers&quot; that I know.&lt;br&gt;
&lt;p&gt;
They are just so used to having to have a 3D card they don't recognise when top-of-the-range becomes bog-standard.  The same thing happened several years ago with soundcards - the onboard sound on 99% of machines is no different for &quot;ordinary people&quot; than a £200 add-in card.&lt;br&gt;
&lt;p&gt;
1Gb is fairly bog-standard nowadays, but memory is pretty much standardising between 1 and 4Gb for almost every use except high-end servers.  Things like Steam's hardware survey will show you this, and that's based on the usage of &quot;hardcore&quot; gamers.  That's partly due to the fact that 4Gb is a limit in some circumstances, but mainly because 1Gb is pretty much enough to do just about anything and 2Gb+ just gives you a nice comfort zone if it's cheap enough.&lt;br&gt;
&lt;p&gt;
It always amazes me when someone reviews some piece of low-powered tech and marvels at how it can &quot;load multiple applications&quot; or &quot;play DVD's flawlessly&quot;, etc.  My 233MHz/64Mb could do that, my 500MHz/128Mb certainly could, my 600MHz/384Mb IBM laptop did it spectacularly.  How is it shocking that a 1.3Ghz/1Gb device can?  Yes, the apps are bloating all the time but really - running more than one app smoothly in 1Gb of RAM is hardly news.&lt;br&gt;
&lt;/div&gt;

      
      </description>
    </item>
    <item rdf:about="http://lwn.net/Articles/338851/rss">
      <title>Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)</title>
      <link>http://lwn.net/Articles/338851/rss</link>
      <dc:date>2009-06-26T10:20:29+00:00</dc:date>
      <dc:creator>jamesh</dc:creator>
      <description>
      &lt;div class=&quot;FormattedComment&quot;&gt;
Then I guess it is a good thing that it also includes SHA-256 support (from the SHA-2 family).&lt;br&gt;
&lt;p&gt;
It's going to take a long time for SHA-1 to become irrelevant, so it seems like a useful feature.&lt;br&gt;
&lt;/div&gt;

      
      </description>
    </item>
</rdf:RDF>

