以美國為中心,往東邊與往西邊,有著不同的防護罩。往東邊就是北約、歐洲;往西邊就是第一、第二、第三島鏈。主要防著的就是中俄兩國。
所以,我們可以這麼的理解:第一島鏈如果有個全名,應該叫作「美國防線的第一島鏈」。
千萬不要被那個「第一」沖昏了頭,以為第一好棒棒。這個第一是萬一出事,第一個遭殃的意思。
最後,台灣是美國往西看的第一防線,而美國往東看的第一防線就是烏克蘭了。大家真的要好好思考這個問題。
我隨意寫寫,大家隨意看看
以美國為中心,往東邊與往西邊,有著不同的防護罩。往東邊就是北約、歐洲;往西邊就是第一、第二、第三島鏈。主要防著的就是中俄兩國。
所以,我們可以這麼的理解:第一島鏈如果有個全名,應該叫作「美國防線的第一島鏈」。
千萬不要被那個「第一」沖昏了頭,以為第一好棒棒。這個第一是萬一出事,第一個遭殃的意思。
最後,台灣是美國往西看的第一防線,而美國往東看的第一防線就是烏克蘭了。大家真的要好好思考這個問題。
兩段式左轉並不是政府突然想到的規定,而是在規定之前,已經有很多機慢車騎士自發性使用兩段式左轉了。
幾十年前,我騎單車在路上,想要左轉但是切不進去。看到一位大嬸把機車騎到右前方橫向車道的停止線前等綠燈,心想這真是個好方法,雖然慢一點但是很安全。之後我就開始了兩段式左轉。
兩段式左轉的機慢車日益增多,後來政府才訂了兩段式左轉的規定。所以這個規定是起於民間的大量自行實踐,再由政府明訂規定讓其合法化,而不是什麼政府自己憑空訂出來的規則。
隨著年輕人口的減少,路上的車子也比以前減少,加上性能較佳的重機的引入,漸漸的有些騎士認為不用待轉也能安全左轉。時空背景的改變,規定是可以改的,例如讓大家自行選擇,風險自負。不過在當年,這個規定的確是有其民意基礎的。
這些年來,有時候會看到綠營朋友們轉發德國之聲中文版的新聞,大概內容和中國又有什麼問題有關,你看國外媒體都這麼說等等。
有一次,我有些納悶,明明一件小事,為什麼德國之聲會報導。實際上是什麼新聞,我已經忘了。不過,我因為這個疑問,去查了一些資料:
現在,德國之聲中文版的記者幾乎全部匿名了,例如財經記者用德才,政治記者用德正,把記者的資訊藏起來了。不過大家還是可以去查查看中文新聞有沒有其它語文的版本,來更進一步的判斷。
Infrared 是紅外線,而Ultraviolet 是紫外線。為什麼都是"外",英文的字首卻不一樣?
如果以可見程度為基準點,紅外線與紫外線都是不可見,都在外面,所以中文名字這麼取。
如果就頻率來說,以0為基準點,紅外線的頻率其實是比紅色更靠近0的,所以用Infra-,有below的意思;而紫外線的頻率是比紫色更遠離0的,所以用Ultra-,有beyond的意思。
所以如果用英文意思直譯,應該叫作紅內線與紫外線。
公民投票是民主的表現,然而它還是有很大的改進空間。 大家的民主素養普遍不夠高,以為有投票就是民主了,所以會導致很多問題。
理論上,國家的運行,應該是事事民主的,不管有沒有公投。有這樣的觀念,才能有所改進。
例如英國的脫歐,這件事情的執行,代價很大而且幾乎是不可逆的。如果公投的結果是60%的人都想脫歐,那就執行吧;如果只有50.1%,那會不會過一陣子又變成49.9%? 如果就脫歐了,三個月後反轉過來,那還有遵照民意的機會,重新加入嗎?
太著重在形式,想要用一次投票決勝負,是會有這種問題的。所以,我會認為這類的事情,門檻不能只有50%。
以台灣未來的公投為例,比較好的方式,是在投票時,讓大家獨立、統一、維持現狀三選一,然後可以例如每八年固定投一次票,而不是那種只能投是否獨立或是否統一。獨立或統一,都需要設定某個門檻(例如可投票人數的50%)而非多數決,因為這兩個改變也是不可逆的,所以民意上一方需要領先到看似不會再反轉,再去執行比較保險。
允許人民有後悔的機會(例如罷免就是一種後悔的機會),考量到可能波動的民意,在重大不可逆的議題上作出符合長期民意的決策,這才是真的把民主放在心中。
在Python當中,有一些取得UTC時間的方法。這裡介紹一個不用安裝package的方法。
from datetime import datetime, timezone
# 設定時間為2025/1/1 00:00:00, 無時區資訊
dtm = datetime(2025, 1, 1)
# 根據系統設定加上時區資訊,時間為2025/1/1 00:00:00 local time
dtm_local = dtm.astimezone()
# 加上UTC時區資訊,時間為 2025/1/1 00:00:00 utc time
utc_20250101 = dtm.astimezone(timezone.utc)
# 將2025/1/1 local time轉換成utc time,按照兩地的時差
utc_from_dtm_local = dtm.astimezone().astimezone(timezone.utc)
如果是取得當下的時間,可以用以下:
utc_now = datetime.now(timezone.utc)
# 或是 datetime.now().astimezone().astimezone(timezone.utc)
可能用了Asus Webstorage 有三年多了,雖然看到它有進步,但是仍有一些問題。
我個人是滿支持國貨的。用的手機與筆電大多是Asus的,雖然品質不是每次都滿意,但是還在可接受範圍。不過在用了 Asus WebStorage 之後,我對於這個品牌的滿意度又降了一些。
一開始在使用時,看到它有自動同步功能,於是就開啟了,讓它慢慢的同步。直到有一天,要上傳下載大量資料時,才發現原來它批次上傳下載的速度超級慢。在第一次Subscription結束前,想說如果速度仍然很慢,那我就不再續訂了。在我給它最後一次機會時,發現速度變快了,於是我再續訂了兩年。
原本的自動同步功能,後來不再使用了,有點忘了是它有什麼問題。我現在使用的是將它設成網路磁碟機的功能。有一次,我將資料從WebStorage磁碟往本地磁碟搬移時,發生了搬移失敗,然後WebStorage磁碟的資料也沒了。這真不知是Windows的問題,還是Asus的問題。
這兩天因為對於自動同步的正確性與效率有疑慮,我打算自己來寫一個適合自用的同步程式。檔案修改時間會是重要的判斷依據,而且我有兩台電腦,一台是台灣時間,一台是美西時間,所以我還得研究一下當我把檔案複製到Asus WebStorage時,它的時間會是什麼。結果很是震驚與不解。先說優點,我在不同時區的電腦,會看到不同時區的時間,表示時間會按照電腦的時區作自動調整。正當我覺得可以再繼續使用時,發現了問題。兩台電腦看到的檔案修改時間,是很不一樣的。當我用程式修改檔案的修改時間到2024年1月1日,在原電腦會看到修改後的時間,在另一台電腦則看到了當天的2025年日期。
今天看到微軟有便宜的方案,六組Office 365家庭帳號 + 六組 1TB OneDrive,一年只要台幣2000出頭。如果它的時間資料正確,那我就準備要換過去了。