i've been using ClipX on windows for quite some time, but it seems the latest version (which haven't been updated for quite some time) has some bugs, or perhaps it's windows 7 with something installed or used at the moment.
from time to time it did not catch all the "ctrl + c" events from text editors, so a couple of months ago i've moved to Ditto, which has much more features, yet at the same time can remain quite simple when in action. it can store a very large number of entries in a database that can be cleared any time and is still quite responsive when retrieving something (perhaps slightly slower that ClipX).
on the linux side of things, the only one i've tried is parcellite, which apparently to a majority of users is the best one out there.
perhaps future OS's will have native implementations of clipboard (history) managers pre-bundled.
--
Showing posts with label linux. Show all posts
Showing posts with label linux. Show all posts
Thursday, December 13, 2012
Sunday, October 23, 2011
#articles on object-oriented design in c
here are, a couple of articles by Neil Brown (from june this year @ lwn.net), that explain some of the methods used in the linux kernel to provide virtual function tables and data inheritance in c.
Object-oriented design patterns in the kernel, part 1
Object-oriented design patterns in the kernel, part 2
--
Object-oriented design patterns in the kernel, part 1
Object-oriented design patterns in the kernel, part 2
--
Sunday, September 18, 2011
#newer adobe air no longer supports linux
adobe air 2.7 was released around june this year and while it improves speed for android and ios, there are no runtimes for linux desktops. the last ones are version 2.6.
here is the main reason:
Adobe attributes this to the fact that a relatively few 0.5% of downloads of Adobe AIR were for Linux. This makes Adobe AIR 2.6 the last version of AIR to be available for Linux.
from a more detailed post on the subject.
the decision itself may be a bit questionable, but i wonder how much of a time investment would it be to update / maintain the linux runtimes (and sdk).
cross platform developers that target some of those 0.5% will now have to consider using the 2.6 sdk.
--
here is the main reason:
from a more detailed post on the subject.
the decision itself may be a bit questionable, but i wonder how much of a time investment would it be to update / maintain the linux runtimes (and sdk).
cross platform developers that target some of those 0.5% will now have to consider using the 2.6 sdk.
--
Friday, July 8, 2011
#20 years of linux
as you may know, linux will soon have its 20th birthday (1991 - 2011). apparently its celebrated on august 25. here is an hour long video filmed at linuxcon japan of gregkh and linus discussing the version history so far, the recent "jump" to version 3.0 and some of the future plans for the kernel.
http://www.youtube.com/watch?v=__fALdvvcM0
edit:
also in another video (44:18), andrew morton (akpm) gives an excellent answer to the question "what will happen to linux in another 20 years?" and i would like to quote a part of it:
"...could be at one day, a completely new technology comes along, some little quantum based computer with a million quad cores, which comes along and completely makes linux obsolete. i suspect the first thing such a computer will do is emulate x86 and we will just keep going. [laughs]"
--
http://www.youtube.com/watch?v=__fALdvvcM0
edit:
also in another video (44:18), andrew morton (akpm) gives an excellent answer to the question "what will happen to linux in another 20 years?" and i would like to quote a part of it:
"...could be at one day, a completely new technology comes along, some little quantum based computer with a million quad cores, which comes along and completely makes linux obsolete. i suspect the first thing such a computer will do is emulate x86 and we will just keep going. [laughs]"
--
Sunday, January 2, 2011
#android dropped from /staging in december 2010.
(following this post by G.K.-H.)
i guess i'm a bit too late, but it seems the android drivers were dropped from the linux kernel staging tree due to lack of maintenance, which basically means that google no longer has the chance (for now at least) to go upstream with android and keep it up to date with the latest kernel.
this pretty much leaves them maintaining a kernel snapshot which is becoming more and more incompatible with the official linux tree.
i think that this might be a company decision to not spare the resource for the integration or perhaps hope that someone will magically do the work for them without even understanding the driver specifications, security models and etc.
one other thing is that there has been public criticism that google (apart from andrew morton) does not contribute much to the kernel (and same goes for canonical).
the above post by G.K.-H. explains some of their reasons but i think that the longer they wait with the android code the more difficult it would be to be merged, considering what they are constantly adding to the os.
i must admit i haven't even seen an android phone (not much "smart phones" where i live), but i'm fairly interested in the android platform specification wise. here are my impressions:
- linux kernel based os
nicely done. as mentioned above, unless they keep upstream they are going for the route of tv manufacturers, gaming consoles and embedded systems in general - taking snapshots of kernel.org and modding it and maintaing for years, which will eventually leave them behind as they will have to spend more resource to keep up with newer hardware (and in relevance cannot compete with the kernel.org development cycle).
- c++ libs?
not sure exactly what is included but looks like according to the Android NDK the c++ support is "minimal".
- java api for gui in userspace
this is great for a modern machine, as java is very easy to write on and will allow a lot of freedom for developers. not so good for older chips as the JVM is quite slow to be frank (like the flash AVM), it is however possible to use the Android NDK to compile native code. on the other hand the ram usage of the JVM is sometimes out of proportion...considering that the average hardware configuration might have 256 mb a slightly more complicated interface will probably take like 80% of the ram...and i'm not sure how well would a modern interface run with the JVM on a 800hz cpu.
- it has a cool logo
i guess i'm a bit too late, but it seems the android drivers were dropped from the linux kernel staging tree due to lack of maintenance, which basically means that google no longer has the chance (for now at least) to go upstream with android and keep it up to date with the latest kernel.
this pretty much leaves them maintaining a kernel snapshot which is becoming more and more incompatible with the official linux tree.
i think that this might be a company decision to not spare the resource for the integration or perhaps hope that someone will magically do the work for them without even understanding the driver specifications, security models and etc.
one other thing is that there has been public criticism that google (apart from andrew morton) does not contribute much to the kernel (and same goes for canonical).
the above post by G.K.-H. explains some of their reasons but i think that the longer they wait with the android code the more difficult it would be to be merged, considering what they are constantly adding to the os.
some notes on android
i must admit i haven't even seen an android phone (not much "smart phones" where i live), but i'm fairly interested in the android platform specification wise. here are my impressions:
- linux kernel based os
nicely done. as mentioned above, unless they keep upstream they are going for the route of tv manufacturers, gaming consoles and embedded systems in general - taking snapshots of kernel.org and modding it and maintaing for years, which will eventually leave them behind as they will have to spend more resource to keep up with newer hardware (and in relevance cannot compete with the kernel.org development cycle).
- c++ libs?
not sure exactly what is included but looks like according to the Android NDK the c++ support is "minimal".
- java api for gui in userspace
this is great for a modern machine, as java is very easy to write on and will allow a lot of freedom for developers. not so good for older chips as the JVM is quite slow to be frank (like the flash AVM), it is however possible to use the Android NDK to compile native code. on the other hand the ram usage of the JVM is sometimes out of proportion...considering that the average hardware configuration might have 256 mb a slightly more complicated interface will probably take like 80% of the ram...and i'm not sure how well would a modern interface run with the JVM on a 800hz cpu.
- it has a cool logo
Subscribe to:
Posts (Atom)
