Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)
At the heart of the Shuttle XS29f is the Nano, Via's first 64-bit processor in their x86 line. The Nano delivers high-end performance with low power requirements. Two memory slots support up to 4 GB of memory to go along with the Via 1.3 GHz Nano processor. It uses DDR2 memory, which is pretty inexpensive right now. Two internal SATA-II connectors support internal storage."
Posted Jun 26, 2009 0:55 UTC (Fri)
by ncm (guest, #165)
[Link] (25 responses)
Posted Jun 26, 2009 1:21 UTC (Fri)
by Kit (guest, #55925)
[Link] (23 responses)
Posted Jun 26, 2009 7:10 UTC (Fri)
by timschmidt (guest, #38269)
[Link]
Posted Jun 26, 2009 7:41 UTC (Fri)
by tzafrir (subscriber, #11501)
[Link] (15 responses)
Posted Jun 26, 2009 7:52 UTC (Fri)
by brother_rat (subscriber, #1895)
[Link] (11 responses)
Posted Jun 28, 2009 19:36 UTC (Sun)
by sbergman27 (guest, #10767)
[Link] (10 responses)
Posted Jun 28, 2009 20:03 UTC (Sun)
by brother_rat (subscriber, #1895)
[Link] (9 responses)
I'm guessing that a "porch light" is normally left on all evening in your part of the world? I'd say we
Incidentally, they are due to stop selling 60W light bulbs in January 2010 here, and also in the rest
Posted Jun 28, 2009 21:55 UTC (Sun)
by nix (subscriber, #2304)
[Link] (4 responses)
And 60W is not enough to read by :(
Posted Jun 29, 2009 9:27 UTC (Mon)
by farnz (subscriber, #17727)
[Link] (2 responses)
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.
Posted Jun 29, 2009 12:19 UTC (Mon)
by nye (subscriber, #51576)
[Link] (1 responses)
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.
Posted Jun 29, 2009 12:37 UTC (Mon)
by farnz (subscriber, #17727)
[Link]
One thing to watch for - incandescent lights warm up almost instantly, whereas CFLs take ten to fifteen minutes to warm up.
Note also that CFLs tend to be bluer than incandescents once running - if this bothers you, halogens are your best bet.
Posted Jul 2, 2009 19:00 UTC (Thu)
by NRArnot (subscriber, #3033)
[Link]
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.
Posted Jun 28, 2009 21:56 UTC (Sun)
by dlang (guest, #313)
[Link] (3 responses)
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.
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)
I use florescent lights in many locations, and LED lights in others, but I also recognise that they are not right for everywhere.
Posted Jun 29, 2009 4:51 UTC (Mon)
by eru (subscriber, #2753)
[Link]
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 "compatible" 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):
http://www.osram.com/osram_com/Consumer/Home_Lighting/Halogen_lamps/Product_overview/Screw_bases/ENERGY_SAVER/HALOGEN_ENERGY_SAVER_Classic_A/index.html
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...
Posted Jun 30, 2009 19:41 UTC (Tue)
by Wol (subscriber, #4433)
[Link] (1 responses)
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 ...
Cheers,
Posted Jun 30, 2009 21:09 UTC (Tue)
by dlang (guest, #313)
[Link]
this isn't just a case of CFL, normal FL have the same problem, power cycling them drasticly cuts down on their life
Posted Jun 26, 2009 10:20 UTC (Fri)
by jamesh (guest, #1159)
[Link]
It's going to take a long time for SHA-1 to become irrelevant, so it seems like a useful feature.
Posted Jun 26, 2009 13:31 UTC (Fri)
by ballombe (subscriber, #9523)
[Link] (1 responses)
Posted Jun 26, 2009 14:49 UTC (Fri)
by tzafrir (subscriber, #11501)
[Link]
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.
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.
Posted Jun 26, 2009 14:13 UTC (Fri)
by nix (subscriber, #2304)
[Link] (5 responses)
So it's useless for e.g. OpenSSL.
Posted Jun 26, 2009 15:22 UTC (Fri)
by kieran (guest, #59319)
[Link]
~$ openssl version
~$ openssl engine
Posted Jun 26, 2009 15:42 UTC (Fri)
by drag (guest, #31333)
[Link] (2 responses)
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.
Then from OpenSSL you can get it supported in OpenVPN and in OpenSSH.
Probably not as nice as having a 'crypto device' or whatever, but it is supported by a number of applications.
Posted Jun 26, 2009 16:29 UTC (Fri)
by nix (subscriber, #2304)
[Link] (1 responses)
If not, then, well, great.
(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...)
Posted Jun 26, 2009 18:06 UTC (Fri)
by drag (guest, #31333)
[Link]
> If not, then, well, great.
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)
Beyond that I don't know.
Posted Jun 26, 2009 16:43 UTC (Fri)
by ballombe (subscriber, #9523)
[Link]
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.
SHA1 support is a different story. Note that SHA 256 is also supported by the hw.
Posted Jun 27, 2009 14:14 UTC (Sat)
by ariveira (guest, #57833)
[Link]
Posted Jun 26, 2009 10:43 UTC (Fri)
by ledow (guest, #11753)
[Link] (18 responses)
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.
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 "3D gaming" 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 "gamers" that I know.
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 "ordinary people" than a £200 add-in card.
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 "hardcore" 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.
It always amazes me when someone reviews some piece of low-powered tech and marvels at how it can "load multiple applications" or "play DVD's flawlessly", 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.
Posted Jun 26, 2009 12:18 UTC (Fri)
by NAR (subscriber, #1313)
[Link] (14 responses)
Well, I happen to run a not so good desktop called GNOME 2.12.2 and top show me this:
My English is not sufficient to describe my feelings about this.
Posted Jun 26, 2009 14:44 UTC (Fri)
by timschmidt (guest, #38269)
[Link] (12 responses)
Posted Jun 26, 2009 16:26 UTC (Fri)
by ledow (guest, #11753)
[Link]
Posted Jun 26, 2009 16:27 UTC (Fri)
by cortana (subscriber, #24596)
[Link] (1 responses)
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:
208M epiphany-browser
and so on
Posted Jun 26, 2009 18:14 UTC (Fri)
by drag (guest, #31333)
[Link]
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).
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.
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.
*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.
Posted Jun 26, 2009 16:27 UTC (Fri)
by NAR (subscriber, #1313)
[Link] (1 responses)
Posted Jun 26, 2009 16:35 UTC (Fri)
by drag (guest, #31333)
[Link]
I don't know what the hell was going on.
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.
So I gave up.
It seems that later versions of the kernel some how magically fixed this problem, but I have no idea.
Posted Jun 26, 2009 16:30 UTC (Fri)
by drag (guest, #31333)
[Link] (6 responses)
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 "-o %format" output options.
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.
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.
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.
-------------------
From experience you need to have about a 800-1ghz Pentium-III processor with 512MB of RAM to run Gnome comfortably.
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.
And it's similar for KDE.
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.
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.
Posted Jun 29, 2009 5:35 UTC (Mon)
by eru (subscriber, #2753)
[Link] (5 responses)
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:
Posted Jun 29, 2009 7:30 UTC (Mon)
by dlang (guest, #313)
[Link] (4 responses)
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.
Posted Jun 29, 2009 9:35 UTC (Mon)
by eru (subscriber, #2753)
[Link] (3 responses)
Posted Jun 29, 2009 9:43 UTC (Mon)
by dlang (guest, #313)
[Link] (2 responses)
the X configuration solutions are independant of the desktop (although there are tools available as part of the desktops to tweak the config)
access to removable media is automounter plus a single app, again, not very involved with either gnome or kde
both of these things are available if you the same windowmaker desktop that I ran many years ago with 128k of ram.
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.
Posted Jun 29, 2009 10:35 UTC (Mon)
by eru (subscriber, #2753)
[Link] (1 responses)
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?
Posted Jun 29, 2009 16:59 UTC (Mon)
by dlang (guest, #313)
[Link]
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.
Posted Jun 26, 2009 16:21 UTC (Fri)
by cortana (subscriber, #24596)
[Link]
To be fair, you appear to be running some comedy fork 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...
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!
Posted Jun 26, 2009 15:02 UTC (Fri)
by tialaramex (subscriber, #21167)
[Link]
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.
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 "entry level" ie not enough.
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.
Posted Jun 26, 2009 15:27 UTC (Fri)
by drag (guest, #31333)
[Link] (1 responses)
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.
After that then only very fast computer is a fast computer.
Posted Jul 2, 2009 19:06 UTC (Thu)
by NRArnot (subscriber, #3033)
[Link]
And I wonder whether it can run VMware (which does NOT require the VT extentions, by the way).
Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)
Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)
Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)
Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)
The reviewer is a bit behind the times too - "... less than half the 60 watt light bulb..."
should be
"... almost double the 15 watt light bulb..."
Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)
Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)
Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)
and I reckon there's at least 80% energy efficient bulbs. Most of the remaining incandescent bulbs
are spot lights or "candle" type bulbs, which I guess makes sense. For reference I'm in Bath, UK.
started using efficient fluorescent bulbs for those kind of things 10-15 years ago.
of Europe on a similar timescale.
Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)
be no energy-efficient bulb on sale equivalent to the old 100W bulbs: they
go up to 60W-equivalent and then stop.
Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)
Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)
Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)
Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)
Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)
(motion sensor controlled) and had it burn out in a few months.
I put one in a a place that had high cycle rates (motion sensor controlled) and had it burn out in a few months.
Replace with halogens
Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)
Wol
Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)
Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)
Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)
However support for this hardware feature in software is much more recent.
Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)
Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)
Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)
OpenSSL 0.9.8k 25 Mar 2009
(padlock) VIA PadLock (no-RNG, ACE)
(dynamic) Dynamic engine loading support
Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)
Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)
Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)
Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)
Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)
Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)
1GB is more than enough for a good desktop to run lots of large applications simultaneously.
Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)
PID USER PR NI RES VIRT SHR S %CPU %MEM TIME+ COMMAND
4799 e 16 0 451m 582m 7180 S 0 22.3 11:51.47 intlclock-apple
4793 e 16 0 447m 559m 9412 S 0 22.1 14:50.55 gnome-panel
Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)
Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)
Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)
62776 X
45600 evolution
39204 emapthy
34104 gnome-panel
31388 tomboy
25228 nautilus
24292 xchat
23364 gnome-power-manager
22800 nm-applet
21908 gnome-terminal
20248 vim
Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)
Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)
Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)
Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)
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.
The Grand Guignol
- 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?
- 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.
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 "obsolete" system (library revisions and so on). Linux has its own version of the "upgrade treadmill", it just is powered in a bit different way from the Windows one.
The Grand Guignol
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...
The Grand Guignol
The Grand Guignol
access to removable media is automounter plus a single app, again, not very involved with either gnome or kde
The Grand Guignol
The Grand Guignol
Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)
some circumstances
Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)
Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)