【科技新聞】米哈伊爾·戈爾巴喬夫去世


米哈伊爾·戈爾巴喬夫去世
Mikhail Gorbachev has died

評論

戈爾巴喬夫通過他沒有做的事情確保了他在歷史上的地位。雖然從不支持東方集團的終結,但他從 1980 年代後期開始就明確表示,與他的前任不同,他不會以武力反對東歐的民主改革。令普遍驚訝的是,他信守了這一承諾,除了令人遺憾的立陶宛例外,這一承諾不再重蹈其前任罪行的覆轍是戈爾巴喬夫最偉大的遺產。在 1988 年,你很難找到任何人能夠想像東方集團在很大程度上是和平的崩潰,但戈爾巴喬夫有道德勇氣接受他的政策曾經難以想像的後果,並堅持到底。

安息戈爾巴喬夫,政治上為數不多的真正好人之一。

從政界退休後,他出現在幾則廣告中:

– 1994 年蘋果電腦: https://www.upi.com/Archives/1994/10/07/The-first-advertisem…

– 1998 年的必勝客: https ://en.wikipedia.org/wiki/Gorbachev_Pizza_Hut_commercial

– 2000 年 ÖBB,奧地利鐵路: https ://www.youtube.com/watch?v=bLscz8kEg6c

– 2007 年路易威登: https://www.nytimes.com/2007/11/05/business/media/05vuitton….

隨你怎麼說,他似乎是一個非常熱衷於世界和平的政治家,而不僅僅是口頭上的。他了解蘇聯體制的缺陷,並真正著手進行改革。但歸根結底,是烏克蘭、波羅的海和中亞共和國的民族利益,以及葉利欽等機會主義攫取者的崛起,使他和蘇聯加入了進來。

或許他自己也不願意效仿中國模式。他更喜歡政治改革而不是經濟改革,而中國人首先更喜歡經濟改革。

他結束了阿富汗戰爭。他比西方領導人更熱衷於核裁軍:西方領導人在這件事上拖拖拉拉,最終我們沒有在核裁軍方面取得任何進展。

他迎來了改革。觀看該時期的蘇聯電影,可以看到與冷戰時期好萊塢描繪的截然不同的畫面。


穩定擴散很重要
Stable Diffusion is a big deal

評論

在大量使用 SD 一周後,我有一半同意這一點。它具有令人難以置信的破壞性,它在多大程度上加速了創作過程。我會給你那個。

但是我注意到了兩件事:

首先,使用此工具,藝術家仍將比非藝術家擁有巨大優勢。熟悉不同鏡頭和相機以及行業術語的攝影師將比沒有經驗的人更快地表達他們的想法。如果沒有這種深度的知識,有人可能不得不依靠隨機運氣來創造他們腦海中的東西。藝術策展人在這裡可能處於有利地位,因為擁有廣泛的知識和參考點是他們的優勢。

其次,我們需要持久化設計的能力。如果我使用 SD 創建一個角色,我需要能夠在不同的場景、姿勢、情緒、照明等中保持該角色。根據我對 SD/Midjourney/Dall-E 使用的方法的了解,我不確定這將是多麼容易實現,或者是否有可能。總會有細微的差別,這就是作為一名可以使用 SD 獲得靈感而不僅僅是創作的藝術家將保持他們相對於非藝術家的優勢的地方。

也就是說,天哪。這技術太牛了

只是我,還是這個線程中的評論似乎與類似 Github Copilot 線程的評論中的情緒完全相反?

我只是覺得有點諷刺的是,程序員對 Github Copilot 使用他們受版權保護的材料進行訓練感到憤怒。但是,如果它是使用受版權保護的藝術家材料進行的 ML 模型訓練,那麼它顯然是一項變革性的工作。我只是覺得這些場景的相反情緒有點好笑。

> Stable Diffusion 已針對從網絡上抓取的數百萬受版權保護的圖像進行了訓練。

我的大腦已經接受了更多受版權保護的材料的訓練。我讀的每一本書,我看的每一個電視節目,我小時候玩的玩具。很難想像我能想出任何不受版權作品啟發的東西。


90 年代光標效果
90s Cursor Effects

評論

我會開始,哇,這很酷而且很有趣。正如另一位評論者所說,這讓人想起了 90 年代互聯網的異想天開。

嘆息,然後彗星光標來提醒我們為什麼我們不能擁有美好的事物:

https://en.wikipedia.org/wiki/Comet_Cursor

“不能有好東西”部分來自隨之而來的跟踪。 Comet Cursor 是現代網絡的先驅!

目前,時尚潮流正在反抗低調的 2010 年代,將 90 年代末 / 2000 年代初的美學以更寬的合身和更響亮的色彩形式回歸。讓我想知道我們是否/何時會在網頁設計甚至家具方面看到類似的變化。作為一個對那個時代沒有太多記憶的年輕人,我可能會有偏見,但如果它打破了 2010 年代中期企業級平面設計趨勢的單調,我完全支持一些改變(除非對可訪問性產生影響)。

光標延遲非常糟糕,尤其是在 Windows 上,但至少有兩種方法可以降低延遲:

1.使用'desynchronized',例如canvas.getContext("2d", { desynchronized: true });

2. 不使用 requestAnimationFrame(),而是在收到移動事件後立即繪製。

這是一個繪圖應用程序,它使用技術 1 和 2 來實現更低的輸入延遲,繪製追逐光標的筆劃:

https://paint.js.org/

另外兩個需要注意的技巧:

3. [僅限 Chromium。] 使用“pointerrawmove”在移動事件發生時立即獲取它們,而不是等待一大堆合併的移動在延遲後全部到達。

4. 在平滑的光標/筆運動期間,為了補償滯後而預測光標所在位置的繪圖效果很好。例如,Windows Snip & Sketch 工具實際上會在檢測到筆尖行進的方向之前呈現您正在繪製的線條,因為在物理 Surface Pro 屏幕上使用 Microsoft Surface Pen 時,所繪製的線條會明顯除非使用這種預測技巧,否則會落後於物理筆尖(尤其是在 60Hz 屏幕上)。

最後,請注意開放的 Chromium 問題 #992954。當 devtools 打開 [F12] 時,不使用合併的事件,因此您可以獲得較低的輸入延遲,但要泵送更多的事件(如“pointerrawmove”)。這個錯誤令人抓狂,因為它取決於您是否打開了調試器!

https://bugs.chromium.org/p/chromium/issues/detail?id=992954


留言討論區