Skip to main content

Google Desktop

以前我最喜欢的桌面日历是Active Desktop Calendar，它能清晰的显示出最近几天的待办事项和Tasks（任务列表）。
不过现在考虑到经常会在几个电脑上转移，需要把数据存在网上，所以选用了Google Calendar，用着还可以，只是没有Tasks，另外每次还得主动打开浏览器去连接，所以还是稍显麻烦。
最后想到了Google Desktop，因为听说了Calendar可以集成进去，果真如此。初次之外，我发现Google Desktop改版后的一个亮点就是可扩展性。拥有众多的插件。我把尝试过的几个列在下面

日历：需要从英文插件里选，没有中文的，不过好像Create new event都把时间建到当前日期了。是bug么

时钟：挺好的，就是希望能再大些

Email：不会用，从来没显示出邮件过。后来就删掉了

Google Talk：本以为是单独的插件，想把原来的Google Talk删掉的，没想到它是外部调用了Google Talk，我晕。。于是也删了

任务列表：扩充了Calendar的功能，这下我就可以抛弃Active Desktop Calendar了

便笺簿：还没真正用上，但是感觉还不错。

网摘: 本想把Google Reader集成的,后来发现不怎么行(不仅仅是显示条目,而是把已读与未读的状态也与Google Reader同步)

还有很多有趣的Gadget,另外还可以自己开发,不错.

另外，其实我挺讨厌Google Desktop的索引的，于是把它和搜索功能都禁了。但是既然这个功能
可以禁掉，就说明这个软件还不错。

我好像成Google fans了

感兴趣的试试吧

PS:似乎只有Windows版,没有Linux的 :(
Labels:

Comments

Post a Comment

Popular posts from this blog

A Rocky Migration: Moving from docker-compose to Podman and gVisor

I've been running a few containers for several years. They were all running under rootless Docker with a single user. Initially, I planned to  migrate the containers to VMs , but I couldn't get a stable workflow after about two months of effort. Later,  gVisor caught my attention , and I decided to migrate to Podman with gVisor instead. The new plan is to run each container with  --userns=auto  and use Quadlet for systemd integration. This approach provides better isolation and makes writing firewall rules easier. I'm now close to migrating all my containers. Here are a couple of rough edges I'd like to share. Network Layout I compared  various networking options  and spent a few hours trying the one-interface-per-group approach before giving up. I settled on a single macvlan network and decided to use static IP addresses for my containers. To prevent a randomly assigned IP address from conflicting with a predefined one, I allocated a large IP range for my ...
Post a Comment
Read More »

Exploring Immutable Distros and Declarative Management

My current server setup, based on Debian Stable and Docker, has served me reliably for years. It's stable, familiar, and gets the job done. However, an intriguing article I revisited recently about Fedora CoreOS, rpm-ostree, and OSTree native containers sparked my curiosity and sent me down a rabbit hole exploring alternative approaches to system management. Could there be a better way? Core Goals & Requirements Before diving into new technologies, I wanted to define what "better" means for my use case: The base operating system must update automatically and reliably. Hosted services (applications) should be updatable either automatically or manually, depending on the service. Configuration and data files need to be easy to modify, and crucially, automatically tracked and backed up. Current Setup: Debian Stable + Docker My current infrastructure consists of several servers, all running Debian Stable. System Updates are andled automatically via unattended-upgrades. Se...
Post a Comment
Read More »

mkosi: First Impressions

I stumbled upon the Gentoo wiki page for systemd-nspawn , which in turn led me to nspawn.org , mkosi , and later systemd-sysupdate . mkosi quickly caught my eye because it's almost exactly what I wanted to build myself, as mentioned in a previous post . So, I decided to spend my "sysadmin fun quota" on it. Overview mkosi is similar to docker build or podman build , but it's designed for creating full OS images. It focuses on development and testing. For example, much like nix-shell , mkosi can quickly launch a sandboxed shell with a specific distribution and selected packages installed. The systemd project itself uses mkosi for testing across different distros. The re-introduction article  is a great read. Speed Note that this is by no means a rigid benchmark. My setup is an SSD with LUKS and an ext4 filesystem (without reflink support). Building Container Images mkosi is pretty fast. A simple mkosi command creates a fresh Debian image. I used the --incrementa...
Post a Comment
Read More »