幾個其他 Teams 的替代方案 (但還是連到 Teams 伺服器)

這邊講的替代方案不是換掉 Teams,而是找其他的方法連上 Teams 伺服器,畢竟用 Teams 的人大多都沒得選...

在「Teams is killing my Mac every day (microsoft.com)」這邊看到的一些資料可以嘗試,裡面有很多抱怨 Teams 的問題,但還是有些人有給出一些 workaround。

大家主要遇到的問題除了 CPU 吃很兇以外,另外就是記憶體這塊。

一種方法是是用 Edge 瀏覽器的 extension 來跑,我本來想看看 Linux 上的 Brave 能不能裝,但沒有看到對應的安裝連結,大概是 Edge 限定:

If you don't want to use the Microsoft Teams app (which uses a lot of resources), you can:

1. Install the Microsoft Edge Web browser on your Mac

2. Log into https://teams.microsoft.com

3. Click ... > Apps > Install this site as an app

This will create an Edge app for Teams that uses almost no resources but has feature parity with the regular Microsoft Teams app.

We tell all of our students to do this, and it has solved all Microsoft Teams performance issues on student Macs (both Intel and Apple Silicon).

另外有人提到其實官方是有放 M1 的 preview 版本的,雖然不是正式版,但總是比 Intel 版本會好一些:

If you're running an Apple Silicon Mac you can get an early build of Teams osx-arm64 from the exploration build link listed here.[0]

I've been running a daily build for a few weeks and it's noticeably better than the Intel build on an M1 Pro. It launches in half the time and feels far more responsive (probably due to not needing to use the Rosetta JIT for Electron). That said it's still a daily "exploration" build so YMMV.

[0] https://raw.githubusercontent.com/ItzLevvie/MicrosoftTeams-msinternal/master/defconfig

據說會少吃一點點記憶體,就真的大概一點點:

Can confirm it is snappier on a M1 Macbook Pro and using *less* RAM, maybe about 10% less.

但據說這個 preview 版本在自我更新時會跳到 Intel 版本,還要再找一下 workaround 關掉自動更新:

How do you prevent it from automatically updating to the Intel version? I keep downloading the preview builds and they keep getting updated.

後面還有看到有人說他直接實體隔離,把這些肥滋滋的 app 跑在另外一台 Mac 上,然後透過 Universal Control 使用,大多數的情況下都夠用,真的有需要分享畫面時再跑在自己機器上,用完就可以關掉:

Thanks for the tip. I'll give this a try!

For work, I have to run Microsoft Teams, Slack, and Discord. Of those 3, Slack surprisingly uses the least amount of memory (~700 MB), and Teams uses the most (~1.5 GB). I dusted off an old Intel Mac (literally) and interact with it using Universal Control. It only runs those 3 chat apps + mail. It's turned out to be a great way to offload resource hogs and as an added benefit, it minimizes distractions. I'll occasionally glance at the dock to see if there are any notification badges, whereas on my main Mac, I'd feel compelled to deal with notifications immediately.

When I have to share my screen or focus on a conversation, I'll fire up one of those 3 apps on my main (M1) Mac and quit it when I'm done.

Universal Control still feels rough around the edges, but it has saved me from ditching my Macbook Air and shelling out for an M1 Macbook Pro. Sometimes there are issues with reconnecting to the Intel Mac, but it seems to resolve itself if I wait a bit or turn off/on wifi.

大家都在找方法 XDDD

EC2 Auto Scaling 可以透過機械學習來預開機器了

Amazon EC2 的新功能,Auto Scaling 可以透過歷史資料分析預開機器了:「Amazon EC2 Auto Scaling customers can now monitor their predictive scaling policy using Amazon CloudWatch」。

這是吃 CloudWatch 的資料做的,在「Predictive scaling for Amazon EC2 Auto Scaling」這份文件裡面有提到:

Predictive scaling uses machine learning to predict capacity requirements based on historical data from CloudWatch.

還是希望把 Auto Scaling 整合 Lambda 啦,這樣就是 turing machine 了...

用 GPT-3 解讀程式碼

Hacker News 上看到的方法,Simon Willison 試著把程式碼餵進 GPT-3,然後問 GPT-3 程式碼的意思,看起來答的還不錯:「Using GPT-3 to explain how code works」,對應的討論 (包括 Simon Willison 的回應) 則可以在「Using GPT-3 to explain how code works (simonwillison.net)」這邊看到。

第一個範例裡面可以解讀 regular expression,雖然裡面對 (?xm) 的解讀是錯的,但我會說已經很強了...

第二個範例在解釋 Shadow DOM,看起來也解釋的很不錯...

第三個範例回來原來產生程式碼的例子,拿來生 SQL 指令。

