Comment Re:Lecture Fruit! (Score 1) 475
You forgot coconuts that can be deadly when received on the head.
There is also that well known story of a couple having huge problems after eating a single apple!
You forgot coconuts that can be deadly when received on the head.
There is also that well known story of a couple having huge problems after eating a single apple!
A huge problems with the flat log file is that it breaks the secrecy. If you know the order of the voters you can easily figure out who voted what.
A better solution could be to print or select a ballot paper and have it sent into a ballot box after visual verification by the voter.
Humm... wear leveling in software
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.
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
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
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.
Yep! Life was invented by Al Gore 1 billions years ago.
If you want to put yourself on the map, publish your own map.