《維京戰士傳奇》:神秘的「盧恩符文」,以及歌頌英雄傳奇的吟遊詩人

《維京戰士傳奇》:神秘的「盧恩符文」,以及歌頌英雄傳奇的吟遊詩人
Photo Credit: Asztalos Gyula@Wiki Public Domain

我們想讓你知道的是

維京人常被描述為原始的蠻族,對藝術、文化與書寫棄若敝屣。這樣的偏見往往是受於基督教歐洲的拉丁文手稿之渲染;事實上,維京人的文化傳統源遠流長,只是比起繕謄抄寫,他們更重視口耳相傳罷了。

文:安古斯・堪斯坦(Angus Konstam)

盧恩符文, 吟遊詩人與英雄傳奇

維京人常被描述為原始的蠻族,對藝術、文化與書寫棄若敝屣。這樣的偏見往往是受於基督教歐洲的拉丁文手稿之渲染;事實上,維京人的文化傳統源遠流長,只是比起繕謄抄寫,他們更重視口耳相傳罷了。

維京人的語言自有其豐富的內涵,之中包括了用於書寫,獨特的盧恩符文系統。這套字母見諸斯堪地那維亞各地的符文石,偶爾也會在歐洲其他地方發現。以盧恩字母書寫的手稿是今人得以一窺維京人文化堂奧的文獻記錄,但隨著維京時代的落幕,拉丁字體取代了符文,前人的書寫遺產受到冷落漠視。所幸仍有些維京傳奇留存至今,其中蘊藏著豐富的維京文化傳承。這些英雄傳奇是吟遊詩人,他們所傳唱的故事中追想著維京的歷史、宗教的信仰,歌頌著維京戰士們的英勇事蹟。這些符文石與傳奇詩歌交織出一扇神祕的門扉;開啟之後,便進入了維京人的精神世界。

盧恩符文

先前維京人曾經謄寫過多少抄本,已經不得而知;當時的文件之中,僅有少數的法律文件以及官方記錄,而北歐吟遊詩人的傳奇手稿是在維京時代結束之後才錄存成文字的。不過,維京人也常常在石塊上鐫刻下神祕的符號——線條剛直如杆杖的盧恩符文,便是他們使用的字母系統。

維京人的神話傳說之中,這套字母是神族之長奧丁孤身倒吊在世界樹尤克特拉希爾的枝上,凝視命運女神烏爾德的井水整整九個晝夜,終於獲得的智慧。通過試煉之後,從世界樹上摔落的奧丁,將此知識遍傳給人類。歷史的考證追溯倒是沒有這麼曲折離奇,我們大概可以推論出這套系統傳到斯堪地那維亞的年代大約在西元二世紀左右;而在此之前,它已經在歐洲北部地區流傳了好幾個世紀之久。由於羅馬的興起,拉丁字母在西歐強勢地取代了盧恩符文,但是因為斯堪地那維亞一直是羅馬勢力所不及之地,當地人便毫不受影響地繼續使用這套字母。

這套字母的名稱「盧恩」來自古英語「rūn」,本意是「祕密」;每一個字母都有對應的咒語。以簡單的直線條構成的符文字母,易於在木料上彫出;即使是斜劃也經過特意的設計,可以避開木頭的紋理,維持字跡清晰易讀。只需要一柄刀刃就可以在木頭上記錄下符文,通常言簡意賅,並不冗贅——如同現代流行的推特一樣。文字在傳播的過程中也會演化,在維京世代揭幕之際有兩套稍有差異的符文系統並行,丹麥地區使用一種,而挪威與瑞典則是另外一套。基礎的十六個字母依照起首六個字母為名, 稱為「符拓刻」(futhark)。每一個符文同時具有字母的拼寫用途,以及類似咒文的獨特意涵。咒文的意涵會因時、因地而異,從這些演變之中可以追溯、重建出盧恩符文的傳播軌跡。

通用的丹麥式符文的兩種意義最為人所周知。舉例來說,第一個字母,用在拼寫的場合中等同於拉丁字母的「F」,單獨出現時的字義則是「犢牛」。挪威與瑞典通行的符拓刻與丹麥形貌有些差異,有些人基於它彫寫的特徵而稱之為「短槓符拓刻」。這套拼寫系統的原型僅有十六個字母,隨著語言內容的擴充而漸漸地不夠用,人們便在彫寫符文的時候借用符號來擴充字義,比如說用「t」取代「d」;另一種演變的例子則是省略輔音之前的d。這些變形的拼法,令現代的歷史學者在辨讀盧恩符文時都倍感困難,遑論當時的維京人。因此,到了維京時代的末期,人們不再借用符號,改以創造出新的符文來補充原有的不足。

許多彫寫在木頭上的訊息隨著木料的腐朽而佚失,所幸要把這種文字彫上石板、骨頭或者金屬也相當容易。因此,維京人的手跡是散布在斯堪地那維亞各地:隨處可見的符文石、骨製器具、鐵製兵器,或者建物牆上的潦草塗寫。不刻在木頭上,線條結構更沒有閃避木紋的顧慮,可以劃出曲線,彫寫的速度更快。因此,在鐵、石、骨頭材質上所發現的符文,常常有比較圓潤的字體結構。甚至有些符文等同於塗鴉留言;在奧克尼島上,名稱為梅肖韋的新石器時代葬場中,就發現了盜墓的維京人刻下一段符文來讚賞一位名為英姬碧悠的美女。君士坦丁堡(今名為伊斯坦堡)的聖索菲亞大教堂內,也有維京人刻下類似「某某到此一遊」的字跡,到現在仍然清晰可見。

