Tomcat and OpenCMS, to be specific. And I don't use any of them.
This might be interesting news to me if they found problems with: Apache 2, PHP 5, Wordpress, Gallery 2, or Python 2.5, which is basically what my site runs on.
And yes, I know there's security problems with PHP and Wordpress. I'm just pointing out that they aren't targeting more popular software; wonder why?
The framebuffer is typically memory-mapped. While it's possible to program a video card just through indirect DMA and the GPU's command processor, most systems need to map the framebuffer for part of startup, and generally there's no reason to unmap it.
By the time they ship, we might have released working 3D drivers for these, through xf86-video-ati and xf86-video-radeonhd. Can't guarantee anything, though, since we don't even have the documentation, but I do know that there's been some NDA work going on already.
We can test this scientifically. What happens when the Juggernaut (can't be stopped) charges into the Blob (can't be moved)?
I always assumed that the Blob would catch the Juggernaut, and slide backwards, slowly slowing the Juggernaut to a stop. The Juggernaut moves the Blob, and the Blob stops the Juggernaut.
I joined the X.org project for the sole purpose of getting 3D working with my Radeon X1700 in my laptop, since fglrx is a piece of shit and AMD recently released documentation to the public.
We all have itches to scratch; if you're capable or writing C, then log on, lurk for a bit, read patches, start hacking. It's not that hard once you actually dive in.
Most groups that release the higher-quality H.264 + SSA in Matroska containers follow a pattern of hardsubbing the OP and ED, and softsubbing the rest of the ep. Allows for very fast subbing, while still putting an original touch on the video.
But there are endless ways to encrypt and shift network data to appear innocuous. There are lines ISPs won't cross; blocking VPN, SSH, TLS, HTTPS is out of the question, and after the initial handshakes, they can't see what's being transferred.
Although it's true that we have been forced to use x86 for quite a while, and as a result have gotten quite good at using it, that doesn't mean that it is an optimal instruction set. amd64 is an ugly hack, as is PAE, and although they do work, they don't change the fact that x86 was never intended to handle 64-bit spaces.
Consider the various POWER arches, and the ridiculously powerful ARM arch. ARM, for example, has an SIMD extension called Neon, which makes audio decoding possible at something like 15 MHz. These are very cool and potentially powerful architectures that have never been fully explored due to Microsoft's monopoly in the nineties.
(To be fair, Microsoft couldn't have forced adoption of another arch even if they wanted to; they homogenized the market way too far.)
Everybody else is focusing on the license, but ZFS also violates the virtual filesystem layers in Linux, which is Andrew Morton's original complaint about it and the principal reason that nobody has ported it.
Sorry. The version of ping was old; the overflow program had to be compiled on another box, since there's no toolchain on the kiosk. The overflow program exploited a vulnerability in the already-installed suid ping, not a custom ping.
OSU (Oregon State University, a bastion of open source) has Ubuntu terminals. Now, I'm pretty good at what I do, and that used to include breaking Windows for fun, so I tried to break their terminals. My goal: root.
Not easy. First, they use Idesk for their desktop (on Windowmaker), so all you can open is Firefox. I used the local browser code execution trick to get a shell, and took the home directory back for myself, but had no root. I eventually had to look up an old, old, old overflow in ping, compile it on another box (since there's no local compiler), and copy it to the terminal, and then I had a root shell. Total time: 5 hours. That's roughly 60 times what it took for me to break an XP kiosk.
The moral is either "don't admit to fucking with kiosks online," or "Ubuntu is, despite its friendliness, surprisingly more secure than Windows."
You're assuming that every page of that RAM is dirty, which is probably not a safe assumption. (Well, I mean, it's safe, but it's not realistic.) Also a modern enterprise UPS can give you twenty minutes, easily. If we assume that only two thirds (66%) of the pages are dirty, then our rate comes down to ten times your estimated max throughput of 60MB/s, which is 600MB/s and could be matched by a RAID array. Suitable for the home, no, but definitely possible in an enterprise scenario. (Also my numbers are very conservative; I'm sure that many businesses have much more powerful backup power supplies.)
Perhaps when the UPS is active, fsync() and friends work as intended, forcing certain dirty blocks (like that one containing your resume or database driver or porn or whatever the hell you have at work) to disk ahead of not-so-important blocks. Also don't forget that ramback is constantly flushing to disk, it's just not doing it at a very fast pace.
It's the x86 ABI, so it has nothing to do with the lineage of the code and everything to do with the architecture. (Unless you're going to tell me that BSD has its own double secret x86 ABI!)
Slashdot Mirror
Tomcat and OpenCMS, to be specific. And I don't use any of them.
This might be interesting news to me if they found problems with: Apache 2, PHP 5, Wordpress, Gallery 2, or Python 2.5, which is basically what my site runs on.
And yes, I know there's security problems with PHP and Wordpress. I'm just pointing out that they aren't targeting more popular software; wonder why?
I suppose that it irritates you when British authors reproduce cockney or Scottish accents in their writing, too?
- Implement CUDA in Gallium, so all Gallium-capable HW can run CUDA
Upgrade your CPU.
The framebuffer is typically memory-mapped. While it's possible to program a video card just through indirect DMA and the GPU's command processor, most systems need to map the framebuffer for part of startup, and generally there's no reason to unmap it.
By the time they ship, we might have released working 3D drivers for these, through xf86-video-ati and xf86-video-radeonhd. Can't guarantee anything, though, since we don't even have the documentation, but I do know that there's been some NDA work going on already.
And yes, I AM a Mesa dev. :3
We can test this scientifically. What happens when the Juggernaut (can't be stopped) charges into the Blob (can't be moved)?
I always assumed that the Blob would catch the Juggernaut, and slide backwards, slowly slowing the Juggernaut to a stop. The Juggernaut moves the Blob, and the Blob stops the Juggernaut.
Too vague. I could use that to describe my Mesa Radeon driver!
Corbin Simpson here, reporting in.
Oh, wait, you said "paid full-time," not "unpaid student fixing bugs that affect him directly, in his spare time."
Sorry. Didn't see that.
I joined the X.org project for the sole purpose of getting 3D working with my Radeon X1700 in my laptop, since fglrx is a piece of shit and AMD recently released documentation to the public.
We all have itches to scratch; if you're capable or writing C, then log on, lurk for a bit, read patches, start hacking. It's not that hard once you actually dive in.
Most groups that release the higher-quality H.264 + SSA in Matroska containers follow a pattern of hardsubbing the OP and ED, and softsubbing the rest of the ep. Allows for very fast subbing, while still putting an original touch on the video.
The zinc required to make a penny costs about 2~3 cents by itself.
But there are endless ways to encrypt and shift network data to appear innocuous. There are lines ISPs won't cross; blocking VPN, SSH, TLS, HTTPS is out of the question, and after the initial handshakes, they can't see what's being transferred.
Although it's true that we have been forced to use x86 for quite a while, and as a result have gotten quite good at using it, that doesn't mean that it is an optimal instruction set. amd64 is an ugly hack, as is PAE, and although they do work, they don't change the fact that x86 was never intended to handle 64-bit spaces.
Consider the various POWER arches, and the ridiculously powerful ARM arch. ARM, for example, has an SIMD extension called Neon, which makes audio decoding possible at something like 15 MHz. These are very cool and potentially powerful architectures that have never been fully explored due to Microsoft's monopoly in the nineties.
(To be fair, Microsoft couldn't have forced adoption of another arch even if they wanted to; they homogenized the market way too far.)
Everybody else is focusing on the license, but ZFS also violates the virtual filesystem layers in Linux, which is Andrew Morton's original complaint about it and the principal reason that nobody has ported it.
... Satin himself... Satin? Oh, right, the guy who tempted Jesse for Fort 'n' Daze in the Dessert.*starts slow clap*
Sorry. The version of ping was old; the overflow program had to be compiled on another box, since there's no toolchain on the kiosk. The overflow program exploited a vulnerability in the already-installed suid ping, not a custom ping.
OSU (Oregon State University, a bastion of open source) has Ubuntu terminals. Now, I'm pretty good at what I do, and that used to include breaking Windows for fun, so I tried to break their terminals. My goal: root.
Not easy. First, they use Idesk for their desktop (on Windowmaker), so all you can open is Firefox. I used the local browser code execution trick to get a shell, and took the home directory back for myself, but had no root. I eventually had to look up an old, old, old overflow in ping, compile it on another box (since there's no local compiler), and copy it to the terminal, and then I had a root shell. Total time: 5 hours. That's roughly 60 times what it took for me to break an XP kiosk.
The moral is either "don't admit to fucking with kiosks online," or "Ubuntu is, despite its friendliness, surprisingly more secure than Windows."
I would say that he's True Neutral; after all, puppets don't really have an alignment.
But for those of us with gigs upon gigs of Vorbis, Rockbox is very, very, very useful.
You're assuming that every page of that RAM is dirty, which is probably not a safe assumption. (Well, I mean, it's safe, but it's not realistic.) Also a modern enterprise UPS can give you twenty minutes, easily. If we assume that only two thirds (66%) of the pages are dirty, then our rate comes down to ten times your estimated max throughput of 60MB/s, which is 600MB/s and could be matched by a RAID array. Suitable for the home, no, but definitely possible in an enterprise scenario. (Also my numbers are very conservative; I'm sure that many businesses have much more powerful backup power supplies.)
This code prefers to flush as little as possible; sync() doesn't do anything. That's the "new."
Perhaps when the UPS is active, fsync() and friends work as intended, forcing certain dirty blocks (like that one containing your resume or database driver or porn or whatever the hell you have at work) to disk ahead of not-so-important blocks. Also don't forget that ramback is constantly flushing to disk, it's just not doing it at a very fast pace.
It's the x86 ABI, so it has nothing to do with the lineage of the code and everything to do with the architecture. (Unless you're going to tell me that BSD has its own double secret x86 ABI!)