後面的 bonus 題目居然是拿來解釋數學公式,他直接丟 TeX 文字進去要 GPT-3 解釋柯西不等式 (Cauchy–Schwarz inequality)。這樣我想到以前高微作業常常會有一堆證明題,好像可以丟進去要 GPT-3 給證明耶...

Hacker News 前幾天炸很久的 root cause

前幾天 Hacker News 炸了很久,如果是從 Twitter 上的資料來看,是從 2022/07/08 14:08 UTC 這篇:

中間還原失敗 (2022/07/08 17:35 UTC):

到最後恢復 (2022/07/08 20:48 UTC):

Twitter 這邊的資料看起來差不多是六個小時多,以一個應該是只有 database 需要還原的站台來說的確是蠻久的,所以後續在「HN is up again」這邊就有在討論原因,裡面 HN 的老大 dang 也有提到 downtime 是七個小時多:

8 hours of downtime, but not data loss, since there was no data to lose during the downtime.

Last post before we went down (2022-07-08 12:46:04 UTC): https://news.ycombinator.com/item?id=32026565

First post once we were back up (2022-07-08 20:30:55 UTC): https://news.ycombinator.com/item?id=32026571 (hey, that's this thread! how'd you do that, tpmx?)

So, 7h 45m of downtime. What we don't know is how many posts (or votes, etc.) happened after our last backup, and were therefore lost. The latest vote we have was at 2022-07-08 12:46:05 UTC, which is about the same as the last post.

There can't be many lost posts or votes, though, because I checked HN Search (https://hn.algolia.com/) just before we brought HN back up, and their most recent comment and story were behind ours. That means our last backup on the ill-fated server was taken after the last API update (HN Search relies on our API), and the API gets updated every 30 seconds.

I'm not saying that's a rock-solid argument, but it suggests that 30 seconds is an upper bound on how much data we lost.

另外大家就在找 dang 的回應是什麼 (畢竟是第一手資料),用 Ctrl-F 找一下就看到有趣的猜測,從 32028511 這個節點可以看到這串有趣的討論,首先是 mikeiem

You are never going to guess how long the HN SSDs were in the servers... never ever... OK... I'll tell you: 4.5years. I am not even kidding.

然後是 kabdib 的回應:

Let me narrow my guess: They hit 4 years, 206 days and 16 hours . . . or 40,000 hours.

And that they were sold by HP or Dell, and manufactured by SanDisk.

Do I win a prize?

(None of us win prizes on this one).

接著就是 dang 說他覺得這個猜測很有可能:

Wow. It's possible that you have nailed this.

Edit: here's why I like this theory. I don't believe that the two disks had similar levels of wear, because the primary server would get more writes than the standby, and we switched between the two so rarely. The idea that they would have failed within hours of each other because of wear doesn't seem plausible.

But the two servers were set up at the same time, and it's possible that the two SSDs had been manufactured around the same time (same make and model). The idea that they hit the 40,000 hour mark within a few hours of each other seems entirely plausible.

Mike of M5 (mikiem in this thread) told us today that it "smelled like a timing issue" to him, and that is squarely in this territory.

後續他也從自家的 /newest 裡面撈了相關的資料出來,依照他撈出來的關鍵字,看起來是用 HPE 出的 SSD:

It's also an example of the dharma of /newest – the rising and falling away of stories that get no attention:

HPE releases urgent fix to stop enterprise SSDs conking out at 40K hours - https://news.ycombinator.com/item?id=22706968 - March 2020 (0 comments)

HPE SSD flaw will brick hardware after 40k hours - https://news.ycombinator.com/item?id=22697758 - March 2020 (0 comments)

Some HP Enterprise SSD will brick after 40000 hours without update - https://news.ycombinator.com/item?id=22697001 - March 2020 (1 comment)

HPE Warns of New Firmware Flaw That Bricks SSDs After 40k Hours of Use - https://news.ycombinator.com/item?id=22692611 - March 2020 (0 comments)

HPE Warns of New Bug That Kills SSD Drives After 40k Hours - https://news.ycombinator.com/item?id=22680420 - March 2020 (0 comments)

