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.
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.
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.
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.
The C++ annotations is more a tutorial than a reference but I find it very useful.
http://www.icce.rug.nl/documents/cplusplus/
And unlike more other documents of that kind, this one is regularly updated by its author (since 1994).
Actually, he is right. In most raw files, each pixels is composed of single channel and the missing two channels are interpolated from the neighbors.
So a raw file pixel is indeed 12bit.
Did you try the UFraw plugin?
It supports almost existing RAW file formats.
UFRaw will do all adjustments in 16bit (exposure, saturation, curves, ICC profiles,...)
The result will be 8bit in gimp but that is usually not a problem if the levels were correctly adjusted by ufraw in 16bit.
Slashdot Mirror
case "$filename" in ;; ;;
*.temp|*.tmp|*.junk) echo "good $filename"
*) echo "bad $filename"
esac
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 ... 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.
http://xkcd.com/538/
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 /apps/nautilus/preferences/show_desktop to get rid of all desktop icons.
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.
Don't remove the images!
Simply hide the cars under a big "CENSORED BY TOYOTA".
Emacs eat the C-J in my example, You need of course to apply one after the closing ) of defun and one at the end of the global-set-key line.
M-x lisp-interaction-mode
Allow the execution of any emacs lisp command in a buffer (no need to edit your .emacs)
The *scratch* buffer is in that mode by default.
Basically you can do the following:
(1) copy any of the e-lisp examples given in other post
(2) put the cursor after the last ')'
(3) press C-j to execute the command
For example (with indicates where you have to apply C-j):
(defun save-all ()
"sauve tout les tampons"
(interactive)
(save-some-buffers 1)
)
(global-set-key [f6] 'save-all)
and you now have the function 'save-all' bind to F6 in your emacs session.
On some systems, gnu-emacs startup can be quite long because it is waiting for the Window Manager.
The same command also set the colors, font and a few other settings that used to be controlled by the X resources.
(if (eq window-system 'x) ;; prevent slow start
(if (x-display-color-p)
(progn
(modify-frame-parameters nil '((wait-for-wm . nil)))
(set-background-color "#FFDDD0")
(set-foreground-color "black")
(set-frame-font "9x15")
(set-cursor-color "red")
(set-mouse-color "blue")
)))
This one set the default command for 'compile'
(setq compile-command "make -k")
Add my favorite commands to the 'compile' history
(setq compile-history
( list compile-command
"cd $HOME/work/project ; make -k"
"cd $HOME/work/project ; make -k build"
"cd $HOME/work/project ; make -k clean all"
"cd $HOME/work/project ; configure"
))
Save all modified files at once
(defun save-all ()
"sauve tout les tampons"
(interactive)
(save-some-buffers 1)
)
Save all modified files and relaunch the last 'compile' command
(defun save-all-and-recompile ()
"Sauve tout les fichiers et lance une compilation"
( interactive)
(save-some-buffers 1)
( recompile )
)
Some fast keyboard shortcuts for compilation
(global-set-key [f6] 'save-all)
(global-set-key [f7] 'compile)
(global-set-key [f8] 'save-all-and-recompile)
(global-set-key [f12] 'next-error)
The C++ annotations is more a tutorial than a reference but I find it very useful. http://www.icce.rug.nl/documents/cplusplus/ And unlike more other documents of that kind, this one is regularly updated by its author (since 1994).
nt
Actually, he is right. In most raw files, each pixels is composed of single channel and the missing two channels are interpolated from the neighbors. So a raw file pixel is indeed 12bit.
... the rocks are trying to leave California!
Humm! doesn't work! Your link is borken.
Did you try the UFraw plugin? It supports almost existing RAW file formats. UFRaw will do all adjustments in 16bit (exposure, saturation, curves, ICC profiles, ...)
The result will be 8bit in gimp but that is usually not a problem if the levels were correctly adjusted by ufraw in 16bit.
Ha Ha!
a phone ringed?