《陽光普照》:阿豪賺人熱淚的「歸返」是電影對其自身的背叛

《陽光普照》:阿豪賺人熱淚的「歸返」是電影對其自身的背叛
Photo Credit: 甲上娛樂

我們想讓你知道的是

如果要我假設鍾孟宏所碰到的問題的話,我會說他似乎是錯誤地將自己的框架(framing)理解為現實的極限,或者是我們太過習於給予一種太過簡單的議題臉譜化正當性,以至於將高材生一而再再而三跳樓的社會現實空虛化為阿豪的中空形象被理解為唯一可能的取徑。

必須要請讀者注意的是,儘管您能不同意,我認為作品通常會有它自己的生命,它通常會溢出導演和創作者之外,透過元素間的有機互動,成為它自己的東西,這是我這篇文章的基本前提。

(內文有雷,可先收藏文章觀影後閱讀)

《陽光普照》的基本運作其實非常簡單,在這個意義上它毫不新鮮:它關於象徵債務的償還。

電影前段展示每個角色間的衝突,鋪排他們的債務經濟關係,然而這個債務關係是糾紛中的。因此真正啟動電影的是阿豪的死:它判決「父親」阿文欠下一個對「兒子」的象徵債務的關係。然後「兒子」阿和出獄被過去的同夥菜頭纏上,「父親」就透過殺死菜頭拯救阿和,還了對「兒子」所欠下的象徵債務。

這是電影的主幹,在這個意義上,小兒子阿和償還他自己的象徵債務(他當年傷害黑輪、讓小玉懷孕、「背叛」菜頭所欠下的象徵債務)的整個類型通俗劇,只能算是一個配角,一個支線。 鍾孟宏所做的,不過是在通俗劇上撒上了社會寫實的肌理,而我們不得不說它非常成功,它給予了每一場戲,尤其是阿和的整個輔育院及其後的經歷,一種澄澈而本真的緊握,而幾乎每一位演員都因此給出了他們最好的演出,純熟而精煉。

l6o5diueg9fxhk91tdka387bcup96b
Photo Credit: 甲上娛樂

問題是什麼?問題是阿豪的死在電影中是一個功能性的存在,這個死亡是為了讓「父親」獲得贖罪機會的樁腳,一個工具,而電影對於阿文的還債與阿豪的死本質上的毫無關係,幾乎可以說是無法再更顧左右而言他的了,好像它想塞給這個父親一張贖罪券的激情是如此難以抑制,以至於電影在阿豪被丟下樓之後就以最快的速度將他忘記,它甚至是如此恐懼這個贖罪券沒有被成功地送達它的目的地,以至於阿豪還得要以善鬼的形式在夢中給予這個父親最大的諒解。

關於台灣電影的慣常說法「表面上的某種悲歡離合,其實是為了服務揭露什麼什麼社會議題的需要」因此是一種錯誤的取徑(false approach),因為在更多的時候至少在《陽光普照》這裡,相反的才是真的。不是「表面上的某種悲歡離合,實際上是為了服務揭露什麼什麼社會議題的需要」,而是「表面上的社會議題大會串,實際上服務了某種悲歡離合的需要」。

因此我們應該考察的是這個精神狀態內部存在著怎麼樣的符號功效(symbolic efficiency),為什麼阿豪的死「冥冥之中」促成了阿和和父親的一根菸?這「冥冥之中」就是「溫情主義」對世界的扭曲,是「家庭秩序」或者說「溫情主義」死活賴活的對世界的挾持,將「障礙」轉化為自己「繼續向前」(move on)的慾望,在這個意義上它完全是淫穢的。

鍾孟宏新片陽光普照 演員表現廣受好評
Photo Credit: 中央社

阿豪因而在死後淪為一個任其擺佈的符號籌碼,為父親虛假的象徵「贖罪」鋪路,最終目標是確保「溫情主義」的慾望再生產不至於分崩離析,免除我們面臨世界毀滅的恐懼,以至於「繼續向前」。這是為什麼父親從反英雄,到最後揭露自己的「犧牲」迎來妻子琴姐的擁抱的那一刻,變成了悲劇英雄,他拯救的不是下一個阿豪,而是溫情主義。

是在這個意義上,我覺得《陽光普照》的這個設計是下流的。這不只是一個致命的缺陷之類的東西,這是電影暗渡陳倉對其自身的背叛。

