-Sun forks a opensource project - Xen -Sun continues developing their fork in a propietary way -Now they release it as opensource! OMG we opensourced it!
Sorry, but this is not interesting. This looks like the typical "I'm going to make my own fork" effort. Sun has probably already lost many of the features being coded in Xen right now just because of the fork.
There're not many spanish-speaking programmers. Most of the spanish speakers live in countries where getting a internet connection is not so easy as in EEUU/europe/japan
"movie studios"? Yeah, I'm sure Intel is putting a GPU in every Intel CPU (80% of the desktop market) just to make a couple of companies happy.
Why wouldn't Intel want to be a Nvidia's competitor? Intel has been the top seller of graphic chips, more than nvidia or ati, for some years. I'd say that they have been competing for a looong time now.
Intel has been very succesful with their integrated graphic chips because most of people on the world only need a chip that can draw Windows. Apparently, now they want to go beyond of that. Larrabee cant catch Nvidia, but it will be "fast enought" to become a important target for game developers. Nvidia always keep the "top-performance" tip of the market share, but that tip is becoming smaller and smaller.
Another 64K addresses would make it harder to hack.
You said it, it'd make it harder, but not impossible, specially with hardware geting faster every year.
Re:Clever new tools for kernel config
on
Linux 2.6.26 Out
·
· Score: 1
Thats what udev does. And it does it without even recompiling the kernel - it works with standard kernels. Awesome!
Seriously, better config tools are not needed because normal people does NOT need to compile the kernel. Compiling your kernel "just because" it's like recompiling libc. You CAN do it, but not many people does it and people who does do not need better config tools.
No, it can't. XFS has not the concept of "storage pool" that ZFS and AdvFS have. It doesn't have ZFS/AdvFS-style snapshots. XFS is also a journaling filesystem, unlike ZFS (AdvFS however is a journaled filesystem - and even then, the journaling modes of advfs allow to configure a much better data integrity than ZFS)
It doesnt use the native widgets. It uses its own widgets and then it paints them so that they look like they were native (other browsers also do this)
Re:Haven't really noticed any reduced quality ..
on
The State of X.Org
·
· Score: 3, Informative
I disagree that there's not that much going on - using the standard pci interfaces to access the devices, the recent input hotplug work, the new acceleration architectures in the DRM side...
Re:Finally, developers' ignorance and childish
on
The State of X.Org
·
· Score: 3, Informative
Internally, X11 running in local mode works the same way as Apple's window server - using shared memory and local sockets.
It doesn't uses shared memory, I think. There's a "shared memory" extension, but there's not a "shared memory transport" for the X11 protocol. Sun's propietary server has a shared memory transport, and it was said that they'd opensource and port it for X.org, but so far nothing has happened. It'd be an interesting thing to have, i think - today, when an application wants to display a image in the server it must send the whole image to the server (the protocol is network-oriented so it can't send a "reference" like a file, it has to send the whole data of the image). If the client app keeps the image in its memory after sending it to the server, the image is using 2x its memory size (one in the server, one in the client). With a shared memory transport, client and server could shared the memory that the image is using. Or so I've heard.
Re:Finally, developers' ignorance and childish
on
The State of X.Org
·
· Score: 1
Do they still sing "network transparency out of the box" mantra every time someone suggests changing architecture ?
They sing "not breaking the compatibility with all the graphical applications out there".
Guess what? It works fine here, and I bet that it also works for everyone using ff3, except you, for some reason (maybe your setup is broken?). I know because breaking gmail would be a very serious showstopper for ff3, and nobody has complained.
And not only it works, it works really well and the performance improvements in ff3 are so great that the speed different is noticeable.
If opera dev's team can't be beaten then they must have a ultrafast version hidden somewhere, because the public versions, including 9.5 betas, are already slower than firefox 3 and webkit on many benchmarks
The next time it'll be web page hosting what google and microsoft will be ofering, and dreamhost will have to say "choose their services, ours are not good enought"
Duh, I meant mutex/semaphore. And Linux semaphores have become slower, meanwhile mutexes still are fast as old semaphores were, as #23446368 says. The options were to move from a semaphore to mutexes or spinlocks, but Linus chose spinlocks because the RT/low-latency crow will notice it and will try to remove the remaining BKL users.
Because these days the BKL is barely used in the kernel core, or so Linus says: the core kernel, VM and networking already don't really do BKL. And it's seldom the case that subsystems interact with other unrelated subsystems outside of the core areas. IOW, it's rare to hit BKL contention - and in those cases, you want the contention period to be as short as possible. And spinlocks are the faster locking primitive, so making the BKL a spinlock (which is not preemptable) makes the BKL contention periods faster. A mutex/spinlock brings you "preemptability" and hides a bit the fact that there's a global lock being used sometimes at the expense of performance, which may be a good thing for RT/lowlatency users, but apparently Linus prefers to choose the solution that is faster and doesn't hid the real problem.
Slashdot Mirror
They hired lawyers. Lawyers don't fix problems, they create them. Here's a good example...
The Linux kernel can't have a EULA of the sort being discussed - it's impractical.
It can, it just need to be presented to the user on install time. Just like Mozilla/Ubuntu should do.
-Sun forks a opensource project - Xen
-Sun continues developing their fork in a propietary way
-Now they release it as opensource! OMG we opensourced it!
Sorry, but this is not interesting. This looks like the typical "I'm going to make my own fork" effort. Sun has probably already lost many of the features being coded in Xen right now just because of the fork.
Yeah, well, and firefox has had a extension for it since a few months later
https://update-dev.mozilla.org:8080/extensions/moreinfo.php?application=firefox&id=1306&vid=6511
direct link: https://addons.mozilla.org/en-US/firefox/addon/1306
It has 820.000 downloads, so it's not like people have been missing this functionality from firefox...
The U.S. is China's largest buyer.
The EU recently stole that place (probably due to $/ fluctuations)
There're not many spanish-speaking programmers. Most of the spanish speakers live in countries where getting a internet connection is not so easy as in EEUU/europe/japan
"movie studios"? Yeah, I'm sure Intel is putting a GPU in every Intel CPU (80% of the desktop market) just to make a couple of companies happy.
Why wouldn't Intel want to be a Nvidia's competitor? Intel has been the top seller of graphic chips, more than nvidia or ati, for some years. I'd say that they have been competing for a looong time now.
Intel has been very succesful with their integrated graphic chips because most of people on the world only need a chip that can draw Windows. Apparently, now they want to go beyond of that. Larrabee cant catch Nvidia, but it will be "fast enought" to become a important target for game developers. Nvidia always keep the "top-performance" tip of the market share, but that tip is becoming smaller and smaller.
"Extramuros" is a spanish word, so i guess there's not a lot of "bending" in it...
Another 64K addresses would make it harder to hack.
You said it, it'd make it harder, but not impossible, specially with hardware geting faster every year.
Thats what udev does. And it does it without even recompiling the kernel - it works with standard kernels. Awesome!
Seriously, better config tools are not needed because normal people does NOT need to compile the kernel. Compiling your kernel "just because" it's like recompiling libc. You CAN do it, but not many people does it and people who does do not need better config tools.
Probably clutter (http://clutter-project.org/)
64-bit firefox eats a LOT more of memory. The windows versions are 32-bit only.
No, it can't. XFS has not the concept of "storage pool" that ZFS and AdvFS have. It doesn't have ZFS/AdvFS-style snapshots. XFS is also a journaling filesystem, unlike ZFS (AdvFS however is a journaled filesystem - and even then, the journaling modes of advfs allow to configure a much better data integrity than ZFS)
It doesnt use the native widgets. It uses its own widgets and then it paints them so that they look like they were native (other browsers also do this)
I disagree that there's not that much going on - using the standard pci interfaces to access the devices, the recent input hotplug work, the new acceleration architectures in the DRM side...
Internally, X11 running in local mode works the same way as Apple's window server - using shared memory and local sockets.
It doesn't uses shared memory, I think. There's a "shared memory" extension, but there's not a "shared memory transport" for the X11 protocol. Sun's propietary server has a shared memory transport, and it was said that they'd opensource and port it for X.org, but so far nothing has happened. It'd be an interesting thing to have, i think - today, when an application wants to display a image in the server it must send the whole image to the server (the protocol is network-oriented so it can't send a "reference" like a file, it has to send the whole data of the image). If the client app keeps the image in its memory after sending it to the server, the image is using 2x its memory size (one in the server, one in the client). With a shared memory transport, client and server could shared the memory that the image is using. Or so I've heard.
Do they still sing "network transparency out of the box" mantra every time someone suggests changing architecture ?
They sing "not breaking the compatibility with all the graphical applications out there".
Guess what? It works fine here, and I bet that it also works for everyone using ff3, except you, for some reason (maybe your setup is broken?). I know because breaking gmail would be a very serious showstopper for ff3, and nobody has complained.
And not only it works, it works really well and the performance improvements in ff3 are so great that the speed different is noticeable.
If opera dev's team can't be beaten then they must have a ultrafast version hidden somewhere, because the public versions, including 9.5 betas, are already slower than firefox 3 and webkit on many benchmarks
The next time it'll be web page hosting what google and microsoft will be ofering, and dreamhost will have to say "choose their services, ours are not good enought"
Well, Linux (at least the kernel) is mainly analyzed with Sparse, a tool started by Linus himself.
A mutex/spinlock brings you "preemptability"
Duh, I meant mutex/semaphore. And Linux semaphores have become slower, meanwhile mutexes still are fast as old semaphores were, as #23446368 says. The options were to move from a semaphore to mutexes or spinlocks, but Linus chose spinlocks because the RT/low-latency crow will notice it and will try to remove the remaining BKL users.
Because these days the BKL is barely used in the kernel core, or so Linus says: the core kernel, VM and networking already don't really do BKL. And it's seldom the case that subsystems interact with other unrelated subsystems outside of the core areas. IOW, it's rare to hit BKL contention - and in those cases, you want the contention period to be as short as possible. And spinlocks are the faster locking primitive, so making the BKL a spinlock (which is not preemptable) makes the BKL contention periods faster. A mutex/spinlock brings you "preemptability" and hides a bit the fact that there's a global lock being used sometimes at the expense of performance, which may be a good thing for RT/lowlatency users, but apparently Linus prefers to choose the solution that is faster and doesn't hid the real problem.
Yeah, that must be why TrustedBSD is copying SELinux (just like opensolaris)...
People claims SELinux is difficult, but they often don't understand how insanely powerful it is....