Note the article says ARM *server* processors. In that market, GPUs are totally irrelevant, power usage is secondary to performance, and price of the CPU is a distant third.
Power usage translates directly into heat, so if you have a CPU that takes 10x less power you can cram 10x more of them onto the same server.
That's exactly what SRV records are for. They first made MX records for email. Then they realized that other services need special records too, and added the service-independent SRV record.
Unfortunately this means every write to the display now has to go via the kernel instead of going direct.
No, if you mmap() the framebuffer you (as in the application) write directly to video memory (of course, what you say is true if the application uses lseek() and write() instead, but why would it?). The reason it's slower is because drivers make the GPU do all the heavy lifting. The only abstract thing about the Linux framebuffer is that you don't have to map the memory yourself, the kernel drivers do it for you.
x11vnc is not limited to X. It can also remote control a console session on a Linux framebuffer device, and a few other things.
Also, from TFA:
- Jesse has been playing around a bit with some remote Wayland support using libvncserver. He's apparently had some success with this and expects to push some code upstream soon.
unless you create an infrastructure that regulates how many vehicles can charge at any one time
Like a limited number of refueling stations? If recharging only takes six minutes and needs special equipment (thick cables, giant power transformers, etc.), people probably won't charge their cars at home.
The difference is that with all the things you mentioned, you know the expected lifespan when you pay for them. When you buy a game, you don't expect it to stop working 5 years later, when the company that made it goes out of business.
Phone electronics are already small enough. Most of a smartphone's power usage is its screen, and most of its weight is its battery. Shrinking the screen will lower the phone's power consumption, thus allowing for a smaller battery.
And what is that external source on Earth? Meteors maybe? Of course you exhale the exact same amount. Unless, of course, you put on fat in the process.
Who said anything about perpetual motion? Humans consume carbon and oxygen, creating carbon dioxide. Plants split that carbon dioxide back into carbon and oxygen, using ultra-violet light.
It's all just like on Earth, except using a nuclear reactor as a power source instead of the sun.
Did you even read my post? Vegetation grown by nuclear-powered artificial light provides food and oxygen, and a water recycling system provides that (assuming you start with enough).
It has at least two other issues: it doesn't support ext3 journaling (so ext3 is treated as ext2), and it can't fsck (and because it doesn't support ext3, it can't do a journal replay either), which means that it can't mount a dirty volume until it is mounted by Linux.
Every other modern system does it (Quartz, GDI+), and X's early competitors did it (NeWS comes to mind). Putting widgets in the client (or even in a client library, such as QT or GTK) is unnecessary overhead, and results in inconsistent environments (think QT apps in GNOME).
Correct me if I'm wrong, but I thought runtime linking wasn't covered by the GPL. Otherwise, you wouldn't be able to use bash in OpenSolaris, as its libc is CDDLd.
Slashdot Mirror
Evil, obviously.
Note the article says ARM *server* processors. In that market, GPUs are totally irrelevant, power usage is secondary to performance, and price of the CPU is a distant third.
Power usage translates directly into heat, so if you have a CPU that takes 10x less power you can cram 10x more of them onto the same server.
That's exactly what SRV records are for. They first made MX records for email. Then they realized that other services need special records too, and added the service-independent SRV record.
Unfortunately this means every write to the display now has to go via the kernel instead of going direct.
No, if you mmap() the framebuffer you (as in the application) write directly to video memory (of course, what you say is true if the application uses lseek() and write() instead, but why would it?). The reason it's slower is because drivers make the GPU do all the heavy lifting. The only abstract thing about the Linux framebuffer is that you don't have to map the memory yourself, the kernel drivers do it for you.
If this board had a few spare GPIO pins brought out to a header there really wouldn't be a reason for Pi to exist at this point.
Except that it costs twice as much and draws more power, so it you don't need all the extra functionality it's a waste of money and electricity.
Not that I'm saying it's not needed. There probably will be a larger, more expensive version of the Raspberry Pi.
- Jesse has been playing around a bit with some remote Wayland support using libvncserver. He's apparently had some success with this and expects to push some code upstream soon.
So there are already people working on it.
Fujitsu never implemented OpenSPARC. They developed the SPARC64 themselves, and the UltraSPARCs in their machines are manufactured by Oracle.
unless you create an infrastructure that regulates how many vehicles can charge at any one time
Like a limited number of refueling stations? If recharging only takes six minutes and needs special equipment (thick cables, giant power transformers, etc.), people probably won't charge their cars at home.
Not true. The GPL includes a patent license. By releasing the code under it, Oracle gave everyone the right to use their patents freely.
The difference is that with all the things you mentioned, you know the expected lifespan when you pay for them. When you buy a game, you don't expect it to stop working 5 years later, when the company that made it goes out of business.
Phone electronics are already small enough. Most of a smartphone's power usage is its screen, and most of its weight is its battery. Shrinking the screen will lower the phone's power consumption, thus allowing for a smaller battery.
If it were in the public domain, someone would have collected it and put it online. Google Books comes to mind.
4) The assumption that spammers would have a hard time spamming because they would have trouble keeping their servers reachable is false.
Sure, but then the servers couldn't be botnets, so you would know where the are and could take them down or block them.
And what is that external source on Earth? Meteors maybe? Of course you exhale the exact same amount. Unless, of course, you put on fat in the process.
Who said anything about perpetual motion? Humans consume carbon and oxygen, creating carbon dioxide. Plants split that carbon dioxide back into carbon and oxygen, using ultra-violet light.
It's all just like on Earth, except using a nuclear reactor as a power source instead of the sun.
Did you even read my post? Vegetation grown by nuclear-powered artificial light provides food and oxygen, and a water recycling system provides that (assuming you start with enough).
You forget the most important part of Boot Camp: the BIOS emulation layer that allows Windows to boot.
Macs could dual-boot long before Boot Camp came along.
It doesn't have to. Windows machines come with Windows drivers. Macs don't.
You seem to forget that a human scientist can do in a day what a rover does in a year.
With a few nuclear reactors, a water recycling system and some vegetation, settlers can survive indefinitely.
It has at least two other issues: it doesn't support ext3 journaling (so ext3 is treated as ext2), and it can't fsck (and because it doesn't support ext3, it can't do a journal replay either), which means that it can't mount a dirty volume until it is mounted by Linux.
"Cold fusion" doesn't mean cold enough to touch, it means cold compared to the sun, somewhere in the range of a modern nuclear reactor.
Blackholes don't block.
Actually, they do if you get close enough.
That's one deadlock you're not getting out of!
Every other modern system does it (Quartz, GDI+), and X's early competitors did it (NeWS comes to mind).
Putting widgets in the client (or even in a client library, such as QT or GTK) is unnecessary overhead, and results in inconsistent environments (think QT apps in GNOME).
What about widgets not being part of the server?
Correct me if I'm wrong, but I thought runtime linking wasn't covered by the GPL. Otherwise, you wouldn't be able to use bash in OpenSolaris, as its libc is CDDLd.