Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×

Comment Re:Boycotting? Hardly (Score 1) 221

The link to the Richard Stallman page is not against ebooks but about Amazon ebooks, or to keep it simple about DRM, proprietary formats and all other nice features introduced to "protect" users

There is nothing wrong with open ebook formats such as EPUB (XHTML+CSS+XML) as they remain DRM free.

         

Comment Re:Image size? (Score 1) 223

Let's assume
    - an average page is 10x10 inches (25x25 cm)
    - a high scan resolution of 1200DPI
    - 32bits per pixel (4bytes)

An average uncompressed page takes 10*10*1200*1200*4 = 576000000 = 0.57 gigabytes

A lossless compression can probably reduce the size by 2 but if they are not stupid they will make multiple backups so 1.2 gigabytes per page seems reasonable to me.

Comment Re:Smart Machines (Score 1) 125

Humm... wear leveling in software ... wait until an OS misconfiguration, an OS bug or a virus ruins your SSD by writing thousand of times the same sector. I am not talking about losing your precious data which should be backuped but losing the whole disk. And don't even think about using the warranty. SSD makers are not suicidal. The first thing they would had to their product is a counter of writes per block in order to prove that the failure was not their fault.

       

Comment Re:The enemy of my enemy . . . (Score 1) 297

I don't agree! During the last years Tom Tom attitude was more and more against the OSS community so the OSS community should not help Tom Tom.

I have not tried recently but as far as I know it is virtually impossible to download and install a map on a TomTom without their Windows-only application. And please don't tell me that they have good technicals reasons since that was perfectly possible a few years ago.

I don't say that the community should be silent. It would be far more productive to use this as an opportunity to express a strong dissatisfaction against parasitic companies that take as much as possible without even giving the most basic OSS support for their products.

Comment Re:40% faster kernel, but what overall performance (Score 1) 173

That's a common misconception but malloc is not a kernel call but a user land function.

Malloc is implemented in the libc by managing a since large area of memory (the heap). When the heap is full, malloc() increases the heap size by a system call such as sbrk(). On my system (64bit), the heap is increased by blocks of 128KB.

For large data sizes (>128KB) malloc does not use the heap and directly allocates the memory using the system call mmap().

For example, for an application allocation up 100MB the overall number of calls to sbrk() is no more than 100MB/128KB = 800 regardless of the number of calls to malloc()/free() which can be millions. The kernel calls are totally negligible.

There is a nice article here: http://www.linuxjournal.com/article/6390

   

Comment Re:Not really news... (Score 3, Insightful) 348

The first problem is indeed that a desktop file does not require the executable bit to be executed (from Nautilus) by double-clicking it.

The second problem is that the file content specifies it icon, name and tooltip regardless of the filename of the desktop file.

For example, a very efficient way to fool people could be to disguise the desktop file into one of the default icons of the desktop (Trash, Computer, Home, ...)

For the virus writer the only problem is to get the desktop file to be saved in the Desktop directory.

Humm... Guess what is the default directory of most applications for saving uploaded files? I give you an hint. The name starts by a 'D'.

Even better, it is possible to specify that the Desktop is the HOME. I haven't checked recently but that I remember that this used to be the default in Ubuntu.

My advice is simple: Start gconf-editor and disable the configuration key /apps/nautilus/preferences/show_desktop to get rid of all desktop icons.

Comment Not for SSDs (Score 1) 256

Those filesystems are designed for FLASH devices like usb keys or memory cards but are probably not suitable for SSD.

The reason being that modern SSDs already perform wear leveling to improve the performances and I don't believe that apply wear leveling could be a good idea.

For the time being, it is probably better to wait for the SSD controller technology to mature.

On the OS, the existing filesystems should be tuned to exploit the lower seek times. Caching the writes so that they can be perform in large consecutive blocks probably make sense too.

Slashdot Top Deals

"Gravitation cannot be held responsible for people falling in love." -- Albert Einstein

Working...