Sufficiency is not necessity, so listing a few examples of unrelated potential fair uses isn't much of an argument. And nobody here is using children as a defense - the EFF is suing Universal, not the other way around. Universal is being accused of abusing the DMCA takedown process, and the defense is that one of their songs happened to appear incidentally in the background to a 29-second video of a baby acting cute.
I have to give them credit. The Firefox devs have quite a sense of humor.
I remember when they claimed that Firefox's excessive memory usage was a feature not a bug -- i.e., Firefox was caching pages. Which is really great except that it wasn't true.
I remember that. It actually was all true, and not as you describe. They never said that the memory usage was "a feature, not a bug". That would be daft. They said that the enormous memory usage of one particular version wasn't caused by a memory leak as many suspected (there were several known ones at that stage, but this wasn't one of them), but rather that it was caused by a new feature that was added to that version and removed from the next (hey, let's use all the free memory as a cache pool! when apps need more memory we'll feed it to them as needed. what could go wrong?). It was a misfeature - a bad idea that worked as it was designed to.
Triggering a separate interrupt for individual characters was the slow way of rendering text. There's the overhead of the IRQ jump itself, handling cursor movement, window wrapping, scrolling - all that is OK if done once for a batch of characters but too much work when repeated for each character. Most programs used DOS or BIOS calls to print out strings of text at a time. Those occasional programs that had need to twiddle random characters on the screen would edit segment $B800 directly. Whether using BIOS, DOS or the text buffer, you're still using text mode. And believe me - it was much faster just setting the byte for a character and letting the hardware figure it out than plotting the pixels for the text in software. That's what text mode was - hardware-accelerated graphics that increased speed and reduced memory usage at the expense of limiting you to a set of pre-defined characters always arranged in a grid. There weren't compatibility issues because the protocol (the location and format of the text buffer in segment $B800) was kept sufficiently consistent from CGA to EGA to VGA.
A market that likes to overpay is a good market to be in:) There's a question about how long that tendency will last, but it's been going strong for over 3 years so far and doesn't appear to be slowing yet. It possibly won't until games are so commonplace on that platform that users no longer feel the need to encourage growth, but at that stage you will probably no longer have your problem of a limited userbase.
You can't "turn off" UEFI - it's the firmware that provides the legacy BIOS payload. If you install Windows XP you'll be adding a pre-Secure-Boot bootloader and thus need to have Secure Boot disabled. Of course, current Windows XP systems don't have Secure Boot anyway, so it's not much of a difference having it disabled.
At 33 milliseconds, shaving off 0.5 milliseconds is useful only if you can do it 13 times, because the cumulative effect adds up to 7.5ms, which pushes your interval below the 16 2/3 ms time budget and flips your performance from "bad" to "good". There's a huge difference between meeting your budget and missing it. Lots of little differences that add up to a lot can be significant. 0.5 millisecond total difference when your budget is aleady met anyway is hardly worth mentioning.
20% is half a millisecond. That's nothing. It could easily come from something unrelated to graphics - a different allocator, scheduler, etc. You can't look at this and reasonably conclude that either graphics system is better than the other. All you can say is that neither performed considerably worse than the other in this case. Regardless of whether OpenGL is better than DirectX, they have determined that Linux+OpenGL is a feasible target platform for at least one hardware setup.
Faster, not fastest. At least as I understood it he was talking about a reason why they chose Texas over - for example - California, where Apple is based. (disclosure: I haven't RTFA'd yet, or know how often California judges in favour of patent holders)
Nope. Unfortunately, Steam doesn't have any mechanism for controlling whether or not it updates games. The setting that you describe merely exposes a flag (that frequently gets set and unset automatically) for whether the game should be updated in the background. Steam often either disregards that or silently sets it back to "Always keep this game up to date" at odd times. Also, whenever you run a game Steam tends to do an update regardless and switches the setting back to "Always keep this game up to date" for you.
His identity is Malcolm Harris, apparently. That's not the problem. It seems they want to use tweets that he made and later deleted as evidence against him, but those tweets don't exist anymore, which is why they're pressuring Twitter to provide them again.
Well, it's a population of people with a distinct geographic ancestry (France), ethnicity (French culture and language) and social status (French nationals presumably have citizenship, right?). I think that's "most ways" already covered - now, why do you think they should be disqualified? I'm not trying to be snarky - it's just that your answer hasn't clarified anything and I really would like to understand what you mean.
He's recording, not transcribing from a record, and I'm not sure if anything he wrote could honestly be considered actual "testimony". They might choose to consider writing on paper "operating a recording device" though.
Asking for feedback? You know what that means? It means that if you are Australian then you really ought to tell them what you think about this. Ideally before the end of the month to be sure that your feedback can be read before the hearings start.
Can you confirm that's actually the case? I don't know much about Wayland's technical details, but it's such a dramatic loss in flexibility that I'm inclined to suspect this being a complete misunderstanding. I can't see how code that runs on the compositing and window-management layer would be unable to add decoration unless it is restricted to an extremely limiting API (hopefully not what is happening), and even if that were so then wouldn't it be possible to have a decorator using the same reparenting technique that window managers use on X? And wouldn't it be possible to have window managers as precompiled shared objects which could be swapped during runtime?
I guess I should look into Wayland and try to answer those questions for myself. I'd hate to be unable to change window managers on the fly or have apps needing to decorate their own windows.
From the FAQ: "The Wayland architecture integrates the display server, window manager and compositor into one process."
From there it continues:
You can think of Wayland as a toolkit for creating clients and compositors. It is not a specific single compositor or window manager. If you want a different window manager, you can write a new one.
This may sound like a lot of work, but one of the key points about Wayland is that the boilerplate code to a Wayland compositor is comparable or less than the X boilerplate involved in becoming an X window manager and compositor. Bringing up EGL and GLES2 on the Linux KMS framebuffer and reading input from evdev can be done in less that a thousand lines of code. The Wayland server side library provides the protocol implementation and makes it easy to put the pieces together.
So basically you can use any window manager provided that the manager is written to support Wayland, just as you can use any window manager on X provided that it supports X.
Re:Amateur protestors vs professional lobbyists
on
Bye ACTA, Hello CETA
·
· Score: 1
Slashdot Mirror
Killer whales have no self respect? :(
Sufficiency is not necessity, so listing a few examples of unrelated potential fair uses isn't much of an argument. And nobody here is using children as a defense - the EFF is suing Universal, not the other way around. Universal is being accused of abusing the DMCA takedown process, and the defense is that one of their songs happened to appear incidentally in the background to a 29-second video of a baby acting cute.
Naturally, the trick to doing minimalism right is to use as little of it as possible.
Can you provide a citation for those numbers? TFA links here, which lists Galaxy SIII and Galaxy Nexus at 1560 and 1039 respectively.
Oh, IE certainly is a game. A strange game. The only winning move is not to play.
I once received a cheque for a million Gummiberries, but it bounced.
</badjoke>
I have to give them credit. The Firefox devs have quite a sense of humor.
I remember when they claimed that Firefox's excessive memory usage was a feature not a bug -- i.e., Firefox was caching pages. Which is really great except that it wasn't true.
I remember that. It actually was all true, and not as you describe. They never said that the memory usage was "a feature, not a bug". That would be daft. They said that the enormous memory usage of one particular version wasn't caused by a memory leak as many suspected (there were several known ones at that stage, but this wasn't one of them), but rather that it was caused by a new feature that was added to that version and removed from the next (hey, let's use all the free memory as a cache pool! when apps need more memory we'll feed it to them as needed. what could go wrong?). It was a misfeature - a bad idea that worked as it was designed to.
Triggering a separate interrupt for individual characters was the slow way of rendering text. There's the overhead of the IRQ jump itself, handling cursor movement, window wrapping, scrolling - all that is OK if done once for a batch of characters but too much work when repeated for each character. Most programs used DOS or BIOS calls to print out strings of text at a time. Those occasional programs that had need to twiddle random characters on the screen would edit segment $B800 directly. Whether using BIOS, DOS or the text buffer, you're still using text mode. And believe me - it was much faster just setting the byte for a character and letting the hardware figure it out than plotting the pixels for the text in software. That's what text mode was - hardware-accelerated graphics that increased speed and reduced memory usage at the expense of limiting you to a set of pre-defined characters always arranged in a grid. There weren't compatibility issues because the protocol (the location and format of the text buffer in segment $B800) was kept sufficiently consistent from CGA to EGA to VGA.
"Copyright 2004–2006 TextDrive Inc. TextDrive is a trademark of Joyent Inc."
It looks to me like the agreement was with Joyent the whole time. At the very least they were a party to the agreement. Joyent still exists.
A market that likes to overpay is a good market to be in :) There's a question about how long that tendency will last, but it's been going strong for over 3 years so far and doesn't appear to be slowing yet. It possibly won't until games are so commonplace on that platform that users no longer feel the need to encourage growth, but at that stage you will probably no longer have your problem of a limited userbase.
You can't "turn off" UEFI - it's the firmware that provides the legacy BIOS payload. If you install Windows XP you'll be adding a pre-Secure-Boot bootloader and thus need to have Secure Boot disabled. Of course, current Windows XP systems don't have Secure Boot anyway, so it's not much of a difference having it disabled.
At 33 milliseconds, shaving off 0.5 milliseconds is useful only if you can do it 13 times, because the cumulative effect adds up to 7.5ms, which pushes your interval below the 16 2/3 ms time budget and flips your performance from "bad" to "good". There's a huge difference between meeting your budget and missing it. Lots of little differences that add up to a lot can be significant. 0.5 millisecond total difference when your budget is aleady met anyway is hardly worth mentioning.
20% is half a millisecond. That's nothing. It could easily come from something unrelated to graphics - a different allocator, scheduler, etc. You can't look at this and reasonably conclude that either graphics system is better than the other. All you can say is that neither performed considerably worse than the other in this case. Regardless of whether OpenGL is better than DirectX, they have determined that Linux+OpenGL is a feasible target platform for at least one hardware setup.
Faster, not fastest. At least as I understood it he was talking about a reason why they chose Texas over - for example - California, where Apple is based. (disclosure: I haven't RTFA'd yet, or know how often California judges in favour of patent holders)
Nope. Unfortunately, Steam doesn't have any mechanism for controlling whether or not it updates games. The setting that you describe merely exposes a flag (that frequently gets set and unset automatically) for whether the game should be updated in the background. Steam often either disregards that or silently sets it back to "Always keep this game up to date" at odd times. Also, whenever you run a game Steam tends to do an update regardless and switches the setting back to "Always keep this game up to date" for you.
His identity is Malcolm Harris, apparently. That's not the problem. It seems they want to use tweets that he made and later deleted as evidence against him, but those tweets don't exist anymore, which is why they're pressuring Twitter to provide them again.
I was wondering the same thing. Those are the only consoles I've ever bought.
Well, it's a population of people with a distinct geographic ancestry (France), ethnicity (French culture and language) and social status (French nationals presumably have citizenship, right?). I think that's "most ways" already covered - now, why do you think they should be disqualified? I'm not trying to be snarky - it's just that your answer hasn't clarified anything and I really would like to understand what you mean.
In what way isn't 'French' a race?
He's recording, not transcribing from a record, and I'm not sure if anything he wrote could honestly be considered actual "testimony". They might choose to consider writing on paper "operating a recording device" though.
Asking for feedback? You know what that means? It means that if you are Australian then you really ought to tell them what you think about this. Ideally before the end of the month to be sure that your feedback can be read before the hearings start.
Can you confirm that's actually the case? I don't know much about Wayland's technical details, but it's such a dramatic loss in flexibility that I'm inclined to suspect this being a complete misunderstanding. I can't see how code that runs on the compositing and window-management layer would be unable to add decoration unless it is restricted to an extremely limiting API (hopefully not what is happening), and even if that were so then wouldn't it be possible to have a decorator using the same reparenting technique that window managers use on X? And wouldn't it be possible to have window managers as precompiled shared objects which could be swapped during runtime?
I guess I should look into Wayland and try to answer those questions for myself. I'd hate to be unable to change window managers on the fly or have apps needing to decorate their own windows.
From the FAQ: "The Wayland architecture integrates the display server, window manager and compositor into one process."
From there it continues:
You can think of Wayland as a toolkit for creating clients and compositors. It is not a specific single compositor or window manager. If you want a different window manager, you can write a new one.
This may sound like a lot of work, but one of the key points about Wayland is that the boilerplate code to a Wayland compositor is comparable or less than the X boilerplate involved in becoming an X window manager and compositor. Bringing up EGL and GLES2 on the Linux KMS framebuffer and reading input from evdev can be done in less that a thousand lines of code. The Wayland server side library provides the protocol implementation and makes it easy to put the pieces together.
So basically you can use any window manager provided that the manager is written to support Wayland, just as you can use any window manager on X provided that it supports X.
You can't push a bill if you're dead.
If you can push a daisy, you can push a bill!
...and where a competent person would not install a fleshlight app that asks for...
Freudian slip?