  |
はてなキーワード:デファクトとは
昔は夫婦別姓に賛成だった。
「選択肢があることは良いことだ」「誰にも迷惑かけない自由なんだから」という、まぁよくあるリベラルっぽいノリで。
でも、最近になって、ふと「これはちょっと違うかもしれない」と思うようになった。
いや、別に誰かが別姓にしたいと言うこと自体を否定するつもりはない。実際、戸籍の手続きや名前の変更が面倒くさいというのは理解できるし、そういう不便さは制度の整備である程度解消できるものだと思ってる。問題の本質はそこじゃない。
「選択的」って、言葉だけ聞けばすごく良い感じがするじゃないか。
でも、その「選択肢」が社会的な圧力のトリガーになるなら、それって本当に自由か？と思う。
ここ数年、選択的夫婦別姓に否定的な意見を言うと、まるで人間性に問題があるかのような扱いを受ける。
保守的だの、頭が固いだの、時には「頭悪そう」とか「昭和脳」だの。
ああ、なるほど。選択肢が与えられた結果、選ばなかった側が吊し上げられるのかと。
で、これが怖いのは「選択できる」とされているはずなのに、結局は「別姓を選ばないと非進歩的だ」という空気がじわじわと支配してくるところ。
制度上は自由、でも社会的には強制。そういう「自由」は、自由じゃない。
現制度においても、どちらの姓を選択するかという自由はあるが、夫側の姓を採用することがデファクトで強制的であるという点が問題のはずだ。
結局のところ、社会的な要請や機運が高まったりしないといけないと、このような変更はハードルが高いのだろう。
正直に言えば、最初は賛成していた自分が、いつの間にか「同姓を選んだら何か言われるかもしれない」という圧力にストレスを感じて、気づいたら立場を変えていた。
なんというか、リベラルの皮をかぶった全体主義って、こういうのを言うんじゃないかと思った。
「でも今は同姓を強制されてる人がストレスなんだから、反対派も同じぐらいストレスを感じれば平等だよね」みたいな態度が透けて見えるのもキツい。
加えて、こういう制度が通ったあとに、「夫婦」だけじゃなくて「親子」や「戸籍制度そのもの」とか、適用範囲がどんどん拡大していく流れになるのでは？という懸念もある。
最初は「選択的」だったのに、気づいたら何も選べない社会になっていくのだろう。わりと静かに、でも確実に起こる。
夫婦別姓を推す人たちが全員そうだとは言わない。けど、「ああ、これは賛成することが“善”で、反対は“悪”とされる世界だな」と思ってしまった時点で、ぼくはもうその運動に乗る気にはなれなくなってしまった。
TypeScriptベースのフルスタックフレームワークが増えてきたね。
フロントエンドもバックエンドもTypeScript実装できてとっても嬉しいね。
しかし、バックエンドとフロントエンドと密結合な事実はとても怖いんだ。
フロントエンドの成長速度はとても早い。
React がデファクトになりつつあるが、 Reactベースのフレームワークは群雄割拠だ。
むしろ、 React を排する新しい技術も出てくるくらいの戦国時代なんだ。
フレームワークを選定時、各言語でも多くて3つ程度に絞られるのではないか。
成熟しつつあるバックエンドと成長中のフロントエンドを一緒のライブラリで運用すること。とても怖い。
特にTypeScript はフロントエンドを祖に持つので、フロントエンドの事情がフレームワークの開発ロードマップの意思決定に強い影響を与える。
フロントエンドに破壊的変更が加わった時、バックエンド側にも影響を与える。
他フレームワークにおけるフロントエンドの実装について、あのRuby on Rails ですらバージョン上がるごとにフロントエンドに破壊的な変更が入る。
まぁView の取り扱いの黒魔術は魔境だから極力触りたくないが、バックエンドの側面のみを切り出したAPIモードであれば爆速の開発体験とテスト機構により信頼性が高い。
それなら、フロントエンドとバックエンドを別々に管理にしたい。
いや俺は、TypeScript のアプリケーションが嫌いなのかもしれない。
フォルダ設計も、テスト機能の整備も、ORMの設定も、最初から設定する必要があるから。面倒なんだ。
どうせTypeScriptアプリケーションの設計は設計者の自己満足になる。
そして、設計者は運用の責任を全うせずいなくなる。ドキュメントすら残さない。
それなら、規約で縛るフレームワークの方が、後任がキャッチアップしやすい。
設計者が知識を普及もしくはドキュメントを整備して知識の移転に心を砕いてくれれば、設計方針を汲み取りやすいのだが、そうしてる設計者はいるのだろうか。
後任のために、せめてものドキュメンテーションを心がける。
あれはNTTのうんこ通信網をどうにかすると言うだけの技術で、ほとんど意味ないからだよ。
NTTは光だけでスイッチングするから低遅延で高速だと言うだろ？
でもそんなことをせずに実現しているところがある。
NTTなどのオールド通信会社のネットワークは、電話の通信網を基本にしているから、細かい基地局と基地局の間を回線でつなぐという構造をしている。
そのため、IP通信になった今でも、その通信網を一つ一つパケットがルーティングされて流れていくと言う構造になっている。
だから、低遅延にするならオールフォトニクスにして光のままでルーティングする必要がある。
けど、それって昔ながらの古いネットワークだから必要なだけだって、もっとシンプルなネットワークだったらいらないよね？
巨大なデータセンター間を専用の光回線でつなぐと言う商売をやっている専門の通信会社は、そんな面倒くさいネットワークではなく、シンプルに両端にのみ光電変換をする装置を配置する構造にすることによって、IOWNとか言わんでも高性能低遅延低消費電力のネットワークを構築しているわけです。だから、本質的にAPNでございだとか、マルチオーケストレータでございますとか言わなくても、いらないんですよねそんなの。
データセンターの中の通信技術なら既にIOWNより優れたものがある。
インターネットのトラフィックは平等にルーティングされているのではなく非常に偏っているのは周知の事実であり、高性能なネットワークが必要なのはここなのでここだけにシンプルなネットワークを適用すればIOWNなんていらないである。
今は親方電電虫が言ってるからお付き合いでやってる企業は多いが、温度差が激しい。もうすがる先がここしかないところはやっているが、そうでない所は冷めた目で見てる。
NTTが自社の環境こそがデファクトだと思い込んで、それに対応させるだけのガラパゴスな技術に名前を付けて出してしまった、それに取り巻きがやんややんやの拍手をしていると言うのが今のIOWNだよ。ISDNと同じ。
オープンソースだと、無償の名の下に自分に都合の良いものを世の中に広げて、別の稼ぎの足がかりにしたりする。
つまり例えば自社製品向けの潜在的市場を作ってたりするんだよ。
Android なんかが良い例だ。あれも無償でオープンソースのOS（一部無償プロプラ含む）をバラまいて、自社のアプリストアやOSの仕様を通じて、アプリストア税を取ったりOSのログから効果的な広告を出せるようにしてより高額な広告を売ってる。他社がアプリストアを出しても勝てないだろ？その理由はAndroid が先にOS ごと無償でデファクトになってしまってるからだ。
ああいう会社はいわゆる三段論法的な考えで、「無償行為AでBという環境を作る」「Bの環境で自社製品Cを売れば儲かる」と考えられるから無償行為Aをすることができる。
逆に日本の企業は、ほとんどが「製品Aを売ったら儲かる」というビジネス以外できない企業が多すぎないか？と思ってる。そういう訳なのでオレは Abema がやってることはやる価値があると思うぞ。
MS OfficeやPhotoshopからデファクトを奪うレベルのオープンソースソフトが未だに出てこないのはどういうこと？
LibreOfficeにしろGIMPにしろ、いつまで経っても業務でまともに使えるレベルにならないし。
あとGUIも、オープンソースにおける決定版がこれまた待てど暮らせど出てこない。
てかOSSって、便利である以上に複雑怪奇なUIで、ユーザを苦しめるソフトばっかり作るよね。
(Perl、sendmail、bind、TeX、gnuplotなどなど挙げてったらキリがない)
なんでユーザの使い勝手というか、そこら辺のデザインがこうも蔑ろにされるのか意味がわからん。
結局、viとemacsどっちがいいかという、傍から見たらきのこたけのこ未満のしょーもないレベルで使い勝手を言い争っていた頃から、OSS界隈は何も変わっちゃいないと。
学校ではiPadを使ってるんだけどどのパソコンを与えるかに悩んでる。
まずはWindows。なんだかんだいってまだデファクトはWindowsだよね。ただ自分が使ってないし、Excelも買い与える予定ない。必要があればSpreadSheet使わせる。あんまり直近で良いことはなさそう。
Mac。自分も使ってる。ただ高いよね。あと、何に使うんだ？ほとんどブラウザしか使わないのでは？なにかに興味を持ったら選択肢は広がるか。でもそれ言ったらWindowsも同じか
CheomeBook。大体のことはこれで済む気がする。でもいろんなことやりたくなっても選択肢が狭いよね。プログラミングとか、動画編集とか？
Linux。やりたいことはググって自分で環境構築させるスパルタ教育。うちの子はそこまでやらないとおもうからなしかな。
とりあえずChromeBookで様子見なのかなぁ。
平均がよ、平均が。
もちろん人それぞれよ。
まず驚いたのは、店員のお姉さん達が俺との会話で「sir」を付けてくれるの。
敬意を持った言葉遣いをしてくれる。
もうこの時点で他の料理屋では考えられないよね。
裏を返せばちょっと浮いた世間ズレした店とも言えるんだが、メイド喫茶のロールプレイみたいなもんで、その言葉遣いで「あっ俺日本に来たわ」って感じがする。
そんで注文してしばらくしたら料理が運ばれてきた。
「Excuse me, sirrrrrr」って。
後ろから料理が運ばれてきたからね、俺がびっくりしないようにちゃんと断り入れながら運んできてくれた訳だ。
これも感動よね。他の店でそんな気遣いないよ？チョベリグよもう。
そんで、極めつけには「Is thateverything, sir?」と、ちゃんと全部の料理が来てるか確認が飛んできた。
なにそれ怖い。ここただの料理屋ですよね。ボク独りで昼飯食いに来ただけですけど。
もうどうかしてるんじゃない？良い意味で。
ゴトンと皿置かれて、なーんも言わずがデファクト。もう慣れたわ。
まあ確かに雑に「Have a goodone.」とか言ってくれる店はあるけど、アジア料理店はガチのマジで無言。
React.jsを使うと、Node.jsの学習って無駄になるんでしょうか？
例えば、何か新しい機能を追加したい、となったらNodeのライブラリじゃなくて、reactのライブラリを使いますよね？ もしくは普通にJSで書くとか（？）
無駄にはなりません。
まず、「Node.js、Deno」はサーバー･サイドJavaScript、「React」はクライアント･サイドJavaScript(つまりブラウザ側)なので、役割分担が違います。
ただし日本のプロの世界では「Node.js、Deno」はイマイチ人気は無いので、プロを目指すなら無駄になるでしょう。
そうですが、Next.jsは人気は無いので、Reactを強く推奨します。
Google Trendsは、あくまでもキーワードの人気度であり、本体の人気度ではありませんが、人々の関心度と考えて良いでしょう。
https://trends.google.co.jp/trends/explore?date=2013-06-01%202022-06-01&q=jQuery,React,Vue,Angular
オープンソースソフトウェア(OSS)は、ソフトウェア開発でも長い歴史を持ち、なおかつかなり個性的な特徴がある。
ざっと挙げるなら
こうしたコミュニティから生まれてきたソフトを最も多用しているのは、他ならぬWeb系だろう。
サーバサイドプログラミングが中心になることから、Linuxを触る機会も他の開発系に比べて格段に多いだろうし。
結果、「UNIXの哲学」とかGNUの歴史とか全く意識せずとも、こうした活動を通じていつの間にかOSSのエッセンスを身に着けた人が、Web系には少なからずいそう。
その意味では、OSSがどういうわけか今のWeb系の礎になってしまったという意味で、タイトルに書いた通りになっているのかなーと。
あーーーほ
暗号化しても平分で持ってても、ようはDBにアクセスされてる時点でハッキングされてるわけ。
そんなときに暗号化しておくともしかしたらパスワード悪用される前に時間稼ぎができるかもしれん。
そして強力なハッシュ+ソルト+ストレッチングするっていう、「現代のデファクトスタンダード」な運用なら一番その時間稼ぎができるわけ。
そもそもDBが完全無欠に守れる自身があるなら平分で保存でもいいわけなんだけど、んなわけねーだろ。万が一流出したときのダメージコントロールのためにハッシュカルル訳？ソコンところ理解できてないから、
安全化どうか？みたいなアホな観点でしかものを語れないわけよ。アホたれ
だからパスワードハッシュおもらししたら、直ちにおもらししたことを報告して、その間にハッシュでパスワード解読時間を稼いでる間に、おもらしされたユーザーは万が一他のサービスで同じパスワード使ってるとかいうアホなことしてたら、対応するわけよ。わかる？
まあでも、そもそも他のサービスでもパスワード流用してるタイプのアホは、そんな事しねーよみたいな気持ちもあるな。
そしたらそもそも、平文でほぞんしててもいいような気がしてきたけど、ハッシュで管理してて、アカウントの数が何千万とかあればだよ。
自分のアカウントのパスワードの解読まで一生かかっても作業が回ってこない可能性もあるので、事実上安全っちゃ安全かもしれない。
でもハッキング対象のアカウントが決め打ちでキメられてるなら、スパコンとか使って意地でも特定アカウントのパスワードを割り出すみたいな作業は可能かもれない。
だからってそれは、平文で保存したり、暗号化していい理由には並んと思ってて、
完全に安全にパスワードを管理することは無理だけど、限りなく安全に近い形で取り扱うことのできるハッシュ化(当たり前だけどそこには強力であること+個別のソルと使うこと+ストレッチングが含まれる)をするのは当然であって、
ハッシュが安全かどうかとか言ってる時点で、そもそもの何が問題で、なぜハッシュが良いとされているのか、なぜハッシュがデファクトで使われているのかってのをまるで理解してないと思う
そうやって表面だけの技術情報をなぞっただけでわかったような気持ちで文章書いてる時点で、自分の知識に対する過剰な自信と、慢心が溢れ出してて嫌いです
オープンソースcURLの作者、某大企業から「24時間以内にこの質問に答えるように」との無礼なメールを受け取る － Publickey について思ったことをつらつらと。
log4shell と呼ばれる脆弱性が 2021 年12 月にあった。これはJava というプログラミング言語でプログラムする際に、動作のログを記録するのに非常によく使われるライブラリlog4j にとても危険な脆弱性があった。なにがそんなに危険かっていうと
マインクラフトのサーバが乗っ取られたとか被害も有名。詳細は Piyolog さんのLog4jの深刻な脆弱性CVE-2021-44228についてまとめてみた - piyolog あたりを参照。
そんなわけで即座に影響範囲、脆弱性のない新しいバージョンになっているか調べろ！ってIT関連企業はとてもバタバタしていた。
という背景の中、オープンソースのソフトウェアであるcURL の作者にとても失礼なlog4j の問題に関する質問メールが送られてきて、「サポート契約すれば即座に教えてあげますよ」ってかっこいい返しをして盛り上がっている。
cURL (https://github.com/curl/curl]) はオープンソース(以下OSS)の通信ライブラリとコマンドラインツール。Linux などのサーバ上からファイルをダウンロードしたりするのにとてもよくつかわれるライブラリ。
C言語で書かれている。
ライセンス はMIT を参考にした独自ライセンスhttps://curl.se/docs/copyright.htm]
OSS は基本的に無保証で提供される。そのことはライセンスに明記されている。
THESOFTWAREIS PROVIDED "ASIS", WITHOUT WARRANTY OFANY KIND,EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. IN NO EVENT SHALL THE AUTHORS ORCOPYRIGHT HOLDERS BE LIABLE FORANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN ANACTION OF CONTRACT, TORT OROTHERWISE, ARISING FROM,OUT OF OR IN CONNECTIONWITH THESOFTWARE OR THE USE OR OTHER DEALINGS IN THESOFTWARE.
そんなOSS に対して、
「あなたがこのメールを受け取ったのは、■■があなたが開発した製品を採用しているためです。私たちはこのメールをあなたが受け取ってから24時間以内に、お読みいただいた上でご返答いただくよう要求します」
といった上から目線のメールを開発者に送るというのは、IT企業として無知にもほどがあるといったところ。加えて log4shell問題、名前のとおりlog4j の脆弱性なのでJava でかつlog4j を使ってなければ影響はないのに、C言語でかかれたcURL に問い合わせているので問題を全く理解していない。(Java の j が消えるので log4shell という命名はどうなんだというのは個人的にある。つーか Poodle とか Spectre とかファンシーな名前つけてあそんでんじゃねーとも思う。)
なおcURL はどうやら開発者のDaniel Stenberg 氏が wolfSSL というところを通じて商用サポートを提供しているらしい。 https://curl.se/support.html]
ということで、「サポート契約を結んでいただければ、喜んですべて速やかにお答えしますよ」 というのはネタでもなんでもなく、普通の対応。
そしてブログに書いてある2回目の返信で、David と名前を間違えられたのに対して、Fotune 500 の巨人ということで "Hi Goliath," と返しているのも最高にクールですね。
こういうフローが事前に規定されていてCVE とか問題が検知されると発動する。このときに担当が大丈夫です！って回答するときにエビデンス（証拠）を求められるのだけど、クソな情セキは自社の担当の言葉を信用せず、開発会社からの言質をとれ！って命令するので、くそメールがスパムされるという背景があったりする。（担当が無知だったりイケイケだと、とにかく下請けにやらせればいいというパターンももちろんある）
そして情セキも経営層に報告するのに必要で、経営が0リスク信者だと報告が大変なのはわかる。わかるがそれを説得するのが情セキの仕事やで。
加えて担当レベルになると大手は「そんなん下請けにやらせればいいだろ」ってマインドのところが多く、上から目線かつ丸投げすることが多いように思う。
もちろん担当者はピンキリだからこうとは限らないけど比較的多い印象。
ま、これ今回Daniel Stenberg 氏が公表したからばずってるだけで、日本でもしょっちゅう行われているし、Hacker News みると海外でも一般的なムーブのようです。LogJ4 Security Inquiry – Response Required | Hacker News
小さいところは
とかであんまり上から目線でこない感じはするけど、これはあくまで個人の資質なのでやべー人はやべーです。オラオラ系の中小とかやっぱいます。でもこんな細かいことはあんまり聞いてこない。（個人の感想です）
この手のメールになんでカチンとくるのかって言えば
ということで、皆ちゃんと保守・サポート契約して、契約範囲で質問しような！
そして金払ってても相手は人間なんで、お互い敬意をもって接しような！
PublicKey でこの件にからめて記載されている奴について
https://www.itmedia.co.jp/news/articles/2201/11/news160.html]
ちな、これ詳しくないんだけど、OSS 作者が 「もうただ働きで支援をするつもりはない。これを機に、私に6桁ドルの年間契約書を送るか、プロジェクトを分岐させて他の人にやってもらうかしてほしい」 というのもよくわからないんだよなぁ。
火事で財産失ってむしゃくしゃしてやったのかなんなのか。人気OSS になったのに全然金にならんぜ！ってのが辛いのはわかる。が、OSS のライセンス的に支援を義務としてやる必要はないので、そんな義務的になってる報告は無視してええんちゃうんと思ってしまう。今回みたいにサポートフィーよこせみたいなスキームが必要だったのかもしれない。
あと個人開発で、善意でこれ便利だろ？って公開しているものに対して、辛辣な言葉の心ないバグ報告やら改善要望は心には刺さるので辛いのはある。それで辞めてしまう人も居る。
ブコメでフリーライドって書いている人が居るけど、MITライセンスでだしてんだからOSS の理念である自由なソフトウェアという意味で、再配布、改変、利用は自由でいいんだよ。イヤならMIT 以外のライセンスでだせばよい。古くはMySQL の Dualライセンス、最近のRedis とか Mongo みたいに。
ただ、金欲しいとか大体 Donation募集したりするとかやってると思うんだけど、そういうのもあったのかなかったのかがよくわからにぃ。ポートフォリオになるので、採用にはつかえるんじゃないのかね？
じゃなきゃGitHub に Public でコード公開しないと思うんだけどな。いまいちピンとこないのであんまり言及しない。
https://www.publickey1.jp/blog/19/redismongodbkafkaaws.html]
で、商用ライセンスの問題。これ今回のくそムーブの問題じゃないのここに並べられるのに非常に違和感がある。なんかOSS と大企業の対立を煽るようなミスリードを誘っているように感じてしまう。
大手クラウドベンダはOSS のライセンスに則って利用・改変するのは問題がない。つーか儲かってるから金よこせっていうのはちょっと違うんじゃないかなと思う。
オリジナルを開発した会社がリスペクトされず、商業的に儲からないってのは、心情的、道義的、人気的にどうなの？クラウドベンダも金払ってあげれば良いんじゃないの？とは思うよ。（2社は協業したけど）
ただ、オープンソースで公開するということは次のような利点を求めてするこって、それがイヤならプロプラで良いわけさね。
Apache License2.0 とかのライセンスのOSS として公表しているものの利用をフリーライドと表現するのも、それがなんか嫌儲でEvil ってのはちょっと判断できないかなぁ。
大手が自社でメンテできてしまう（できるようにする）というのは経営戦略であり、開発元がクローズにするってのも経営戦略。罵り合い合戦はちょっとなぁという感じ。
OSS の理念的に改修した分は元のソースにもっとフィードバックしろよってのはあるけど AGPL とかで出してないんだよなぁ。
この辺は賛否両論色々あるので気になったら調べてみて。
以上。ご査収ください。
iPhoneの話題でAndroidとの比較を、日本のケータイの歴史も絡めた増田がホッテントリしていたけど、
個人的には、むしろAndroidがここまで普及したことのほうがにわかに信じがたい話だったりする。
自分は、大学で覚えたパソコンで2ちゃんどっぷりだったキモオタ系ということもあり、
すでにJK～20代の女性とっては当たり前になっていたガラケーも、仕事するようになって数年後、渋々持ち始めたくらいの代物。
だからそもそも、ガラケーの文字入力からして使いにくかったし、iモードに至ってはなにそれおいしいの？という感じ。
だからW-ZERO3とかBlackBerryといった、液晶画面+qwertyのハードウェアキーボードという当時のスマートフォンは、文字通り垂涎の的だった。
「本物のネットはパソコンの世界にあるもんだ、スマホはそこらへんをよくわかってる」
と胸踊らせたものだった。
しかし自分がいたキャリアはあくまでガラケー一辺倒=そういう機種は一切ラインナップに加えないので、本当に歯がゆかった。
そんな自分がアラサーのとき日本に上陸したiPhoneには、そりゃもう興奮した。
しかしまたしても「スマートフォンはまだ早い」とか言ってたキャリアが…。
さて、そんなiPhoneの後塵を拝す形でひっそり登場したのがAndroidなわけだが、これがモノになるなんて正直思えなかった。
海外ではすでにハードウェアキーボードのスマホが一定のシェアを持っていたことはなんとなく知っていたし、そういう従来のスマホとiPhoneの一騎打ちになると予想していた。
だってBlackBerryもNokiaもめっちゃ強かったから、まさかソイツらがブランドイメージ皆無なAndroidに全て駆逐されるなんて、ありえないと思うじゃん。
何よりAndroidがLinuxのスマホ向けディストリビューション、要は中身がLinuxということが、以下の理由でパっとしない感を更に強めていた。
あと全面液晶の「iPhoneクローン」なスマホだったら、Windowsのモバイル版が伸びるだろうと思ってたこともある。
Windowsはそこそこの値段でそこそこの使い勝手のデスクトップPC向けOSとして、当時はもちろん今もデファクトなわけだし、その実績からLinuxというCLIメインのOSよりも、ずっとスマホに近い場所にいると思ってたし。
それにスタープログラマのカトラーが文字通り人生を賭けて作ったOSなんだから、少なくとも院生のお遊びから始まったLinuxなんかよりは、モバイルでも上手くやるだろうと。
そういう当時を空気感を知っていて、かつ、ほぼXperiaしか触っていないとはいえ5年以上Androidスマホを買い替えつつ過ごした人間として、正直Androidなんて…と思っているわけで。
そして去年ようやく念願のiPhoneに乗り換え1年ちょっと経ち、「別にAndroidでいいじゃん」が「もうAndroidには戻れねえ」となった結果、更にその思いが強くなったと。
だから、AndroidとiPhoneをガチで比較してなお「Androidでいい」とか、ましてや「Androidがいい」という人は、一体何を見てそう思ったのか、心底理解できない。
PixelやGalaxyや中華スマホは触ったことないけど、Xperiaは国産スマホでは最高レベルに優れていると聞くし、そんな高級スマホと比較してもiPhoneのほうが全然使いやすいのだが。
テレビはAndroid搭載するのを消費者は望んだけれど、結局それほど便利になっておらず、すぐ遅くなって消費者のためになってない。
メーカーは発表前のAndroidの情報を受取るのに億単位の契約金を払って開発費の負担になるわりに、
日本以外の特定メーカーの方が情報提供が早かったり、契約金が少なかったりで、そもそも同じ競争の土台に立てなかった。
電子部品の規格は米国が決め、米国企業の装置がないと認証できなくなっている。
ゲームはまだ日本が強いというが、ゲームエンジンは米国が作っているし、アップデートでの仕様変更に振り回される。
最初はエンジニアがタダだからと遊びで始め、これが潮流になって欲しいと盛り上げ、
人材の流動と転職を考えると社外にオープンになっているものの方がエンジニアとしては都合が良く、デファクトを求める。
Googleが内部では社内ツールばかりで差別化と競争力を維持しているのとは、かけ離れていった。
日本だと研究者やら、エンジニアやら多くの人が時間を費やしてしまっている。
