【科技新聞】我想要一部 iPhone Mini 尺寸的 Android 手機

我是一個長期使用小型手機的 Android 用戶。但在 Pixel 5 之後，我一直沒能找到合適的小型 Android 替代品。 Pixel 6 是巨大的，而 Pixel 7 看起來也注定是巨大的。情況變得如此糟糕，以至於我不得不使用 iPhone Mini，等待我的時間，並拼命希望一些 Android OEM 能夠挺身而出。

但越來越清楚的是，小型高端手機不在路線圖上。所以我決定自己動手。我在https://smallandroidphone.com的目標是將其他小型手機的粉絲聚集在一起，並向 Google/Samsung/Anyone 施加壓力，讓他們考慮製造一款小型手機。

我擁有一套非常具體的技能和行業聯繫，這些都是我在硬件行業的長期職業生涯中獲得的（我的第一家創業公司是 Pebble）。我會將它們用於我們共同的追求，以獲得完美的小型 Android 手機。如果沒有其他人建造一個，並且有足夠多的人註冊……也許我將被迫自己製作。

如果您想要一款小型高級 Android 手機，這可能是您（曾經？）幫助恢復我們喜愛的手機類別的最後機會。

嗨，埃里克，我自己是一個硬件創業公司（我們的道路已經交叉），我自己的“非常具體的技能”在智能手機大公司和智能手機初創公司得到了磨練。 OSOM、Essential、HTC、三星、蘋果。我設計並製造了很多手機。我現在正在建一個。我認為這是一項崇高的努力，我個人也更喜歡袖珍手機，但我認為你前進的道路上有幾乎無法克服的障礙。

– 1. 供應鏈/零部件研發 –

您將非常非常難以採購帶有打孔器的預先存在的、高質量、非獨家的 5.4" 顯示器。如果您最終以自己的初創公司的身份這樣做，那麼您將首先嘗試購買現成的零件以降低成本。但是您想要的顯示根本不在主要組件製造商的任何發展路線圖上。這個行業有自己的動力，組件供應商也一直在關注趨勢線，所以他們是建築越來越大。

如果您在目錄中找不到您想要的屏幕，那麼您必須花錢請人建造它。令人信服的京東方等。你的手機銷量不足以支付研發成本是不太可能的，所以準備好在 NRE 上支付數百萬美元以使其值得他們花時間（可能仍然不值得），並等待一年讓他們啟動晶圓廠.因此，大約 500 萬美元和 9-18 個月後你就有了展示。

– 2. 大玩家不感興趣，不是不知情-

大公司淹沒在市場數據中。他們知道有些人真的非常想要小手機。但這是一個他們故意忽略的長尾機會，需要手機的人即使不情願也會買東西。我一直在開會，小小的電話宣傳無濟於事。

此外，我有點驚訝您希望在您之前嘗試影響您的收購方的經驗之後，在線請願會奏效。我想你看到了 Fitbit / Google 的內部以及如何做出決定……

“匹配 iPhone 13 Mini 的尺寸和設計”

因此，從各方面來看，iPhone mini 的銷售速度都非常緩慢。

https://www.macrumors.com/2022/04/21/iphone-13-mini-unpopula…

為什麼這種外形尺寸會在 Android 領域取得成功？

—

我一直在科技網站上看到這些表情包：“哦，手機太大了，我只想要簡單的東西”。這是一種有效的情緒，我認為基本上沒有普通消費者有這種情緒。對於很多人來說，手機是他們的主要計算設備，所以大屏幕在那裡很好。更大的手機允許更多的電池容量。老年人喜歡它們，因為您可以使用屏幕縮放功能來真正放大文本大小，而不會使有效視口太小。

而且……人們只是喜歡大的東西。我知道這很簡單而且有點居高臨下，但看看 SUV 和卡車的銷售情況。

考慮以下場景：前一分鐘你很高興和滿足，認為下一分鐘你的生活會很好。你有幾分鐘的時間，所以你登錄 Facebook 並開始滾動……

首先，您注意到一位朋友的帖子說她接受了理想的工作。

然後你讀到一個同事過於政治化的咆哮。

