  |
はてなキーワード:Open Sourceとは
Ruby Centralの乗っ取りをほめそやしてる奴がマットマレンウェッグにはこんなことを言っていたのだから、本当に人生というのはいついかなる時に誰がどういう立場に流れ着くか想像できなくて面白い
https://x.com/dhh/status/1845197490829889605
@dhh
Thisis totallycrazy.Like if the operators ofrubygems dot org just decided to expropriate theofficialRails gems, handover control to a new team, and lock thecore teamout ofit. We're in uncharted and dangerous territory foropen sourcenow. What asad sight.
https://anond.hatelabo.jp/20211029215655
Android初期の失敗はここに十分詳しく書かれているので、余計なおまけとしてAndroidとiPhone対立煽りで会話が噛み合わない原因について書く。
AndroidはAndroidOpen Source Project、略してAOSPと呼ばれる枠組みで開発されていて、誰でもソースコードをDLして改造することができるようになっている。
メーカによって改造されたAndroidがカーナビやTVやその他のデバイスに搭載されていることは、一般の人でもなんとなく知っていると思う。
ホーム画面には謎のキャラが我が物顔で走り回ることでユーザのタップを阻害し、d〇●・d●○という専門家にしか見分けがつかないアプリがプリプリプリプリ垂れ流されている。
頻繁に鳴る通知は使いもしないアンインストールもできないプリインアプリからのもので、肝心の自分が使っているアプリからの通知はそれに押し流される。
目的も定かではないOSへの改造によってデバイスのリソースは使い切られ、ユーザが使えるのはそのおこぼれでしかない。
そんなザマだからキャリアのAndroidの操作感は悪い。日本人がAndroidを投げ捨ててiPhoneに走るのも当然である。
なぜかといえば、iPhoneという競争相手がいる中で、Androidで金を稼いで飯を食う人たちによって日夜開発されているからである。
当然ながら出来が悪ければ稼ぎは少ない。実際に金を払って使用するエンドユーザではなくどこか壁に貼られたポスターとかを見ているキャリアと違って、彼らはユーザの反応をフィードバックして改善しているのである。使う人のことを考えた使いやすいものを作っているのである。
が繰り返される原因はここにある。
品質が一定水準を超えればあとは好みの問題なのだが、Android絶対否定派は魔改造されたキャリアのAndroidしか知らず、本来のAndroidを知らないのである。
「（キャリアの）Androidはダメ、iPhoneしか選択肢はない」
というのが正しい。
元記事のキャリアをやり玉に挙げたが、3大キャリアはどれもAndroidを「キャリアのAndroid」にしている。
生活費の内訳に通信費が必ず計上されるようになったこの時代において、金を払っているユーザに独自の改造を押し付けることで、日本人をどれだけ消耗させてきたことか。
というか普通に自分で触ればわかるだろ！！？！？！使いづらいんだよ！！！！！！！素のAndroid触ってごめんなさいしろ！！！！！！！！！！！！！！！
そのネットワークシステムの分散化を目指すことが発表され、再びSNSの分散化へ注目が集まっている。
Twitteris funding a smallindependent team of up tofiveopen source architects, engineers, and designers to develop anopen and decentralized standard for social media. The goalis forTwitter to ultimately be aclient of this standard. 🧵— jack 🌍🌏🌎 (@jack)December 11, 2019
この発表は日本語圏でもテック系を中心とした様々なWebメディアが取り上げており、日本でも注目されている。
Twitterのこの発表は驚くべきことだ。何故なら誰でも参加できるオープンなAPIプロトコルを整備するということなので、これまで開発・運用されてきたWebコミュニケーションサービスによって結論付けられたものと逆行した動きだからだ。
この結論はテック系で持て囃されているチャット系WebサービスSlackの例を出すのが理解しやすい。
一時期チャット系サービスではXMPPというオープンなプロトコルを採用するのが一般的だった。これはYahoo!メッセンジャーでもGoogle Talk(現ハングアウト)でもMSNメッセンジャーでもFacebookメッセンジャーでも採用されているプロトコルだ。
しかし、Googleはハングアウトの展開と同時にXMPPのサポートを辞めることを発表しXMPPの流れが変わった。
XMPPを採用しているとすべての会話ログをユーザは得ることができる。会話ログというのはコミュニケーションの歴史であり、ある時は強力な証拠となり、それは貴重な資産であることは明らかだ。
だからこそSlackはXMPPのサポートを辞めた。Slackの有料プランにある検索機能が意味をなさなくなるからだ。ユーザは別にSlackへ課金せずともXMPPを介して手元へ全ての会話ログを保存し検索できた。
ビジネスとして見るならばGoogleやSlackの判断は理解が可能であるし、だからこそ何度となく資金難が騒がれているTwitterが会話ログへ自由にアクセス可能なAPIプロトコルを整備しようとすることに一部の有識者は驚きを隠せないのである。
ある有識者たちは言う
「会話ログのマネタイズよりも通信コストを抑えたほうがTwitterとしては低コストとなる試算が出たのではないか」
「分散化をするとして現在Twitterの収益の中心である広告配信システムはどうするのか」
「Twitterが握っているシェアを分散化するとは考えにくい。Twitterの言う分散化とはメッシュ型分散化ではなくTwitterをトップとするツリー型分散化なのではないか」
「Twitterは言論の管理に疲れ果て、各国の分散Twitterサーバ管理者へ言論の管理を任せるのではないか」
様々な憶測が流れ、更にはジャック・ドーシーはブロックチェーンにまで言及したため仮想通貨界隈の魑魅魍魎までもが反応してしまうという事態へ至っている。
SNS分散化において最も理解ある集団と言えば間違いなくActivityPubプロトコル界隈だろう。
より理解しやすい表現をするならば、こう言えば良い「Mastodon界隈」だと。
ここに来てドワンゴやpixivがマネタイズへ失敗し、Mastodonブームの際にインターネットユーザからTwitterとの違いがわからないと一蹴されたMastodon界隈が、Twitterの分散化方針の発表により最大の理解を示すというのは何ともドラマティックである。
正確にはMastodonがサーバ間通信へ利用しているプロトコルがActivityPubであり、ActivityPubを採用しているのはMastodonだけでなく他にも数多くの分散SNSが存在しており、ActivityPubを採用している分散SNSは相互に通信可能なので、Mastodonをも含んだActivityPub界隈はTwitterの分散化へ興味深く関心を寄せている。
それは「分散Twitterの登場を待つ」「既にあるActivityPubへ投資する」の二択である。
現在、日本語圏でSNSの主流になっているTwitterの分散化方針は示された。この方向性は数年後はわからないが数カ月で変わるような方針ではないだろう。
なぜ数カ月で変わらないのかと言えば、Twitterは既にバックエンド開発でBitTorrentを用いたP2P分散化による運用をしているからである。つまりTwitterにはもう既にある程度のネットワーク分散化のノウハウが存在するのだ。
分散化のノウハウがある中でTwitterはユーザが体験するサービスまでも含めて、わざわざ専門チームまで立ち上げつつ、分散化の方針を示したのだ。これは本気度が高くなかなか変わりようがない。
問題はTwitterがどのような分散化をするのか現状では一切わからないことである。
Mastodonのようにセルフで分散Twitterサーバを立ち上げられるのか、許可制の代理店方式か、単にAPIを利用できるのか、全くわからない。
しかも、先例であるActivityPubは主にITエンジニアリング界隈からの評価が既に定着しており、分散SNSの開発速度は現状で間違いなくActivityPubの方が速い。来年の仕事始め2020/1/6からActivityPubでSNS開発を始めようと言えば始められるくらいに速い。
IT業界、特にWeb界隈は移り変わりが速く、しかも先駆者が強い傾向があるのは明白だ。分散Twitterを待ってActivityPubがデファクトスタンダードへのし上がったときは目も当てられない。
しかし、ActivityPubがデファクトスタンダードになるかはわからない。シェアをどちらがより多く獲得するかは神のみぞ知るというところだ。
わかるのは2020年以降SNSの再編が始まるということだけだ。
中国は習近平体制以降、西側の技術を用いて西側用へ最適化された製品やサービスを西側へ輸出することで経済成長してきた。
それと同時に西側で生まれたイノベーション企業や製品・サービスについて、その当初は中国内でビジネスをすることを静観するが、同種の企業や製品・サービスが中国企業として成立すると西側の企業や製品・サービスを規制して中国資本の自国産業を守ってきた。
米国はドナルド・トランプ体制以降にこれらが非常に強く問題視され、中国携帯電話メーカーのZTEに端を発し中国へ規制を強める動きが本格化した。
前述した通り中国は同種の企業や製品・サービスが中国企業として成立すると西側の企業や製品・サービスを規制して中国資本の国内産業を守るため、Googleは中国内で度々規制の憂き目に遭っていた。
Googleが中国政府へ不満をつのらせていたのは明白で、米国法を遵守するとともに報復的な意図があったと推測されている。
ただし、前述したようにGoogleへ先に手を出したのは中国政府なので、一部で語られている「Googleは米国政府の言いなり」という様な意見は少々弱い。Googleには同調する十分な理由があった。
当然ながらファーウェイは中国政府による海外企業規制に助けられていた面もあるので、完全な被害者と判断するかどうかは意見がわかれるところだろう。
スマートフォン向け基本ソフトウェア(OS)のAndroidOSはその大部分が誰しもが無料で利用できるオープンソースなソフトウェアだが、AndroidOSと名乗るにはGoogleが定めるライセンスに則らなければならない。
そのライセンス取得にはGoogleMobile Service(GMS)の工場出荷時状態からのインストールが必須だが、このGMSの大部分は非公開であるクローズドソフトウェアであり、GMSはGoogleの承認がなければインストールすることが正式にはできない。
GMSはAndroidアプリ開発において便利な機能がまとまっており、Androidアプリ開発者の開発労力を低減させるため、人気がある高機能で高品質のAndroidアプリではGMSの機能が当たり前のように採用されており、AndroidOSでないと人気のAndroidアプリが正常に動作しなくなる可能性が高い。
ファーウェイがAndroidOSを使えなくなるとはどういうことか？という疑問の答えの1つが「人気のAndroidアプリが使えなくなる」というものだ。
その他にもGoogleが正式に認証するAndroidOS向けのソフトウェア情報やセキュリティ情報、携帯電話本体のハードウェア開発に関わる情報も提供されなくなるので、ユーザーとしては便利に安全に使い続けることが困難になる。
ファーウェイがスマートフォンを製造できなくなる可能性は非常に低いと見られている。
それは前述したAndroidOSはオープンソースソフトウェアという部分が関わっており、AndroidOSのオープンソース部分をまとめたAndroidOpen Source Project(AOSP)という存在があるためファーウェイがスマートフォンを製造できなくなることはないと思われる。
AOSPは様々なスマートフォン向けOS開発へ応用されており、一部報道でファーウェイが独自OSを開発するという情報が流れているが、ファーウェイはAOSPを利用して独自OSを開発すると思われる。
AOSPベースのスマートフォン向けOSはライセンスの兼ね合いでAndroidOSと名乗れないだけで、AOSPはOSの振る舞いとしては事実上AndroidOSと大きな差異はない。
ただし、問題となるのはAOSPへは前述したGMSが含まれないので、ファーウェイが開発するAOSPベースの独自OSでは人気のAndroidアプリが正常に動作しない可能性があるので、ファーウェイ製スマートフォンはコストパフォーマンスの高い人気のAndroidアプリが正常に動かないスマートフォンに成り下がるかも知れないのが問題だ。
ARM社はCPUアーキテクチャと呼ばれる、現在のコンピュータやスマートフォンの機械的中核となっているCPUの設計図を考え出している会社だ。
そして現在のスマートフォン向けCPUの大半がARMが考え出したCPUアーキテクチャを採用しており、CPU製造メーカーはARMへライセンス料を支払ってCPUを製造している。
ファーウェイのスマートフォンのCPUであるKirinシリーズCPUは、ファーウェイ傘下のハイシリコン社が製造しているが、このハイシリコンが製造しているKirinシリーズCPUはARMのCPUアーキテクチャを採用している。
つまり、ハイシリコンはファーウェイへKirinシリーズCPUを製造・供給できなくなっており、ファーウェイのスマートフォン製造が窮地に陥っているということだ。
ただし、CPUの調達価格は高くなってしまうがハイシリコン以外の西側の会社からCPUを調達したり、ハイシリコンからKirinシリーズCPUを例えばシンガポールで作った資本関係のない企業あたりへ権利移転して、ファーウェイが輸入するという3店方式のような方法がないわけではないので、直ちにファーウェイのスマートフォン製造が止まることはないだろう。
そもそもSDメモリーカードとは米国へ本部を置く非営利団体SD Association(SDA)が規格を策定しているメモリーカードだ。
SDAは米国へ本部を置いているため法律も米国法の影響下にありSDメモリーカードに関わる技術情報提供やライセンス料の受け取りなどに関して米中貿易摩擦の煽りを受けた形だ。
そして、ファーウェイがSDメモリーカードを使えなくなるのか？という疑問についてだが「SDメモリーカードは使えなくなるがMulti Media Card互換メモリーカードは使える」という回答になる。
この辺りに詳しくない者へ説明は非常に困難を極めるのだが、メモリーカードはこれまで様々な形式や規格が作られてきた。その中にMulti Media Card(MMC)と呼ばれるメモリーカードがある。
このMMCはライセンス料フリーで利用することが可能で、実は形状がSDメモリーカードと全くの同一である。
そして、MMCとSDメモリーカードの歴史的経緯でSDカードはMMCと一部の機能的互換性を持つという側面がある。
そのためライセンス料の支払いが難しいオープンソースかつコミュニティベースで開発されている一部のUNIXOSや一部のLinuxOSではMMCに関しての例外的実装としてMMC互換メモリーカードが動作するのだ。
そのためファーウェイはSDメモリーカードが使えなくなってもMMC互換メモリーカードは使い続けることができるという見方が強い。
再度言う、SDメモリーカードは使えないがMMC互換メモリーカードは使えるのだ。
前述したように、中国の経済成長は西側の技術を用いて西側用へ最適化された製品やサービスを西側へ輸出することで経済成長してきたものであり、その経済成長の推進力は西側の知財によるところにある。
今回の中国はその推進力たる知財を人質に取られている状況であり、推進力を奪われれば中国経済が下降線を辿ってしまうのは難しい想像ではない。
そしてまた「中国を刺激するとGoogleに変わってBaidu、Amazonに変わってAlibaba、そういった中国発サービスが世界を取る」というような意見が稀に見られるが、今まで国際競争に晒されていなかったサービスが来年いきなり世界を取ることは有り得ないので、今回の米中貿易摩擦で懸念する問題ではない。
もちろん10年後や20年後はわからない。だがしかし、今現在の中国発サービスがGoogleやAmazonと対抗できるまで成長するには中国は西洋の知財がどうしても今現在必要なのである。
さらに言えば、中国は簡体字教育を推し進め過ぎていて既存のサービスは簡体字にしか対応していないサービスばかりであり直ぐに多言語化したり、現地法規やユーザー特性に合わせたサービスの微調整を直ぐにするというのは全く現実的じゃない。
例えば、簡体字で話す微博(中国のマイクロブログSNS)ユーザーがいきなり多言語に馴染めるとは思えない。というかむしろ中国在住人以外が微博を利用する理由が今のところない。
何故ならば当時の日本は海外企業を特に規制などは殆どしていなかったからだ。
当時はまだ自由貿易協定などが世界でも稀で、どこの国も輸出入へ関税を掛け自国産業を守ろうのすることが通例だったからだ。
そういった意味で当時の日本は海外企業へ対してあからさまな政治的意図のある摘発などをもって規制することは殆どしていなかった。
今回の米中貿易摩擦は価格の安さから起きた貿易摩擦とは違うと言える。
前述した通りそもそもの発端が中国政府による海外企業の冷遇なので中国は米国へ折れるしかないというのは米中双方が間違いなく理解している。
どこの国も自国企業の優遇はしている。しかしあからさまな冷遇をするのは可能な限り控えているのが通例だ(インフラ関連企業などで海外資本比率に規制を設けるなどの冷遇はどこの国もしている)。
つまり、決着は中国内における海外企業への規制緩和しかないのである。
中国側が簡単に負けを認めない理由が自国産業を守るためにどこまで海外企業への規制を緩和するか？というのを決めかねているというただ1点であり、この判断を誤ると中国バブルはすでにもう弾けていると言われている中で自国産業が急速に萎んでしまうから決めにくいのだ。
もちろん、そのようなことが起きれば習近平体制が揺らぐのは明白であり、中国政府としては非常に難しい判断をしなければならない状況だ。
西側で生まれたイノベーション企業や製品・サービスについて、その当初は中国内でビジネスをすることを静観するという習近平体制の今までの状況から考えるに、中国政府が取る選択は時間稼ぎである可能性が高い。
可能な限り時間を稼いで自国産業が可能な限り最小限のダメージで済むような方策を取ろうとしているところだろう。
ただ、米国もバカではないので、その中国の動きを察して段階的に規制強化をし圧力を強め、中国が持つ有限の時間を浪費させようとしている。
あまりにも中国側の時間稼ぎが上手く行き過ぎるとファーウェイは世界のスマートフォントップメーカーから転落する可能性がある。
しかしながらファーウェイが倒産するところまでは行かず、その前に今回の米中貿易摩擦は解決すると踏んでいる。
つまり中国側が白旗を揚げて海外企業への規制を緩和するということだ。
その後ファーウェイが今のように復活するというのは五分五分だと見ているが、ファーウェイが中堅やそれ以下へ成り下がっても、次はハイセンスかシャオミあたりがスマートフォンメーカーとして世界で注目を浴びるのではないか？と予想している。
オッポやヴィーヴォはあまりにも米中貿易摩擦が長期化すると煽りを食らって会社が傾いてしまうのではないか？とは心配になる。
最後に、中国はファーウェイが倒れても第2第3の中国企業がポストファーウェイとして候補に挙げられる程度にはまだまだ余力があるのだと記してこのエントリを終えたいと思う。
自分でも何を言っているのかわかってない 、そもそもGNU以前にフリーソフトウェアとオープンソースの違いを理解していなそうって感想
なお、GNUの中心人物ストールマンについてははwiki 読むだけでおおよそお分かりいただけると思う
MITに在籍しているが無給である。定住のための住居を持っていない。彼は、この生活について「私はいつも安上がりな生活をしてきた……つまり学生みたいにね。私はそういう生活が好きなんだ。そういう生活なら、カネの言いなりになる必要がないからね」
WEBブラウザは非推奨
「個人的な理由」から、GNUやFSFの自分のページかそれに関連するページ以外は自分のコンピューターから直接ブラウズすることはないと述べている。
▼WhyOpen Source misses thepoint ofFree Software
https://www.gnu.org/philosophy/open-source-misses-the-point.ja.html
元増田の苦悩は、日本語では、断片的なTipやリファレンスはあっても、
市販されている書籍のような情報がインターネットでは手に入らないということに原因があると思う。
英語だと、市販されている本がまるまるネットで公開されていることがある。
例えば、
SICPhttp://mitpress.mit.edu/sicp/
Real WorldHaskellhttp://book.realworldhaskell.org/read/
PracticalCommon Lisphttp://gigamonkeys.com/book/
How to design programshttp://www.htdp.org/
Thinking inC++ 2nd Editionhttp://www.mindview.net/Books/TICPP/ThinkingInCPP2e.html
Thinking inJava,3rd Editionhttp://www.mindview.net/Books/TIJ/
GNU Autoconf, Automake, and Libtoolhttp://sources.redhat.com/autobook/
Managing Projects withGNUMake, Third Editionhttp://oreilly.com/catalog/make3/book/index.csp
Dive IntoPythonhttp://www.diveintopython.org/
ProgrammingRuby The Pragmatic Programmer's Guide 1st editionhttp://ruby-doc.org/docs/ProgrammingRuby/
OnLisphttp://www.paulgraham.com/onlisp.html
TheArt ofUnix Programminghttp://www.faqs.org/docs/artu/
BRUCE PERENS’OPEN SOURCE SERIEShttp://www.informit.com/promotions/promotion.aspx?promo=135563
O'ReillyOpen Books Projecthttp://oreilly.com/openbook/
Creating Applications withMozillahttp://books.mozdev.org/