(there's also https://news.ycombinator.com/item?id=32035934, but that was submitted today)

這次 downtime 看起來很像是中了 SSD firmware bug,目前看起來先搬到 EC2 上面了:

$ host news.ycombinator.com
news.ycombinator.com has address 50.112.136.166
$ host 50.112.136.166      
166.136.112.50.in-addr.arpa domain name pointer ec2-50-112-136-166.us-west-2.compute.amazonaws.com.

看討論串應該是暫時性的?

Starlink 推出 Starlink Maritime

先前是 Starlink 推出了 RV 版本 (參考「Starlink 推出 RV 版本」) ,雖然是車輛,但基本上跟先前 Starlink 一般開放的區域相同,也很好理解...

但這次 Starlink 推出了 Starlink Maritime,是給船隻用的,這個需要的服務範圍就大超多,從 maritime-coverage-map.pdf 這份資料可以看到對應的計畫:

目前第一波覆蓋的地區應該是可以直接打回地面 ISP 的,後續的大面積覆蓋 (2022Q4 以及之後) 應該是得在衛星間 relay 的技術上線使用後才有辦法提供...

看了一下台灣週邊的海上其實在 2022Q4 會上,所以有機會 (如果電信法規搞定的話) 應該可以同步上?

Amazon EC2 有 Mac (M1) 機種可以租用了

2020 年年底的時候 AWS 推出用 Mac mini 配合搭建出 Mac (Intel) 機種:「Amazon EC2 推出 Mac Instance」,當初有計畫在 2021 年推出 M1 的版本:

Apple M1 Chip – EC2 Mac instances with the Apple M1 chip are already in the works, and planned for 2021.

不過就沒什麼意外的 delay 了,這次則是推出了 M1 的版本:「New – Amazon EC2 M1 Mac Instances」。

依照說明看起來還是 Mac mini,掛上 AWS Nitro System

EC2 Mac instances are dedicated Mac mini computers attached through Thunderbolt to the AWS Nitro System, which lets the Mac mini appear and behave like another EC2 instance.

然後跟 Intel 版本一樣,因為是掛進 Dedicated Hosts 的計價方式,雖然是以秒計費,但還是設定最低 24 小時的租用時間限制:

Amazon EC2 Mac instances are available as Dedicated Hosts through both On Demand and Savings Plans pricing models. The Dedicated Host is the unit of billing for EC2 Mac instances. Billing is per second, with a 24-hour minimum allocation period for the Dedicated Host to comply with the Apple macOS Software License Agreement. At the end of the 24-hour minimum allocation period, the host can be released at any time with no further commitment.

Intel 版本代號是 mac1,只有一種機種 mac1.metal,M1 版本代號是 mac2,也只有一種機種 mac2.metal

以最經典的美東一區 us-east-1 來看,mac1.metal 的 on-demand 價錢是 US$1.083/hour,mac2.metal 則是 US$0.65/hour,差不多是 60% 的價錢,便宜不少,大概是反應在硬體攤提與電費成本上了。

另外目前大家用 M1 的經驗來看,Rostta 2 未必會比原生的機器慢多少,雖然 mac1.metal 是 12 cores,mac2.metal 是 8 core,但以雲上面一定要用 Mac 跑的應用來說,馬上想的到的還是綁在 Apple 環境裡 CI 類的應用?

目前看起來主要的問題還是 24 小時的最小計費單位讓彈性低不少...

歐盟通過 Digital Markets Act 與 Digital Services Act

Hacker News Daily 上翻的時候看到的大消息,歐盟通過了 Digital Markets Act (DMA) 與 Digital Services Act (DSA):「EU Approves Landmark Legislation to Regulate Apple and Other Big Tech Firms」,這兩個法案會直接衝擊大企業壟斷的情況。

找了一下中文的資料,iThome 有報導:「歐洲議會通過《數位服務法》與《數位市場法》!傳訊服務必須互通,不得禁止使用者採用第三方App Store」。

其中 MacRumors 上的文章整理的蠻清楚的,DMA 包括了:

  • Allow users to install apps from third-party app stores and sideload directly from the internet.
  • Allow developers to offer third-party payment systems in apps and promote offers outside the gatekeeper's platforms.
  • Allow developers to integrate their apps and digital services directly with those belonging to a gatekeeper. This includes making messaging, voice-calling, and video-calling services interoperable with third-party services upon request.
  • Give developers access to any hardware feature, such as "near-field communication technology, secure elements and processors, authentication mechanisms, and the software used to control those technologies."
  • Ensure that all apps are uninstallable and give users the ability to unsubscribe from core platform services under similar conditions to subscription.
  • Give users the option to change the default voice assistant to a third-party option.
  • Share data and metrics with developers and competitors, including marketing and advertising performance data.
  • Set up an independent "compliance function" group to monitor its compliance with EU legislation with an independent senior manager and sufficient authority, resources, and access to management.
  • Inform the European Commission of their mergers and acquisitions.

可以看出來除了最後兩項是針對 EU 的監管機制外,其他的包括了安裝來自第三方的軟體、可以使用第三方的付款系統、可以整合系統服務、可以整合硬體功能、可以使用第三方的語音工具、可以反安裝所有的 app 以及提供平台蒐集到的資料給開發者,都是針對現在 AppleApp StoreGoogle Play 所限制的條件。

另外 DMA 也禁止了這些行為:

  • Pre-install certain software applications and require users to use any important default software services such as web browsers.
  • Require app developers to use certain services or frameworks, including browser engines, payment systems, and identity providers, to be listed in app stores.
  • Give their own products, apps, or services preferential treatment or rank them higher than those of others.
  • Reuse private data collected during a service for the purposes of another service.
  • Establish unfair conditions for business users.

而 DSA 的部份則是針對網路上的非法內容處理:

The Digital Services Act (DSA), which requires platforms to do more to police the internet for illegal content, has also been approved by the European Parliament.

其中 DMA 的生效日看起來會在 2023 年年中生效?應該是 六個月加上六個月...

Once formally adopted, the Act, which takes the legal form of a Regulation, will enter into force 20 days after publication in the EU Official Journal and will apply six months later. The designated gatekeepers will have a maximum of six months after the designation decision by the Commission to ensure compliance with the obligations laid down in the Digital Markets Act.

而 DSA 至少要到 2024 年才有機會會實施:

Once adopted, the DSA will be directly applicable across the EU and will apply fifteen months or from 1 January 2024, whichever later, after entry into force.

歐盟的市場夠大,這個應該會帶來足夠大的衝擊...

微軟的 Outlook 系統會自動點擊信件內的連結

前幾天在 Hacker News Daily 上翻到的,微軟的 Outlook 系統 (雲端上的系統) 會自動點擊信件內的連結,導致一堆問題:「“Magic links” can end up in Bing search results — rendering them useless.」,在 Hacker News 上的討論也有很多受害者出來抱怨:「“Magic links” can end up in Bing search results, rendering them useless (medium.com/ryanbadger)」。

原文的標題寫的更批評,指控 Outlook 會把這些 link 丟到 Bing 裡面 index,這點還沒有看到確切的證據。

先回到連結被點擊的問題,照文章內引用的資料來看,看起來是 2017 年開始就有的情況:「Do any common email clients pre-fetch links rather than images?」。

As of Feb 2017 Outlook (https://outlook.live.com/) scans emails arriving in your inbox and it sends all found URLs to Bing, to be indexed by Bing crawler.

在 Hacker News 上的討論也提到了像是 one-time login email 的機制也會因此受到影響,被迫要用比較費工夫的方法讓使用者登入 (像是給使用者 one-time code 輸入,而不是點 link 就可以登入)。

先記起來,以後在設計時應該會遇到,要重新思考 threat model...

AWS 宣佈了 API 的 TLS 1.0/1.1 日落期

AWS 宣佈了 API 的 TLS 1.0/1.1 日落期:「TLS 1.2 to become the minimum TLS protocol level for all AWS API endpoints」。

公告裡提到是 2023/06/28:

This update means you will no longer be able to use TLS versions 1.0 and 1.1 with all AWS APIs in all AWS Regions by June 28, 2023.

TLS 1.0 目前還堪用的應該是 AES + CBC 類的 cipher,在正確實做 mitigation 下加減可以用:

對於像是 Java 6 環境這類很老舊的系統,如果真的無法升級的話,可以想到 workaround 的方法是透過 self-signed CA + TLS proxy 來幫忙把 TLS 1.0 的連線請求解開,重包成 TLS 1.2 的連線。

AWS 在同一區不同 AZ 頻寬費用的特別地方

剛好在處理 AWS 同一個 region 下不同 AZ 之間的傳輸費用,跟帳單互相比對,查了以後才發現跟想像中不一樣,這邊以 EC2 為例子,可以參考「Amazon EC2 On-Demand Pricing」這頁裡面的說明。

從 Internet 端進 AWS 的流量是不計費的:

Data Transfer IN To Amazon EC2 From Internet
All data transfer in $0.00 per GB

但從 AZ 進到另外一個 AZ 時,in 與 out 都要收費:

Data transferred "in" to and "out" from Amazon EC2, Amazon RDS, Amazon Redshift, Amazon DynamoDB Accelerator (DAX), and Amazon ElastiCache instances, Elastic Network Interfaces or VPC Peering connections across Availability Zones in the same AWS Region is charged at $0.01/GB in each direction.

所以直接用 US$0.01/GB 的計算是不夠的,得用 US$0.02/GB 來計算。

同樣的,如果是 Public IP 與 Elastic IP 也都是雙向收費,跨 VPC 也是雙向收費,所以都要用 US$0.02/GB 來算:

IPv4: Data transferred “in” to and “out” from public or Elastic IPv4 address is charged at $0.01/GB in each direction.
IPv6: Data transferred “in” to and “out” from an IPv6 address in a different VPC is charged at $0.01/GB in each direction.