An anonymous reader writes: A fierce argument has begun over whether children are actually "reading" new eBooks or simply "watching" them. As publishers pump increasing levels of interactivity into eBooks, the New York Times and others argue that these highly-interactive, popular titles are ruining the purpose of reading. The NYT also worries that new eBook titles could distract kids from the tougher task of actually concentrating on literature: "what will become of the readers we've been: quiet, thoughtful, patient, abstracted, in a world where interactive can be too tempting to ignore?". Others, like Gizmodo, defend these new eBooks, pointing at titles like Alice for the iPad, of which they blabber, "For the first time in my life, I'm blown away by an interactive book design." But, the NYT counters: "what I really love [about traditional books] is their inertness. No matter how I shake Alice's Adventures in Wonderland, mushrooms don't tumble out of the upper margin, unlike the Alice for the iPad.". Alice, a physics-enabled version of Alice in Wonderland is more like a hallucination than a book, but is, much to the horror of traditionalists, the top selling kid's eBook title. So, which is it? Are children's eBooks improving reading standards, or turning the joy of reading into a "watching" experience?

Posted
by
timothyon Friday May 07, 2010 @07:30PM
from the aftershocks-even-worse dept.

An anonymous reader writes "Is vibration killing disk performance? ZDnet reports on research that a carbon fiber anti-vibration rack increased random read performance by 56% to 246% and random write [performance] by 34% to 88%. Vibration is a known disk problem, but this is one of the few attempts to quantify its impact — which looks to be much greater than suspected."

Posted
by
timothyon Friday May 07, 2010 @08:12AM
from the wrong-venue-let's-say dept.

Larry Sanger writes "Jimmy Wales recently took a bold position against pornography on Wikimedia Commons: 'Wikimedia Commons admins who wish to remove from the project all images that are of little or no educational value but which appeal solely to prurient interests have my full support.' Wales also restarted the "Commons:Sexual content" policy page. His basic complaint is that Wikimedia Commons hosts too much unnecessary porn, and he wants to get rid of it. He underscored his seriousness this way, stating that we can expect 'a strong statement' from the WMF soon: 'If the Wikimedia Foundation wants to declare that it is OK for Commons to be a porn host, they can do that, and I'll not be able to continue. That isn't going to happen, though, and in fact you should expect a strong statement from the Board and/or Sue in the next few days.'" (More, below.)

qvatch writes: "The CRTC has approved Bell Canada's request to bill internet customers, both retail and wholesale, based on how much they download each month.The plan, known as usage-based billing, will apply to people who buy their internet connection from Bell, or from smaller service providers that rent lines from the company, such as Teksavvy or Acanac.Customers using the fastest connections of five-megabits per second, for example, will have a monthly allotment of 60 gigabytes, beyond which Bell will charge $1.12 per GB to a maximum of $22.50.If a customer uses more than 300 GB a month, Bell will also be able to implement an additional charge of 75 cents per gigabyte."

An anonymous reader writes: Addresses written in Arabic were live on the internet today, making history as the first online domains in non-Latin characters."For the first time in the history of the internet, non-Latin characters are being used for top-level domains," the Internet Corporation for Assigned Names and Numbers (ICANN) said."Arabic has now become the first non-Latin script to be used as an internet domain name." "Expect more as we continue to process other applications." Languages with native domain script names in the final stages of the approval process include Chinese, Sinhalese, Tamil, and Thai, according to ICANN.Link to Original Source

tux writes: Ubuntu's commercial sponsor Canonical has tried to clarify how — if not why — it has licensed a closed-source and patented codec for video on PCs running its Linux.

Canonical is the first Linux shop to have agreed to license the codec in question, H.264 from MPEG LA. Even though Red Hat and Novell are also available for use on PCs, they have not licensed H.264.Link to Original Source

"Deleted" articles don't get deleted from the Wikipedia database at all. They just get hidden from the public. An administrator can undelete them at any time. So, there's no monetary saving involved. Arguably, plain spam should be removed from the site, but JWASM is obviously not that. It is even discussed in Fog Agner's book, which normally meets the requirements for a Wikipedia article. See my post above. I can't be bothered to read the insanely long deletion discussion to see why that's not enough for them. What's more funny is that they now argue that having a Slashdot story doesn't matter because popularity is not the same as "notability". Go figure.

In the past, I preferred NASM for x86 cross platform development, meaning Win32 and Linux. It had decent support for the latest sets of instructions. The Microsoft syntax is something I prefer to avoid, so NASM was actually a plus in that respect, although some coworkers disagreed. There's a brief, but up-to-date comparison of x86 assemblers in Fog Agner's book. He says that YASM is better than NASM these days, and uses the same syntax. The Wikipedia page on Open Watcom Assembler also has book reference that seemingly compares MASM vs. NASM vs. TASM vs. WASM, but it's from 2005.