您繼續瀏覽並觀看您的鄰居享受美妙熱帶假期的視頻。

現在你表弟上傳了一張前後照片，讓你想一輩子都藏起來。

接下來你知道的是，你正在懷疑你的職業，被政治激怒，想知道為什麼你買不起旅行，並研究你的下一個飲食。

社交媒體不過是過山車，

對我來說，我發現社交媒體不會直接影響我的幸福和/或焦慮程度。它的作用是幾乎不知不覺地佔用了我很多時間——為其他更有意義的活動留下更少的時間。這讓我覺得我每天都沒有時間，這反過來又會引起焦慮感。

由於宗教原因（從黎明到黃昏），我每年禁食一個月。在這段時間裡，我從社交媒體（主要是電報、推特）上禁食。

大約一周後，我在表面上感到焦慮，但在大約 2 週後我感覺很平靜，我感覺好多了。整整一個月後，當我再次登錄推特時，我真的能感覺到精神上的轉變。幾乎就像被拖回它。這並不令人愉快。我對這些發現並不感到驚訝。

一切都在某處存在正確性問題。 Julia 發布了 LLVM 的完整補丁版本，以修復數值方法中的正確性錯誤。它有自己的軟件端 FMA 等實現，因為 Windows 的 FMA 實現不正確： https ://github.com/JuliaLang/julia/pull/43530。核心 Julia 開發人員現在是 libuv 之類的維護者，因為那裡需要修復很多東西。所以從這三點來看，這清楚地指出了 Python、R 等代碼在 Julia 不正確的情況下都是不正確的。

我認為 Julia 的有趣之處在於，因為代碼都是 Julia，所以很容易在那裡挖掘並發現潛在的錯誤。可以使用 @edit sum(1:5) 訪問標準庫函數，然後就可以破解了。查看代碼越容易，就越容易發現問題。這就是為什麼 Julia 的開發者與用戶的比例如此之高。這當然有利也有弊。它使開發過程民主化，但這意味著沒有大量開發經驗（加上 Fortran 或 C 知識）的人不會被排除在貢獻之外。是好還是壞？就我個人而言，我認為從長遠來看它是好的，但可能會遇到一些問題。

順便說一句，作者強調“for i in 1:length(A)”。我同意，代碼永遠不應該那樣做。它應該是`eachindex(A)`。一般來說，應該使用為基於迭代器的任意索引而設計的迭代器。在任何語言中都是如此，儘管總會有一些新手用它來編寫代碼（和文檔）。即使是不傾向於使用 Array 以外的數組的有經驗的人也傾向於這樣做。這是一個有趣的問題，因為編碼風格問題會持續存在：在 GPU 和 OffsetArrays 之前，明確使用 1-base 不是問題，但是這樣的循環代碼可以訓練下一代，因此更多人使用它。最後，真正知道處理這些情況的人往往是使用這些情況的人，就像以 ARM 安全的風格編寫的人往往是使用 ARM 的人一樣。有人應該只運行一個機器人，為每次出現這種情況（尤其是在 Base 中）打開一個 PR，因為這會改變每個人學習的來源並徹底改變風格。

我是 Julia 社區的長期成員，很久以前就與作者討論過這些問題——但沒有對帖子提供反饋。首先讓我聲明，Yuri 是一個偉大的人，是社區的重要成員。他突破了語言的界限，並在他那個時代製作了一些非常好的包。他的擔憂是真實的，應該在這種情況下得到尊重和討論。

另外，讓我說，遇到這些類型的錯誤是我沒有經歷過的。但是，我對庫的使用和花哨的構圖往往非常保守。

如果我在編程語言理論和實現方面有更多經驗，也許我會有一個更好的名字來描述所描述問題的根源。我的嘗試是稱之為“類型無政府狀態”。在我看來，沒有明確的方法來分配正確性的責任。對於帖子中使用的數組，是“sum”函數的實現者（沒有類型簽名，應該是）還是數據結構的實現者的錯？老實說，我不確定。但隨著 Julia 憑藉其類型系統和多重調度打破新聞領域，這在很大程度上可能是一個懸而未決的問題。