  |
はてなキーワード: Unixとは
——登さんくらい常に気持ちをフラットにできればいいのですが、仕事のストレスで参ってしまうエンジニアも多くいます。
そうですね。ストレスを感じる理由はさまざまあると思いますが、一つ例をあげるなら、仕事の目的が「お金を稼ぐこと」それ自体になっている人は疲弊しやすいかもしれませんね。
稼ぐことを目的としている人のゴールは、おそらくご自身の「安寧な暮らしの実現」にあるのだと思います。それがとても大事なことなのは言うまでもありませんし、否定するつもりも毛頭ありません。
一方で、私や私の周りにいる人たちは、現状の成果に満足せずに得たお金を次の進化のために再投資しようと試みる人ばかり。どちらが良いとか悪いとかではなく、価値観が違うだけのことです。
ただ、前者の「お金を儲けて安寧な暮らしがしたい」という人にとって、仕事から受ける疲労や気分の落ち込みというのは、ある種当たり前のことだとも思うんですよね。
——というと？
どこかで成長を諦め、安寧な生活を望むような性向が、かえって心身の不調やフラストレーションを生み、パフォーマンスを落とす一因になっているのではないかと思っているんです。
「お金を稼ぐためだから、しょうがないか」と思ってやっていること自体が、ストレスになるのではないかと。
登 大遊さん
でも、こればっかりは人の価値観ですからね。変えようと思っても、すぐに変えられるものでもない。
どんな価値観で生きるのかを選ぶのはその人ですし、どんな人生を選んでもリスクはついて回ります。
安寧な生活や休息を優先する生き方には、仕事に対するストレスやそれに付随する心身の不調などの副作用があるということに過ぎません。
ただ、一つ言えることがあります。日本において、「大義を持って働く」生き方を選択をした人は、これから大変有利だということです。
——どういう意味でしょう？
自分の手で未来を変えようと野心に燃える人が世界中から集まるシリコンバレーなどでは、埋もれてしまうかもしれない人であっても、日本の旧態依然とした組織の中では、同じことをするだけで、比較相対的に価値が高くなりますから。
技術者がわざわざベンチャーを立ち上げ、投資家からお金を引き出すために詭弁を弄したり、ニーズをでっち上げたりしなくても、日本の大企業にはストレートに解決すべき課題がいくらでもあります。そしてそれらの問題を、自分自身の頭脳を用いて解決しようとする時は、必ず、従来とは異なる方法で解決する必要があるのです。
なぜなら、まさに従来手法では解決できなかったことからその問題が放置または堆積されているためです。
——その場合は、どうすればいいのでしょうか。
その問題を一旦一般化・抽象化した上で、これを解決することができるより低レイヤーのフレームワークのようなものを作ってしまうことが重要です。一定の労力はかかりますが、それによって生じた汎用的成果物は、他の業務や他の組織においても普遍的価値を持つようになります。
ここで重要なのは、目的を「業務上の特定の問題の解決」から昇格させ、「その特定の問題と本質的に類似しており、かつ既存の最適な解決方法が存在しない、新たな汎用的解決方法の実現」という、より価値の高い目標に設定する必要があるということです。
登 大遊さん
——目先の特定の問題をその場しのぎで解決するのではなくて、普遍的な価値を目指すと。
その結果、問題がうまく解決され、成果物が出たならば、サラリーマン的な自分自身（個人）と自組織にとっての短期的な狭い利益だけでなく、同時に「世界における技術の進歩」という長期的で大きな価値が生じます。
具体例を挙げると、たとえば「UNIX」を構成する重要な機能、たとえばシェルやプロセス間通信、パイプ、grepといった機能。これは電話会社であるAT&T社の特許部門における、膨大なテキストファイルを全文検索するという特定の業務を解決しようとした同社の社員たちが、単にその社内問題解決にとどまらず、さまざまな組織や目的で汎用的に利用できる仕組みを考案し、プログラミングして実装したものです。
結果として、「UNIX」は汎用的に利用される価値を有し、単に一企業の業務に留まらず、全世界的に普及し現在のサイバー世界の基礎となっています。
このように考えれば、ICT技術者は、これまで組織内で放置または堆積されてきた多種多様な課題について、目先の解決ではなく、「正しい普遍的な方法で解決する仕組みを作る」という気概で、真摯に向き合えば、自然に世の中に貢献できる成果ができるわけです。
少し前にmacOSはLinuxではないとTwitterで話題になりました。その際に
といった内容のTweetを見かけたのですが「元になったのはBSDではなくMachなんだけどな～。昔を懐かしみつつ、調べながら何か書くか」と思いつつ、面倒になったので記憶のまま適当に書くことにしました。
Machは当時一世を風靡していたマイクロカーネル設計を採用したOSで、BSDとは全く違うOSです。
ただしBSD互換機能を利用していたユーザーは、内部に関心が無ければ
といった印象を持っていたのではないでしょうか。互換機能としては成功なのですが。
macOSのもとになったNeXTSTEPはMachを改造して始まりましたが、現在では別物であると考えるべきです。
macOSは直接にはMachから派生したもので、BSDではありません。ただし
など、BSDと誤解させる点があるのは確かです。
上記のUnix → BSD → Mach → NeXTSTEP → macOSではソースコードを利用しながらOSを作って行ったため共通の部分がありますが、これらとは全く関係無く独立して開発されたものです。
しかし現状ではNode.jsやPythonなどでプログラムを作ろうとした場合にシェルで使うコマンドはmacOSとLinuxでは共通するものも多く
上映当時をリアルタイムで経験したくせに、その頃は歌番組やプロ野球といったメジャーなものにノレなかった、
今で言うド陰キャコミュ障のキモオタだった自分は、ハリウッド映画にも全く触れずに過ごした。
おかげですもごっつも、スーパージョッキーや元気が出るテレビとかも、B'zもドリカムもユーミンもスルーしてたのだから筋金入りだ。
そんなキモオタ学生も、今やどこにでもいる冴えないおっさん、いやジジイだ。
そんなジジイがTwitchの推しが「見る」というだけでホイホイ見に行くんだから、まあその、なんだ、特に弁解はない。
さて、きっかけはともかく、同年代からは「は？今頃？」と言われそうなタイミングで、ジュラシック・パークを見た。
感想としては、結構想定外な意味で「いい映画だわ」と余韻に浸る結果になった。
以下、一応ネタバレあり。
正直、今回ちゃんと見るまで「まあハリウッド映画だし終始大スペクタクルで迫ってくるんだろうなー」と思っていた。
でも実際は「そこまで騒がしくない」というか、きちんとSF小説の原作をリスペクトしたというのが納得できる、良作だった。
個人的に小説ベースの名画というとスタンド・バイ・ミーくらいしか出てこないが、あれに通じるストーリーの「真面目さ」「細やかさ」が作品のうまみになっているというか。
しかし同時に、声を出してしまうようなカメラワーク(Tレックスとかヴェロキラプトルとか)も随所に散りばめられ、最後まで飽きずに見れたのは、さすが名監督スピルバーグの演出と言っていい。
ちなみに作中のイケメン数学者が薀蓄と口説きで披露するカオス理論は、確かに当時の流行りだったが、それが回り回って今のAIとかにも関係しているんだから、息の長い分野である。
とはいえフィクションの中に出てくるITなんてリアリティ的な意味でロクなもんじゃないし、実際この映画も警備システムをはじめ、微妙な所があちこちにある。
その上で注目したのは、本作での事件の発端となったシステムエンジニア(兼プログラマ)のキャラ。
ピザをクッチャクッチャさせてそうなデブというのは、家庭にあるパソコンがオタクのおもちゃでしかなかった当時では、プログラマのステレオタイプだったわけで。
何より、アメリカでもGAFAが世界の覇権を握るほど伸びてくるまでは、たとえハーバードを出ていてもSE仕事はブラック待遇というのは考えさせられた。
まあ日本じゃ、令和の今もそんな感じだし。
更に当時はWindows95すら出ていないので、業務用にプログラマが使う計算機のうち、フルGUIのワークステーションといえばUNIXとなる。
なので本作でもMotifだかXViewだかをGUIにしたっぽいUNIXワークステーションを、例のデブも使っていたし。
あとUNIXといえば、金持ちじーさんの孫2人のうちパソコンが趣味の姉がUNIXを使えるというのも、もし父親が研究者なら納得である(macでもいいけど)。
仮想システムを構築するにあたり、CIFS しか使えない NAS をバックアップ用に選定してきた SI 屋さんが居たので、CIFS と iSCSI のどちらが早いのか、試してみました。
テストに使う NAS は QNAP の Turbo NAS TS110
http://www.tekwind.co.jp/products/entry_6719.php
です。もう６年以上愛用して、カビが生えてもおかしく無い程に古いし, Marvell 800Mhz という低スペックな Qnap NASです。 100Mbps 時代のモノです。
昨年、HDDがお亡くなりになったので、3Tb の HDD に交換しました。ファームウェアはこんなに古い機械でも、QNAP シリーズの最新バージョンが利用できます。
iSCSI は、今あまり見なくなりましたが SCSI ケーブル規格や、SASケーブル接続のハードディスクを、一般的なIPネットワークで規格で仮想化したものです。
マウントするホストシステム側は iSCSI initiator, ディスクストレージの機能を提供する側を iSCSI Target と呼びます。
ホストから「マウントするしない」はイニシエータ側のソフトウェア的な操作で行います。これは便利な機能で、ディスクの故障などで、一時的に物理的に取り外さなければいけない場合でも、ホストからの操作だけで実際のケーブル結線の脱着を行う必要がないので、今時での SAS の外付けディスクドライブの様に、ホストもシャットダウンして電源を切り、結線を外して修理、交換する、という必要がないので、ディスクデバイスの修理をホストの電源を止めないで実施できると言う、実に便利な事ができます。
という事で、仮想環境では実に使いやすいストレージデバイスなのです。
マウントするホスト側から見ると単純に SCSI/SAS のハードディスクに過ぎません。iSCSI のストレージをマウントしてからは、通常の増設ディスクの様にフォーマットして、ホスト側で使う一般的な XFS, ext4, NTFS などのフォーマットでフォーマットする必要があります。
Linux の iSCSI ターゲット側からは、内部にターゲットとして使う「巨大なファイル」が、どん！ とあるだけです。この巨大ファイルを、イニシエータ側に仮想ディスクイメージとして提供しています。当然シンプルな仮想イメージなので、ファイルそのものをバックアップコピーすれば、ストレージのイメージそのもののバックアップができます。
※ qnap NAS の場合、iSCSI イメージは、 /share/HDx_DATA/.@iscsi.img の下にドンと作られるようです。
[Solved]How to mount iSCSI file?
https://forum.qnap.com/viewtopic.php?f=180&t=25322
[/share/HDA_DATA/.@iscsi.img] # pwd
[/share/HDA_DATA/.@iscsi.img] #
[/share/HDA_DATA/.@iscsi.img] # ls -l
-rw------- 1 admin administ 6442450944 Nov 12 2017 iSCSI-2015ace1-5a078d66.000
-rw------- 1 admin administ 1073741824 Jun 24 09:52 iSCSI-lun4-5d0de534.000
-rw------- 1 admin administ 107374182400 Nov 4 2015 iSCSI-nss01-56399e1a.000
-rw------- 1 admin administ 5368709120 Nov 11 2017 iSCSI-nss2015-5a06cf6d.000
-rw------- 1 admin administ 21474836480 Jun 22 17:11 iSCSI-test-56b3ce90.000
-rw------- 1 admin administ 5368709120 Jun 22 17:11 iSCSI-test-56b3ce90.001
[/share/HDA_DATA/.@iscsi.img] #
※ とても重要
CIFS/NFS のファイル共有NAS と違い、iSCSI でマウントして一つのターゲットを制御できるのは、一つのホスト、一つのイニシエータだけです。複数のホストからイニシエータでマウントする（できちゃいます）と、ファイルの排他制御は行われないので、ファイルシステム自体の不整合が起こります。
つまりファイル共有という目的には向いていない、という事です。あくまでも iSCSI ターゲットはネットワーク上の仮想ディスクです。
もっとも、一つのホストからマウントしてファイルを保存して、いったんオフラインにして、ターゲットを別なホストからマウントする、という事はできます。また、ターゲットは一つの iSCSI デバイスで複数作れるので、１台の iSCSI 装置に複数のターゲットを実装して、複数のホストから別々のターゲットイメージをマウントする事は問題ありません。
極端な話、ホストのハイパーバイザーは USB メモリやSANブートさせて、後はマウントした iSCSI の仮想イメージ上で、仮想マシンを動かす、HDDレスなハイパーバイザー運用もできます。
物理的な転送速度は、ネットワークの速度とディスクデバイスの性能に依存します。当然 10Gb base のネットワークカード、HUB、高規格なケーブルを使えば、論理的な性能は 10Gbps です。大抵は NAS の性能がそこまで出ないのですけどね。ヨドバシカメラあたりで売っている 4,000 円程度の 1G HUB でも、そこそこの性能が出てしまいます。
距離は、IPがつながればどこでもなので、ホストコンピュータとメインのストレージを自社のサーバールームに置き、イニシエータを動かし、バックアップ用の iSCSI ターゲットをデータセンターに置く、なんてこともできます。
【送料無料】QNAP TS－431P2（ホワイト） NAS 4ベイモデル クアッドコア CPU ／ LAN 2ポート搭載 （TS431P2）
価格:56,145円
感想(0件)
iSCSI の耳慣れない言葉に LUN （論理ユニット番号 : Logical Unit Number）というのがあります。
昔の SCSI は、 SCSI バスアダプタに７番のIDを振り、残りの 0 ~ 6 のディスクや CD, Tape などに ID を振り分ける物理的な３ビットのディップスイッチやジャンパ端子が付いていました。これが SCSI アドレスです。
これが実に難物でした。特に、複数の SCSI バスアダプタカードをデュプレクス設定する場合、割り込み番号も別々にするので、手が滑ってジャンパピンを飛ばして床を這いまわって探したり、難解なディップスイッチを前に数日悩んだものです。
つまり一つのSCSIバスには 0~７の合計８台（うち大抵７番はSCSI バスカード）の物理ユニットデバイスがつながって別々に見えたという仕組みだったわけです。
ところが SCSI バスを使った Raid コントローラが出てくると、ディスクの鈴なりが、一つの物理デバイスに見えてしまうわけです。これを「論理的な仮想番号」に分割して、システムからは、単一の鈴なり Raid ディスクを複数の論理番号に分割したわけですね。
これが LUN というヤツです。
iSCSI 機器のターゲットも、内部のソフトウェア的に複数の論理デバイスに分割して、複数のホストコンピュータから複数の物理デバイスのように見せかけるわけです。
別々な LUN は一つ、あるいは複数の iSCSI 機器によって、複数のホストに別々のディスクデバイスとして見せかけるンです。
https://en.wikipedia.org/wiki/Logical_unit_number
Qnap NAS の場合、iSCSI ターゲットはウィザード形式で簡単に作成できます。EXT4 ファイルシステム上で、オンラインでも簡単にサイズの拡大ができるので、 Windows の Storage Server のように NTFS の VHD 形式ではないので、そこそこ性能が出ますが、いかんせん古さと遅さは否めません。
Qnap NAS の iSCSI ターゲットの設定は、偉そうな Linux 系サイトに書いてある程、面倒なことはありません。ストレージマネージャから iSCSI タブにあるウィザードに従って iSCSI ターゲット名に任意の名前を付けると IQN にその文字列が追加されるだけです。わざわざ vi エディタに「正確に」綴りを間違えずに設定する必要もありません。ここでは Chap 認証は付けませんでした。
仮想化時代の NAS 選び - やっぱり iSCSI は早い。_a0056607_16405779.jpg
機械は古いのですが、逆に言うと、「古くて遅い」ため、サーバーとNASとの接続プロトコルの性能差が、如実に現れる事になります。
QNAP TVS-951X 10GBASE-T/NBASE-Tポート内蔵
Windows10 の Microsoft 製 iSCSI イニシエータは「コントロールパネル」＞「システムとセキュリティ」＞「管理ツール」の中にあるので、ここで、設定済の iSCSI 「ターゲットを」 「検索」して選んで「接続」します。Chap 認証を付けておいた場合はターゲットで設定したパスワードが必要でしょう。
仮想化時代の NAS 選び - やっぱり iSCSI は早い。_a0056607_16412132.jpg
新規に作成して、接続した後は、フォーマットされていないため、ディスクマネージャからフォーマットして使います。ちなみに、フォーマットして利用した iSCSI ターゲットの仮想ディスクは、他のマシンでマウントすることもできます。つまりHDDを取り外して、他のPCに繋げる事と同じことですね。
ＰＲ
ちなみに opeSUSE で使うにはこんな感じになりました。
open SUSE Leap 15.1 で iSCSI NASを使ってハマった
https://islandcnt.exblog.jp/239328437/
一番イラつくのは、巨大なファイルの転送でしょう。という事で 3G 程ある SUSE Linux のインストール用DVDの ISO ファイルを CIFS でコピーしてみます。
仮想化時代の NAS 選び - やっぱり iSCSI は早い。_a0056607_16414334.jpg
３分１１秒かかりました。１Gビットネットワークで 12～3% 程度の帯域を使って通信しています。明らかに古いNAS の性能が足を引っ張っているようです。
スループットは 150Mbps 程度で全体の最大１５％程度でしょうか。
仮想化時代の NAS 選び - やっぱり iSCSI は早い。_a0056607_16415832.jpg
仮想化時代の NAS 選び - やっぱり iSCSI は早い。_a0056607_16422170.jpg
初速は出るのですが、その後は、ボロイ TS-110 の性能がモロに出ます。それでも 20 MB/s から 25 MB/s 程度は出ています。
仮想化時代の NAS 選び - やっぱり iSCSI は早い。_a0056607_16423835.jpg
２分２５秒でした。 大体２０％程度のスループットです。
--
数字に弱い私の脳みそですが、 iSCSI は CIFS より 1.5倍くらい早い、という事が言えます。
Zabbix で QNAP TS-110 の I/O を見てみると、前半の CIFS アクセスより後半の iSCSI アクセスの山が高い事がよくわかります。
仮想化時代の NAS 選び - やっぱり iSCSI は早い。_a0056607_16425860.jpg
CIFS を使ったリモートディスクのマウントは、他のPCからもアクセスができる、というメリットがありますが、iSCSI は単一のホストからのアクセスしかできません。<--- これ重要.... -- もっとも、ターゲットストレージを複数作って複数のサーバーから異なるデータ領域にアクセスはできますが -- バックアップ用途や、サーバーの増設ストレージとして考えれば、良い選択であると言えます。
もっとも、iSCSI デバイスそのものは、ターゲット単位で別々なホストから接続できます。しかし同じターゲットで別々のホストからイニシエータから繋ぐと、とても笑いごとにならない事態になるので、普通やりません。
ハイパーバイザー同士で一つのターゲットを共有してライブマイグレーションはしたことはあります。
こうした性能のわずかな違いが、仮想化システムのハイエンドな領域で違いとなって出てきます。なお Qnap でも openiSCSI でも Windows Storage Server でも取った領域そのままのサイズのでかいファイルが作成されるようです。
国産 NAS の「ハイエンド」と称する「LANxxxx」などのモデルでは Windows Storage Server を使って NTFS フォーマットしています。Windows Storage Server は見た目 Windows サーバーそのものなのですが、ところどころちゃんとデチューンされているようで、SOHO向けが限度です。
こういった国産 NAS メーカーの製品カタログでは、「ハイエンド」は Windows Storage Server を搭載して、低価格のNASは Unix 系のシステムで「低価格」を謳っていますが、そもそも、上位モデルは、CPUやメモリの性能が高いものが使われています。性能が違うのは当たり前なのですが、あまり性能が出ないだろうと思います。
Windows Storage Server じゃなくて、ちゃんとした Windows Server と CAL 買えよな、という事なのですね。
このあたりは独自OSを NAS としてチューニングした Qnap や Synology, asuster などの iSCSI 機能付きの NAS を中規模ネットワークのミドルレンジの NAS として利用したほうが良いと思います。
仮想環境でのネットワークアタッチストレージ(NAS)は、本回線（構内LAN）とは切り離し、ストレージ専用のネットワークとして独立して運用させるのが基本です。サーバーとNAS間で凄まじい通信が発生します。サーバーNICが２ポート以上のものが推奨されます。
iSCSI はあくまでもネットワーク上のストレージのみの機能を提供するものであり、ファイル共有の手段ではない、という事です。
NAS をCIFSで使うと NAS が持つ独自のアクセス権限を設定しなければなりません。セキュリティも当然 NAS 独自の機能で設定します。
iSCSI はあくまでも「外付け SCSI デバイス」のネットワーク版なので、マウントする側のOSそのもののファイルシステム、セキュリティ機能、アクセス制限がホスト側の機能をそのまま利用できます。セキュリティ的には、マウントする際のパスワード制限しかないので、独自のストレージネットワーク内に配置すべきで、ユーザが使う構内ネットワークに配置すべきではありません。
Docker使うならIntelのCPUにLinuxしか選択肢ないだろ
M1 MacでDocker動かすためだけにZENNに25517字書くとかアホだろ…
現状ならWindowsのWSLやHyper-Vの方が遥かにマトモだし、
一番いいのはWindows消してLinuxをインストールすることだと思う
というか、今、先週到着した新マシンを初めて立ち上げて色々やってたんだけど、
Windows 11も色々クソというか、クソ以前にヘンテコな直訳で失笑させられたんだけど、
単にGUIなんて表面的なものでOSの価値が比較されがちなのは、
そりゃ、世の中の普通の人は技術的なこと知らんのが普通やろというだろうけど、
技術的なこと抜きにしても、そんなに今のGNOMEデスクトップが悪いとも思えない
GUIに否定的なLinusも今のGNOMEはそんなに悪くないみたいに言ってた記憶がある
QtベースのKDEはGNOMEより遥かに軽くなったが、UIとしてはクソだと思う
今のGNOMEとかUbuntuのデスクトップ環境はスマホみたいになったと揶揄されるが、
11inch 2in1のノートPCでUbuntuを使うと、タブレットのようにも使えて個人的には快適だ
Ubuntuだとハードウェアが対応しないということもそんなにない気がする
不安なら、例えばDellは米国ではUbuntuプリインストールして売ってるマシンもあるので、
GUIなんかより、セキュリティ、個人情報をやたらにMSやApple、DellやHPが取得しないか、
やたらとハードウェアの要件とかで足切りして、買い替えを促さないか、
それにも関連して、デバイスドライバとかが長く対応し続けるか、
なんだかんだ中身がオープンであり、使用しているユーザーが多いほど、寄らば大樹だと思う
WindowsマシンのデータレスキューでもLinuxは活躍すると思う
というか、Appleは枯れた技術としても安心感のあるUNIX文化を不安にさせるだけなので、
ソフトウェア開発における名著とされる読みものがある。かつて、そういった著作のエッセンスをひたすら抜き出して黙々とまとめていくはてなダイアリーが存在した。2010 年代のことである。GoF のデザパタ本とか UNIX 哲学とかピープルウェアとかそういうの。ジュンク堂の本棚でいえば「SE 読みもの」というやつだ。業界に入って間もなかった当時の自分は、技術的な相談ができる大人が周囲にいなかった。いま思えば、残業中のオフィスで長いコンパイルを待つあいだ、ぼんやりとこのはてダを読み、目の前のやるせないソースや、所属するチームが置かれた状況について思いを巡らせながら、ガス抜き感覚でこのはてダを読む時間が好きだった。どの項目も歯切れの良い紋切り型の文体で読みやすく、読んでいるうちに不安のかたまりがスルスルと解かれていき、気持ちがラクになるような気がしたのだった。
その後、わたしがアラサーになるころには、そこで紹介されていた大部分の原著は書店で購入し物理的に所持するに至っている。あのはてダがなければ、本屋でも仕事関連の棚で足を止める人間にはなっていなかったのではないかと思う。その後、当時のはてダの内容を抜粋したものが秀和システムで書籍化され出版される運びになった。ファンだったわたしは発売をとても楽しみにしていた。が、本屋に並んだ書籍を手にとってみると、あのはてダにあった宝物のような輝きはすっかり失われていた。なぜかはわからないけれど、説得力が損なわれている気がしたのだった。書籍化の都合、はてダに貼られていた Amazon へのリンクが取り払われ、原著との接続性がいくぶん薄らいでしまったせいかもしれない。またこの書籍化に伴って、はてダも閉鎖されてしまった。もっとも新刊の売上にも関わるだろうし、あの「要約」は原著に対する網羅度がかなり高いもので、権利面ではかなりグレーなものだったように思うから、閉鎖されるのは当然の成り行きだったと言える。が、自分の成長期にあたる年代にあのはてダがあったことは本当にキャリアの上で助けになったと感じているし、原著を所持していてもなおあのはてダを参照したいという思いがあるくらい、とても優れたものだった。他人の「きれいなノート」を借りて勉強していたような感覚というか、そんなような。「新人に読ませたい n 冊の本」というタイトルのクソ記事がもはや春先の業界の風物詩になっているが、そんな記事とは段違いにもっと直接的に本が持つ価値を訴えてくるコンテンツだったのだった、少なくともわたしにとっては。
図解界隈というのが流行っていると聞いて、そんなはてダがあったことを思い出した。結局のところ「SE 読みもの」も自己啓発本に他ならないし、個人的に DDD
なんて宗教だとすら思う。それにしても「要約」がきっかけで世界が広がるとことは実際あるかもしれないよ、ということが伝えたかった。
まぁ、向いていなかった人にとっては転換期になった年齢だよな、とは思う。いわゆる、中年の危機というか。今は日系のハードが駆逐されて、互換機が全盛となって、転職が可能になったおかげでプログラマーのママで老後にいける幸せな時代だと思う。かつては BASIC のような学習コストの低いものでプログラマーをなのれたけど、今となっては OOP や SQL、そして Unix といった類の習得する学習コストが高くて、一度習得したらずっと忘れないような魔法のようなツールが無かったので、体力がある若者たちが勝ってきたけど、というだけだがね。もっと良かったこととしては、プログラマーの需要が低下しなかった、という幸運があっただけかもしれんがね。
ひろゆきは金が無かったんじゃなくて財産収入隠ししてたんだよ。サーバー代払えず閉鎖の危機にUnix板の有志が！みたいな物語を皆がずっと信じてる間にマネロンのスキームを作り上げてたの。国税庁が掴んだ額だけでも大体1億/年くらいを迂回送金していた。
国税は海外の送金記録からひろゆきの送金スキームを割り出して税務調査、脱税分を支払わせた。
https://www.huffingtonpost.jp/2013/08/24/tax_dodgers_n_3808120.html
だから単に金が無くて執行できないっていうんじゃない（それは民事事件で普通にある）。こういう方法で脱税どころか民事執行逃れまでするってのは経済ヤクザなわけで、.sc分裂騒動では離反したネラー達の間で「沖縄でゆっくり休んで」って言い方が流行した。ライブドア事件で元幹部が変死（自殺）した事件の仄めかしで、ひろゆきの後ろにマネロンスキーム作った反社が居て金づるの2ch取られたひろゆきが無用になったので頃されるんじゃないか？それで焦って.scなんてコピーサイト作ったんじゃないか？って想像してからかってたのね。
そもそも2ch取られた原因もこの脱税と執行逃れの為のマネロンスキームで、フィリピン在住の極右米国人ジムワトキンスの会社に表向き事業を譲渡した。
でも実際はサイト管理権と収入はひろゆきの口座に転がり込むってスキームにしてた。国税は送金ルートを追ってこのスキームを暴いたんだな。
でもひろゆきがヌケてるのはちゃんとジムにエサを与えなかったこと。公的にも法的にも譲渡は完了しているので、実際は譲渡されてないという状態を維持するのはジムの善意でしかない。
なのに有料会員の●が情報流出で停止した後にジムの収入への手当をしなかった。●の収入はジムの取り分だったのに入って来なくなったからサーバとバックボーン経費が掛かるだけの状態になった。悪人同士のゼニの付き合いで片務状態にしたら刺されるに決まってるわな。まぁ、送金すると実態が国税にバレるっていう事情はあったろうが。
飄々としながらも自分のカリスマを過信していてジムにあそこの管理は出来ないとか思い込んでたのもあったんだろうが完全に慢心で、削除人とかボラ運営とかの配下のネットゴロ達のサーバ上の権限を削除されて、広告も別会社に契約されたらもうひろゆきの方には一銭も入らなくなった。物理的にも論理的にもサーバの管理者権限持ってるのはジムなんだからそうされるのは当たり前だ。
だからはてなーはひろゆきの倫理性を問題視して目を吊り上げるけど、実際はその企みの結果2chと収入元を失っているので寓話的なお笑い話なのだ。策士策に溺れるってやつ。ネトフリでドキュメンタリ撮ってくれないかな？
悪巧みして書類交わして鍵も渡して相手に経費入れなかったら相手に取られちゃった！あいつは悪人だ！っておまいもだろ。笑っちゃうよな。
ひろゆきはその後裁判で2chを取り戻そうとしているが、その主張って「脱税と執行逃れのための偽装譲渡で、密約があったのに反故にされた。密約の方を履行せよ」って事ですぜ。和久峻三が存命だったら面白裁判集に入れそうだ。
ひろゆきは「裁判でこっちの主張が認められた！我の占有権を裁判所が認めた！」ってたまに叫んでて判決文もUPしてるんだが、嘘で「表向きに払っていた金があったが権利権ジャック後は支払う理由がないから返せ」って内容で、フォロワーは中身読んでないのよ。
最後にトリビア： 川上量生が山本一郎に対して投稿削除の要求を行い、山本がこの削除義務の債務不存在確認請求訴訟を提起した時（所謂川上vs.山本の一発目裁判）に山本は「提訴していいですか？じゃなくて提訴しましたであります」とコメントしていた。これはひろゆきの.sc設立時に山本が「.sc差し押さえていいですか？」と挑発したところ、ネットで然程ウケず、やきう仲間のなんJで「差し押さえていいですか：無能、差し押さえました：有能」と詰られた事に因んでいる。
そこんとこ詳しく。メタップスとか？
Waf なんて書くな！ WAF とかけ！
うっせーな。クラウドベンダーの独自 API なんか使いたくねーんだよ。オラクルじゃあるまいし。
まぁ、それは認める。でもさ、select や create とかのDML/DDL は CRUD と同じだけと、DCL なんて権限を発行できるりょういきにトーシロを突っ込むわけにいかないだろ。何も考えずに GRANT TO なんてプロダクション環境で発行されて日には、権限消失されたら永遠にデータにアクセスできなくなるかもよ？
そりゃそうだけど、フロントエンドは移り変わりが激しいじゃないですか。ほんの数年前までは Flash と DoJa のアプリを作ることがフロントエンド開発者でしたよ？一方データベースや OS の方は、ここ三十年ぐらい Unix と RDB が鉄板だった書ないすか。低レイヤだっていうけど、IoT なんかで C言語開発者はバリバリっすよ。例えば、クラウドフレアなんか CDN の再発明をしてますけど、サーバーラックを見る限りだと差がついているのは低レイヤの根本技術の改善であって、私はそこにプロフェッショナル性を見出しますがね。
わかっていないのはテメーの方だ。今日オーバーフロー問題を抱えている C/C++ でサーバーの開発をしようとするのが危険なのは承知しろよ。パフォーマンスを必要とするなら Rust、または GC があるけど Go言語を使って実装すべきだろ。高学歴なのは結構だけどは、現実は見えてないのか？いい加減にしろ。
そうだね～。卓越したインフラエンジニアがすぐに手に入るなら、問題ないだろうけどさ、ベンチャーや硬直化した雇用形態の我が国で有能なインフラエンジニアをすぐに採用できるかよ。何年前の知識で戦っているの？時代は DevOps なんですよ。必要とあらば、すぐ学んで、応用して、デプロイできるのに「インフラエンジニアを採用から始める」なんて、ヨーロッパが衰退する理由もよくわかるよ。プププ。
誰が Next で SSR なんてするか！あれは SEO が必要な場合に限る。そもそも SSR なんて危険だからまともなエンジニアだったらしないだろ。問題になってないだけで、本当のブラウザとクローラが見える内容が違うなんてスパム認定されてもおかしくないんだ。クローラにインデックスされるページで SPA をやろうとするやつはセンスないで。
すいませんでした。本当にすいません。
ん？ AWS SQS だとパフォーマンスに問題があることしたいから Kafka を使いたいのよ。確かに Zookeeper のことは詳しくないよ。だけど、AWS MSK 使うんで。PaaS というもんがあるので、だめなん？ログ収集は GKE みたいに ログに出したら Fluentd で収集してくれる時代になんでグチグチ言われないといけないの？
ハア？インメモリのデータベースに信頼するほどヤワじゃないから。Redis なんて飛んでなんぼ。だから Kafka のようなストレージに保存されるメッセージキューを利用したいの。
これないと、CI の責務が大きくなるじゃん。ほんでもって、ArgoCD なんて Kubernetes で展開したら運用までしないといけないじゃん。メンドクサ。
いや、J1ビザをとってアメリカに留学したことあるよ。あと、「世界でもっとも強力な9のアルゴリズム」「CleanCoder」「戦うプログラマー」 の本に書いてあるじゃん。馬鹿にしてるのか？
元増田です。
なんか、大人しくUbuntu使っとけば問題ないみたいなブコメがあったけど、Ubuntuだって初心者には普通に難しいからな？
それこそWindowsやmacと比べたら、明らかに高頻度で躓くケースが多いね。
だからサポートする方も大変ってか、Windowsやmacよりも手がかかるのが現実。
「お前、Linux使っててそんなとこまで訊くんだったら帰れよ」
と何回思ったことか。
そんな感情を押し殺して
「(しょうがねえなあ～)○○って知ってる？勉強しとけよーw」
で済ますが、正直言って全く気分は晴れない。
何がモヤモヤするって、Linuxを始めとするOSSに馴染んでいる人間ほど、
「確かに取っ掛かりは難しい。でもそれを乗り越えた後に、素晴らしい『自由な世界』があるんだ」
「どのソフトも時に使いにくいとさえ思うくらい個性的な手触りだけど、それこそが多様性であり、善なんだ」
という主旨の内容を、マントラかよって勢いで唱えるわけだが、まあ正論だけどズレてんなーって感じるんだわ。
アレっすか、一億総ハッカー社会を目指してるんですか？あるいはポール・グレアムの言うようにいっぱしの画家気取り？みたいな。
そりゃ、職業プログラマーとかがここらへんの話を知らないとなると、確かにヤバい。
あと、今のソフトウェア開発はほぼネットワークと不可分だったりするので、Linuxを含むUNIX系OSもろくに扱えないレベルの人間が、ネットワークの専門的知識を得ることは不可能という意味で、開発者ならUNIXくらい使えんだろって話もある。
でもさ、そんなんパソコンを仕方なく使ってるような「普通の人」にはどうでもいい話なわけ。
それこそ多様性云々にしたって、例えばTeXやgnuplotやPerlやsendmailやbindといった、便利である以上に、その複雑怪奇な仕様で長年に亘ってユーザを苦しめ続けてきたことの言い訳にはならなくね？
あと日本語処理が、結局Googleが本気でLinuxに肩入れするまで、UNIX系OSでは(少なくともWindowsと比較して)まともに動作していなかったことも知ってるからな。
それにMS OfficeとAdobe Creativeの代替足りうるOSSは、未だ登場していないし。
鼻につくってそういうとこだぞ？わかる？
一般的に、自由であることと快適であることは全く関係ないけど、これはソフトウェアにもまんま当てはまる話だと思うね。
これまたブコメに「Androidは世界で最も成功したLinuxディストロ」とあったから言うけど、Androidよりも、そのパクリ元かつプロプライエタリでクローズドなiOSのほうが、ごくごく普通にスマホ使ってるぶんには遥かに快適だからな？
そりゃAndroidはスマホというハードウェアを自由にいじり倒すには最適なんだろう。
でも多くの人にとっては電話とメールとWebとLINEとゲームとオーディオと写真や動画の鑑賞・撮影くらいがサクッと使えれば良くて、そういうありふれた用途に限定される反面、それらの使い勝手をパッキパキに洗練させた、iOSのほうが使いやすいわけで。
まあ、AndroidスマホがiPhone買えない貧乏人のイノベーションとして、特にまともな回線の整備がおぼつかない開発途上国の通信環境を、少なからず改善したことは大いに意味があるので、まあ認めて「やるか」って感じだけど。
話を戻すと、ぶっちゃけソフトウェアの場合は、自由になるために要求される水準が高すぎるんだわ。
それに無自覚、あるいは気づかないフリをしているOSS論者の多いこと多いこと。
そんなんだから、お前らの言ってることは
という風にしか聞こえないんだよ。
そこも含めて、OSSは思想そのものからして途方もなく左巻きってことには、もっと自覚的になるべき。
まあでも、なんだかんだ言って世の中は左翼によって良くなってきたことも事実なので、それだけでもOSSの意義は十分にあると思うけどね。