Posted
by
ScuttleMonkeyon Friday January 29, 2010 @03:57PM
from the need-more-assembler-nerds dept.

Odoital writes "January 2010 is an exciting month for x86 assembly language developers. Software developer Andreas Grech, better known to the x86 assembly language community and the rest of the world by his handle "japheth," has released another version of JWASM — a steadily growing fork of the Open Watcom (WASM) assembler. The main benefit of JWASM, arguably, is the nearly full support of Microsoft's Macro Assembler (MASM) syntax. As those in the assembly language community may already know, Microsoft's desire to continually support the development of MASM has been dwindling over the years — if only measurable by a decreasing lack of interest, updates and bug fixes — and thus the future of MASM remains uncertain. While Intel-style syntax x86 assemblers such as NASM have been around for a while, JWASM opens up a new possibility to those familiar with MASM-style syntax to develop in the domains (i.e. other than Windows) in which assemblers such as NASM currently thrive. JWASM is a welcomed tool that supplements the entire x86 assembly language community and will hopefully, in time, generate new low-level interests and solutions."

Trailrunner7 writes: Google is starting a new program that will pay security researchers a $500 bounty for every security bug they find in Chromium, the open-source codebase behind the Google Chrome browser, as well as for bugs found in Chrome itself. The company said Thursday that the plan is both meant as a reward for researchers who have been contributing bugs to the project already, and as a way to encourage other researchers to find security flaws in Chromium. Google said it will pay a base bounty of $500 for most bugs contributed, but may raise the payment to $1337 for bugs that are "particularly severe or particularly clever." The program is modeled after one started some time ago by Mozilla, which also pays $500 bounties. Other organizations have been buying vulnerabilities privately for several years now, most notably the Zero Day Initiative from Tipping Point, and VeriSign's iDefense Labs unit. Those companies pay far more than $500 for vulnerabilities, and researchers say that private organizations, such as government agencies, routinely pay tens of thousands of dollars for critical remotely exploitable bugs in popular software.Link to Original Source

Odoital writes: January 2010 is an exciting month for x86 assembly language developers. Software developer Andreas Grech, better known to the x86 assembly language community and the rest of the world by his handle "japheth," has released another version of JWASM — a steadily growing fork of the Open Watcom (WASM) assembler.

JWASM is a 16/32/64-bit x86 macro assembler that is written in portable C and can build/run on multiple platforms such as Windows, Linux, FreeBSD and DOS. JWASM also supports assembling to popular object formats such as 32/64-bit ELF, 32/64-bit MS COFF, Intel OMF, BIN (flat binary) and even DOS MZ files. The current version at the time of writing this article, JWASM 2.02, can also compile under Mac OS 10.6 using the latest version of XCode, after a bit of error placating with GCC and LD that is.

Since JWASM doesn't currently support Mach-O object output, I went an alternate route and decided to assemble a variation of the "FreeBSD 32 Hello world" example, found on the author's site, to ELF and use Agner Fog's OBJCONV utility to convert the ELF object to Macho-O for linking with LD. As a result, while running JWASM on Mac OS X, it failed to produce valid ELF object files, something the compiled Windows counterpart did with flying colors, indicating that there is some work ahead in providing JWASM as a more mature, consistent and reliable cross-platform assembler.

Despite the current limitations in Mac OS X support, JWASM still packs a punch. The main benefit of JWASM, arguably, is the nearly full support of Microsoft's Macro Assembler (MASM) syntax. As those in the assembly language community may already know, Microsoft's desire to continually support the development of MASM has been dwindling over the years — if only measurable by a decreasing lack of interest, updates and bug fixes — and thus the future of MASM remains uncertain.

Furthermore, JWASM does not have the "non open-source" and "Windows-centric" development restrictions that the MASM license entails. JWASM allows for unrestricted MASM-style operating system and embedded development, as well as development on/for other platforms, e.g. Linux. With all of that in mind, and as it matures, the choice of utilizing JWASM for software development, within toolchains, etc... is becoming more of a serious consideration for software developers.

While Intel-style syntax x86 assemblers such as NASM have been around for a while, JWASM opens up a new possibility to those familiar with MASM-style syntax to develop in the domains (i.e. other than Windows) in which assemblers such as NASM currently thrive. JWASM is a welcomed tool that supplements the entire x86 assembly language community and will hopefully, in time, generate new low-level interests and solutions.