因此值得注意的是鍾孟宏對它的可疑並非沒有戒心,然而更值得注意的是電影竟然僅止於設立一些頂多稱得上是「道路減速墊」的東西作為其應對措施,諸如父親在駕訓班結業式上逐漸冗長的演說,電影試圖透過讓它戛然而止所製造的荒謬感,或者是夫妻之間充滿同情的數落兩句,對「繼續向前」進行某種徒勞無功、虛晃一招的防禦,他們實在很難跟鍾孟宏過去扮演警覺性功能的黑色幽默橋段相提並論,在這裡比較像是發酸的牛奶。

但等一等,難道阿豪的「遺書」不正提供了我們真正抗衡這種淫穢的終極防禦甚至是攻擊,也就是阿豪對片名「陽光普照」的雙重詮釋:陽光不是溫暖的擁抱,而是一種全能律法的淫穢。這個雙重性,難道不正理應是「陽光普照」的重點?

然而正因如此,這更讓電影的後半段對自身可能雙重性的毫無所悉乃至徹底倒退令人匪夷所思,好像電影如此無法面對自己所發現的關於自身的真相,以至於馬上就在歇斯底里的哭泣之後將它壓抑下去。不要問阿豪為什麼死,更不要擔心他會來跟我們要什麼我們不能給的東西,他會體諒我們!他甚至要來拯救我們!幫父親與阿和的和解呢!不,這就是淫穢。是我們想要釋放焦慮的慾望,被偷渡進阿豪的回歸裡,電影在滿足我們的慾望。如果電影當真將阿豪的過度善意視作為他痛苦的自我貶低,作為他在無處可逃的淫穢下的某種受虐式的零度反抗(透過完全展示自身的受虐來讓大他者感到焦慮)[1] ,電影讓他以賺人熱淚的方式歸來,並成功促成了家庭秩序的修復,就是一個令人作嘔的吃乾抹淨,是對他淫穢的終極奴役,因為它支配的甚至不再只是阿豪的肉身,而是阿豪(的死亡)的符號效力。

photo_981b93d20e7f27c5caadb2d11f0a0805
Photo Credit:陽光普照,來源: 台北金馬影展

我更覺得那種論調:「但是偷偷地,因為這樣或那樣的細節,電影難道不其實正是在批判自己在表面上所呈現的東西嗎?」,影評人皆樂此不疲地熱衷於此,完全是自我催眠式地錯過了重點:「難道阿豪過度體諒的歸來不正是電影偷偷地在批判眾人對阿豪的支配嗎?」、「難道這不是保留給觀眾自己思考?」、「難道這不過是角色類型化嗎?」。它正令人想起那個關於手推車和警衛的故事:警衛懷疑工人偷竊,天天檢查工人的手推車卻空無一物,最終發現工人偷的正是手推車。影評人們在用探針細細嗅聞每一個被支解的影格中的細節試圖找出它一層又一層令人驚嘆的隱藏真相時,正正完全錯過了關於它的表層形式本身的最顯而易見的一個真相:電影完全把阿豪鬼魂的歸來和阿文揭露自己為子付出的最後的救贖當成一個洗滌人心的本真感人的時刻。

這些論調不只太容易地讓我們擺脫困境(let us off the hook),更完全輕忽阿豪這個形象的空洞遠遠更傾向於讓電影的態度危險地過度到居高臨下的同情(condescending),就像議題電影常見的那樣,在這個意義上黃榮昇的《小美》才是完全失敗地最糟糕、最下流的例子[2] 。 另外《陽光普照》的此一設計的附帶效應是,它讓電影顯然傑出與熟練深思的關於阿和的另一半(儘管很難說它是獨特的,它有它自己的問題,但這已經是另一個題目)處於一種半可疑狀態。我甚至覺得它限制了父親的可能角色深度發展,因此更不應該誤以為我們應該要將所有廉價的怒意都發洩在阿文身上,阿文只是無能。

整個後半段在這個意義上也因此被賦予了功能性的任務,它是電影與觀眾共謀的一場力比多經濟(libidinal economy)的貍貓換太子,通過一個最能激起氾濫情感的類型通俗劇,通過觀眾對阿和獲得完滿家庭生活的盼望,轉移觀眾的思考至一種純粹的激情的滿足,透過引介另一個阻礙(菜頭)並將它偽裝成唯一重要的阻礙,順理成章地讓父親去消滅這個阻礙,提升父親至殉道「悲劇犧牲」的位置,以拯救並滿足我們對「家庭秩序」或「物歸原處」的信仰,而這個信仰,被實體化為阿和的新家庭,以及阿和與母親終於迎來的本真時光。

