2024-07-13「大吉祥寺.pm」の発表資料です。 参考となる情報にはPDF中からリンクをしていますが、資料中のリンクは Speaker Deck 上ではクリックできないので PDF をダウンロードしてご覧ください。
IBMのBookMasterでは、デフォルトを"vanilla"、特別な設定を"mocha"と呼んでいたらしい。 http://web.archive.org/web/20211224091337/ftp://public.dhe.ibm.com/printers/products/dcf/samples/B2H.HTM 「Chapter 6. Caveats and restrictions (what's supported and what's not!)」に以下の記述がある。 Conditional sections (.cs) and BookMaster's "vanilla" DVCF macros (.CONFIG and .WHEN) are supported, but not BookMaster's "mocha" DVCF macros (e.g. .USING,
はじめに 最近プログラマーとしてのキャリアに一区切りつけようと思っており、これまでのプログラミングの勉強の集大成となるブログを書きたくなったので書く。初めてプログラミングをして、フロントエンド開発をして、サーバーから値が返ってきたときは「どういう仕組みで値が返ってきたんだ?」と疑問に思っていた。ずっと理解したくて理解できていなかった。だからずっと勉強していた。そして最近になってようやく自分の言葉で説明できるようになった気がしたのでブログを書きたい。 2015 年版が自分の原点であり、この記事を書くモチベーションになった このような記事は実は過去に存在している。 FYI: https://blog.yuuk.io/entry/2015-webserver-architecture その記事はサーバーがどういう仕組みで動いていて、どのように進化し、2015 年に至るかを解説してくれた記事だ。自
echoコマンドの移植性が低い歴史的理由とPOSIXの改定方針 ~ 次期POSIXでbashのechoはPOSIX準拠になる! はじめに 実は bash に組み込まれた echo コマンドは POSIX に準拠していません。しかし 2023 年に予定されている次期 POSIX (Issue 8) の改定で、POSIX 準拠の動作になります。🎉🎉🎉 私のこの言い方には違和感を感じるかもしれません。「POSIX に違反している bash が問題点を修正して、POSIX に準拠させるのではないのか?」と。いいえ違います。POSIX 側が仕様を修正することで、bash は何も変更せずに過去のバージョンも含めて POSIX に準拠するようになります。面白いですね。 この記事は echo コマンドの移植性の問題の歴史を振り返りながら、それを例に POSIX 標準化団体がどのような方針で標準規格を
sudo su と sudo -s はほぼ同じ。実行されるシェルが異なることがある。 sudo su - と sudo -i もほぼ同じ。環境変数のクリア的な意味だと sudo su - の方が強い。 以下は別に読まなくてもいい。 su 別のユーザーでシェルを実行するコマンド。自分は「す」とか「えすゆー」とかと呼んでる。 元は super user とか switch user とか substitute user の略だったらしい。 デフォルトでは root になるが、引数でユーザー名を指定するとそのユーザーになる。 新ユーザーのデフォルトのシェルとして設定されているシェルが実行される。 入力するパスワードは新ユーザーのパスワード。 ~% su Password: (rootのパスワード) root@hostname:/home/tmtms# id uid=0(root) gid=0(r
この記事は自作OS Advent Calendar 2020 7日目の記事となります。 はじめに 現在のオープンソースOSは、たとえばLinux開発ボードであればボードベンダーから移植済みのLinux環境が提供されたり、たとえばNetBSDであればクロスコンパイル環境が整備済みでドキュメントも用意されていて、最低限の移植作業で移植が完了したりします。 ぼくがNetBSDを移植した当時(1993年)はそうではありませんでした。ドキュメントもなくいろいろ手探りで、それも一人でやらざるを得ませんでした。苦労話のことは置いておいて、技術的にどういう物が用意され何を調べてどういう手順で移植していったかを記録に残せればと思います。(って前置きした割に苦労話が多いような気がします、すみません) かなり昔の話なので、けっこう忘れてることも多く、微妙に記憶が間違っていたりすることも、順番が前後していることも
Windows 10 Homeでも使える本物のDockerの提供開始 DockerのコンテナリポジトリであるDocker Hubでは、歴史的な経緯からWindows ServerやIISが提供されている。本物のDocker環境「Docker Desktop for Windows」との関係などを整理する。 コンテナ仮想化を用いたアプリケーションの開発/実行環境である「Docker(ドッカー)」を試したことはあるだろうか。Windowsユーザーの場合、Hyper-VやVMwareといった仮想マシン環境は使ったことがあっても、Dockerを普段から利用しているという人はまだ少ないだろう。手元のWindows環境で試してみたかったけれど、「何やら複雑そうで手が出なかった」という人もいると思う(これはWindows OS上のDockerのサポートが二転三転したことも一因だろう。詳しくは後述)。 し
目次 はじめに 本ペーパーで取り上げる内容 歴史と技術的な背景 「UNIX」の意味 Linuxとオープンソース・プログラミングの到来 Bell Labsコードベース 争点のUNIX派生物間の関係 各社の歴史 オープンソースに関するSCOの歴史 「エンタープライズ・スケーラビリティ」の意味 SCO/Calderaはその歴史と立場を偽っている SCO/Calderaが重要な企業であったという主張は偽りである SCO/Calderaが唯一のIntel UNIXベンダだったという主張は偽りである SCO/CalderaはUNIXに対する権利の範囲を偽っている SCO/CalderaのUNIXスケーラビリティ技術を所有しているという主張には説得力がない SCO/Calderaは自身の役割を無視して、開発の動機付けを行うどころか、それを非難してはばからない SCO/Calderaは不正な表現でオープン
多言語化対応における TypeScript の型定義を通して開発のしやすさについて考えた / TSKaigi TypeScript Multilingualization
git は、コードベースの発展過程を記録し、開発者間の協同作業を効率化する強力なツールです。でも、記録対象のリポジトリがとてつもなく巨大なものになったときは何が起こるのでしょうか? この記事では、いくつかの異なる意味での巨大化に正しく対処するためのアイデアと手法を少し紹介してみたいと思います。 二種類の 巨大なリポジトリ よく考えてみると 巨大なリポジトリ が生ずる理由はおおまかに言って二つあります: 非常に長い期間にわたって履歴が積み上げられた (プロジェクトが非常に長い期間継続的に拡大を続けたために開発成果が積み重なった) 場合 巨大でしかも履歴の記録が必要なバイナリ データが存在し、それがコードに反映される場合 その両方の場合 即ち、リポジトリの巨大化は二つの異なる方向に向かって起こることになります。それは、作業ディレクトリのサイズ (即ち直近のコミットのサイズ) の問題と全体の履歴
「GNU/Linux Distribution Timeline」は、1992年に公開された世界最初のLinuxディストリビューション「SLS」以来の、膨大なLinuxディストリビューションの歴史を年表形式で表したものです。(ソースコード、Hacker News)。 例えばメジャーなディストリビューションの一つRedHatからは、こんなにたくさんの子孫が派生していることがわかります。検索してみたら、KondaraとかVineとかLinuxメインのディストリビューションもしっかり含まれていたので、かなり網羅率は高そうです。 最近人気のたかいUbuntuからもたくさん分岐しています。 膨大すぎて一覧表示できないのが難点ですが、Linuxマニアならおさえておきたいタイムラインですね(汗
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く