盧恩符文
通用盧恩符文系統也稱為丹麥系統,以名為「符拓刻」的字母拼成單字;但單獨的一個字母也有本身的隱義。如此的運用方式,就是古人的速記法|Photo Credit:楓樹林

吟遊詩人

北歐語中,「skald」的字義是詩人。在北國的漫長冬季之中,吟遊詩人在維京的領主們之中遊走,足跡遍及國王的宮廷、貴族的廳堂與富農的宅邸。他們頌唱情節豐富的詩歌,有些會配上豎琴或七弦琴為伴奏。這些詩篇緊扣著維京生活為主題——家庭與親情、英雄氣概、榮譽與德行。很幸運地,當時的人們以符文記下了其中若干,日後更是改編為英雄史詩流傳至今。吟遊詩人的歌詠是無價之寶,我們得以從中領略到,當時的維京人是怎麼看待自己與身處的那個世界。

從留存至今的符文石上所收集到的詩文來看,最常見的短文有墓誌銘與追憶;懷念往生者、讚揚他們的行誼。連篇的長歌與文藻豐盛的史詩,規模大到要好幾個鐘頭才能吟詠完畢;這麼複雜的詩歌最後演變成帶有韻律的長篇文體,也就是當今人們所知曉的,北歐特有的英雄傳奇。冰島是北歐傳奇詩篇的的原鄉,許多吟遊詩人便出身於此,從小浸淫在豐富的詩歌教育之中,之後在維京世界中遊歷,以歌聲和詩文慰藉各處的家主及其眷屬。

有些吟遊詩人會追隨著一個家族,記述他們的事蹟與功業,而在冬季的巡迴之中演出依此撰寫而成的詩歌,宣揚這個家族的名聲。也有短韻詩篇的主題是更不起眼的凡夫俗子,或者是一場戰役、一次劫掠的過程;也有作為葬禮禱詞、表揚好人好事的作品……不一而足。吟遊詩人們是那個時代的演藝明星,以他們的詩才贏得豐厚的獎賞與報酬。在斯堪地那維亞的漫漫冬日裡,再沒有什麼事物能比一場宴會上令人回味再三的詩篇、聲韻鏗鏘的傳奇故事更能撫慰緩解這些受苛苦天候折騰的人心了。

吟遊詩人們有種約定俗成的套路,以共通的譬喻典故來引導人們的共鳴。打個比方來說,「女武神之樹」就是形容維京勇士在戰場上淵渟嶽峙、頂天立地的站姿,有如根基穩固的神木。即使整段詩文的隱喻講得再拐彎抹角,熟知如此典故的觀眾們依然能心神領會。詩篇也有一套既定的格律,名為「德洛特勱忒」(冰島語:dróttkvæt);韻文中八句為一段落,每句長六字。制定格律為賦詩設下技巧的門檻,但跨得過這道限制的詩人們卻也因為對格式的嫻熟,而更容易牢記、背誦作品。可惜,除了少部分被彫寫在石碑上的片段,保留至今的詩歌已經不多。幸而,在維京時代之後,有一群新世代的學者與藝人們以英雄傳奇的體裁,存續了此一傳統的神魂精魄。

相關書摘 ▶《維京戰士傳奇》:令人聞風喪膽的狂戰士,殺紅了眼可能只因「喝了點酒」

書籍介紹

本文摘錄自《維京戰士傳奇:北國海盜們的生涯、配備、武裝與戰鬥技術》,楓樹林出版
*透過以上連結購書,《關鍵評論網》由此所得將全數捐贈聯合勸募

作者:安古斯・堪斯坦(Angus Konstam)
譯者:詹君朴

北國海盜們的生涯、配備、武裝與戰鬥技術
維京戰士是殺人越貨的賊寇,也是乘風破浪、矢志朝前的鬥士,
這群海上劫匪,燒殺搶掠、無惡不作,是的太平盛世的禍害,
卻也是中世紀歐洲,永垂不朽的傳奇。

【本書特色】

  • 維京的社會結構:王權與群落的關係,北歐諸神,農莊與飲宴廳的風俗,盧恩符文與傳奇文學。
  • 維京人的樣貌:衣飾、護具、武裝、北歐戰斧與斯堪地那維亞單體長弓,劫掠與戰爭所得的戰利品。
  • 維京人的船隻:遠航的技藝、造船與艤裝的工法,商船與戰船的類別,古人的導航方法與海戰的種種細節。
  • 維京人的武事:劫掠、征服、大部隊行動、要塞、維京人獨有的戰術與戰技,盾牆、對英雄武勇的崇尚與個人名節的追求。
  • 維京人的國度:向東探索、往西拓墾,征服不列顛諸島與北海帝國的建立,維京人在北美洲留下的蹤跡。
維京戰士傳奇
Photo Credit:楓樹林

責任編輯:羅元祺
核稿編輯:翁世航


猜你喜歡


挖掘雲端開放架構優勢!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。

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


猜你喜歡