陽光普照劇情感人  導演鍾孟宏從人父經驗取材
Photo Credit: 中央社

整個後半段,就是為了讓我們逃避真正的阻礙——阿豪的死亡所構成的阻礙——所精心設計的嗎啡,我們滿足了,所以我們回朔性地賦予電影對阿豪之死模棱兩可的「反思」以及對它的穿越正當性,至此電影完全成為自己宣稱所要反對的,全知全能「家庭秩序」的淫穢,而這個運作機制最下流的地方,就是用表面上的自我批判來達到重新肯認自身支配正當性的目的。

因此當歷經劫難的阿和邀請母親一起在撒落的陽光下騎單車時,溫情主義就宣告它的勝利了。我們遠遠不該在柯淑勤望向太陽的惆悵中投射自己關於「陽光普照」的雙重性依然存在的一廂情願的不安,而應該面對以下這個殘忍的事實:電影是真實的逃避了。我甚至覺得說這顆鏡頭是電影在一個「佛洛伊德式錯誤」(Freudian slip)中透露出的對自身的慚愧都十分可疑。真正在銀幕上發生的,是阿豪的死被完全化作為「世界運作的不可逆反的規則之一」,因此這顆鏡頭已經不可能有任何減速墊的效果,而是對溫情主義的俯首稱臣。如果這裡還有任何鍾孟宏招牌的雙重性企圖那也只剩下奄奄一息的一種。我甚至覺得試圖玩弄「陽光普照」片名的某種佛學式的神秘意味的意圖,到了電影的最後是一種狡猾。

鍾孟宏新片陽光普照入選多倫多影展
Photo Credit: 中央社

我遠遠不覺得持續嘗試拍出《第四張畫》、《失魂》、〈回音〉和《醫生》的鍾孟宏因此就成為了溫情主義的擁護者,事實上我甚至覺得鍾孟宏拍攝這部電影大概正是源於對溫情主義的反感。然而正因如此我們應該大方承認鍾孟宏確實是碰到了他的侷限,《陽光普照》雙手一攤「一切皆如此」卻又難以保持自己所宣稱的清醒以至於在溫情主義的威脅利誘下被甕中捉鱉,不是鍾孟宏的勝利,而是倒退。這也讓我比較悲觀地認為,《陽光普照》表現的是台灣電影碰到了溫情主義的「事件視界」(event horizon),在溫情主義的潛移默化之下我們看不到更多的可能性。

如果要我假設鍾孟宏所碰到的問題的話,我會說他似乎是錯誤地將自己的框架(framing)理解為現實的極限,或者是我們太過習於給予一種太過簡單的議題臉譜化正當性,以至於將高材生一而再再而三跳樓的社會現實空虛化為阿豪的中空形象被理解為唯一可能的取徑,這才是為什麼電影只能借一個「司馬光寓言」動畫、一個關於「陽光普照」的遺書和溫貞菱在告別式上抽噎的註釋來回朔性地定義阿豪,同時遮遮掩掩地保持一種表面上的模稜兩可,卻又同時讓一個顯而易見是過度膚淺的預設答案呼之欲出,以至於它最後反而複製了阿豪對「陽光普照」雙重性的詮釋所要提醒我們引以為戒的東西。然而問題或許應該是,這個框架本身最初就是錯的。這個令人反胃看似是思考怠惰的背後,其實是一個關於無能的焦慮。

國片陽光普照入選釜山影展(1)
Photo Credit: 中央社

非常奇怪看見一部宣稱將自己奠基於對意義系統失靈的反思的電影,最終用一種最過量(excessive)的方式意義爆炸。《啟蒙的辯證》(Dialectic of Enlightenment)的這段提醒在這裡或許會是有用處的: 「意識不喜歡把死亡思考為絕對的虛無,絕對的虛無是無法被思考的。而如果說生活的負擔落回到留在世上的人,對他而言,死者的境遇似乎要好一些。遺族在其親屬死後用以重新組織其生活的方法,祭拜死者的繁複儀式,或更好說是把遺忘給合理化的世故做法,是鬼神信仰的現代翻版,該信仰以揚棄的形式殖生為招魂術。唯有我們完全意識到死亡的恐懼,才能夠和死者建立正確的關係:和他們合而為一,因為我們和他們一樣,都是同樣的境遇和絕望的受害者。」[3]

[1]更多關於這個詮釋的說明,參見斯拉沃熱.齊澤克(Slavoj Žižek),《歡迎來到實在界這個大荒漠》,2012年11月,南京:譯林出版社。P.22。

[2] 我非常清楚鍾孟宏和他的團隊大量參與了《小美》的製作,然而我遠遠不是要暗示《小美》的根本問題與鍾孟宏有任何關係,事實上我甚至覺得,儘管這也只能是猜測,鍾孟宏大概幫黃榮昇修正了很多問題,對電影的影響大概是正面的。

[3]馬克斯.霍克海默(M. Max Horkheimer)、提奧多.阿多諾(Theodor W. Adorno),《啟蒙的辯證》,2008,臺北市:商周出版。P. 268。

延伸閱讀

責任編輯:王祖鵬
核稿編輯:翁世航


猜你喜歡


挖掘雲端開放架構優勢!Amazon EKS高可用性叢集快速部署容器

挖掘雲端開放架構優勢!Amazon EKS高可用性叢集快速部署容器

我們想讓你知道的是

企業如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署,減輕人力負擔,提升專案服務運作效率?

所謂現代化智慧 IT,所有工程師最希望的境界,莫過於只要輕鬆點幾下設定,系統就會自動跑起來,管理者再也不用隨時待命在機台旁邊,從此工作悠哉又快樂!儘管這樣情境還沒到來,但隨著敏捷式開發的流行,除了 DevOps 人員,有越來越多開發者將 CI/CD 概念融入到工作流程當中,例如從 build code、執行 unit test、到部署應用程式。

透過 AWS 增加雲端技能 在組織發揮影響力

上述種種反覆步驟自動化執行,也就能提昇服務品質、主動通知開發人員以減輕人力負擔,讓專案服務能持續運作。

其中,GitLab 是執行 CI/CD 常用的工具之一,也是開發者使用程式碼儲存庫的地方。為了讓 GitLab Runner 在雲端快速實踐 CI/CD,《AWS 開發者系列》透過影片分享,如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署。

以下節錄工作坊影音內容,幫助開發者快速理解如何運用 Amazon EKS 的高可用性且安全的叢集,將修補、部署節點、更新等關鍵任務,全部做到自動化設定。同時影片也會示範 Amazon EKS 搭配 GitLab 如何展開自動部署,幫助工程團隊實踐 CI/CD 價值。

Amazon EKS 對容器管理輕鬆簡單、維運省時省力

容器化服務越來越興盛,當容器(Container)越來越多,在複雜的微服務(Microservice)系統環境之下,運維團隊的管理成本可能相對會增加不少,為了有效調度容器部署, 導入Kubernetes 無疑是近年企業熱門的話題之一。

建構 Kubernetes Cluster 流主要可區分兩大塊,一是安排容器調度的Control Plane、另一則是容器運行時需要用到的 Worker Node。

Control Plane 裡面涵蓋有儲存狀態的 ETCD、CoController manager 、Scheduler 的調度管理、甚至是操作時進行互動的 APIServer,若是自己創建 的 Kubernetes Cluster ,需要自己安裝這些元件,後續仍需要對 Control Plane 進行相關管理、維護、升級工作。為了減少上述 Components 的繁複維護,在透過 AWS EKS 代管的 Kubernete Control Plane 部可以獲得以下三大好處。

Amazon EKS 一鍵式部署,展現三大優勢

第一,Amazon EKS代管的 Control Plane實踐了跨AZ的高可用部署,使用者不需要擔心單一節點故障的風險。

第二,Amazon EKS 支持至少四個 Kubernetes版本,持續跟進每季 CNCF 的發佈,同時 EKS 也完全符合上游 CNCF 規範。

第三,部署 Amazon EKS 之後,可直接使用 AWS 平台上現成的服務工具,在安全性管理、網路設定方面,可以做到無縫整合。

最後 AWS 台灣解決方案架構師也提到,若想在容器環境進行 CI/CD 及應用程式的管理,可以進一步透過 IaC 整合部署 Amazon EKS 叢集,透過使用 Console、把 EKS 變成 Cloudformation 的模板、使用 AWS 所開發出來的 eksctl.io、或指令是採用 AWS CDK 可以讓開發者用自身熟悉的語言,在 AWS 平台整合 CI/CD 工具進行維運及部署 EKS。

打造第一個在 AWS 上的應用程式

了解 Amazon EKS 整合 GitLab ,獲得三面向價值

對開發者而言,想把 Amazon EKS 整合到 CI/CD 工具之一的 GitLab 平台上,可以看到那些實際的優勢?

在 DevOps 開發者示範工作坊當中,GitLab 資深解決方案架構師指出,GitLab 使用到 Kubernetes 技術,主要有三種搭配方法,包含 GitLab Server、GitLab Runner、以及創建 Deployment Environment。

本次示範教學會主要聚焦在 GitLab Runner 如何採取 Auto-scaled 方式進行 Build、Test、Package Apps;以及在 Deployment Environment 運用 Kubernetes 技術,做到 Auto Deploy、Review App。

正因為 Amazon EKS 能夠在 DevOps 過程提供所需要的彈性計算資源,幫助開發者在 GitLab 平台上面獲得以下三個層次的優勢:

  • 在 GitLab 內建的部署工作流程當中,自動生成整套 CI/CD 最佳實踐腳本。
  • Review App 過程,從 Merge Request 中可直接訪問應用程式 /App 的 UI 介面,並且根據 Git branch 名稱、專案名稱,自動生成 Review App 的 URL,以及在 Merge 前的最後防線進行 Approval 檢查。
  • 加速 CI/CD 流水線,GitLab Runner 運行時候還可藉由 Amazon EKS Cluster 進行 Auto-scaled 的支援。

Amazon EKS 整合 GitLab ,需要兩大流程

影片最後,GitLab 資深解決方案架構師示範如何把 Amazon EKS 整合至 GitLab 執行 Auto Deploy,主要可分為兩大區塊流程,第一部分聚焦在 Amazon EKS cluster 的設置,第二部分則執行 Auto Deploy 設置。

第一塊可拆分為四個階段,首先教學怎麼創建 EC2 節點的 EKS cluster,第二階段示範把 EKS Cluster 連接到開發者的 GitLab Instance、Group 或 Project,下一步則使用 Cluster Management Project Template 創建一個 Cluster Management Project,以及最後一階段透過 Cluster Management Project 自帶的 Helm Chart,安裝在 Cluster 所需要的內建 App。

第二塊執行 Auto Deploy 設置,針對需要部署的 App 創建一個 GitLab Project,接著再把 gitlab-ci.yml 添加到 Project,並從 Web IDE 選擇及導入 Auto Deploy 的 CI 模版,讓 GitLab 自動生成最佳實踐的整套流水線。

幫助開發者更了解 Amazon EKS 整合 GitLab 的 QA 系列

Q:使用 Amazon EKS 之後,如何更有效率或優化資源去配置 Worker Node 的機器數量,以及如何有效空管開發維運的成本?

A:Kubernetes 除了本身有 HPA(Horizontal Pod Autoscaling)可根據使用程度自動調整資源流量,另外也能延伸使用 AWS Auto Scaling 方案,針對可擴展資源去設定自動擴展管理。另外在成本管控,雖然 Amazon EKS 會收取額外管理費用,但可透過 AWS 平台的 Calculato r計算每個 EKS 的價格,你會發現自動化部署及管理的費用,相對工程師人力的成本更加便宜。

Q:越來越多客戶考慮把現有 Application 變成容器部署,大多是爲了加快部署的效率,那麼變成容器模式之後,對 CI/CD 的工作流程有什麽影響嗎?

A:運用容器技術最直接的效果,可以讓應用程式的環境更一致化,例如 testing 環節、stage production,讓容器避開一些差異問題。至於 CD 部分要 delivery 一些 usage 不太一樣的時候,容器會幫忙做配置,所以 CI/CD 對容器的效益是相輔相成的。

Q: 客戶在開發流程漸漸會把 Infrastructure 變成代碼或文檔,是不是可以把程式碼跟現有的應用程式的 CI/CD 流水線整合在一起,達到一套完整的 CI/CD 部署流程?

A:觀察目前市場作法,主要分成兩個階段去做整體部署。如果規模比較小的團隊,會把 Infrastructure 代碼跟 App 代碼分開,在管理上會比較靈活;如果企業規模比較大,會有另外一個 Infrastructure 團隊來控制部署事情,這種情况之下,APP 的項目會生成一個 APP package,主要做到 delivery 這個階段爲止。而 Infrastructure 的項目會指定把需要版本的文檔,部署到他們的 Kubernetes Cluster。

填寫表單 找到適合的快速上雲服務與工具!


猜你喜歡