アカウント名:
パスワード:
ログアウトしたユーザーのプロセスは終了するのが本来の形。
その昔UNIXマシンを多数のユーザで共有していた頃は、「バックグラウンドでプログラムを動かしたままログアウトするな！リソース不足になるだろ！」ってよく怒られたものでした・・・
だってコンパイル終わらないんだもん
いやいや、今回の件では、daemon(3) 呼んだプロセスまで殺されるんですよ。デーモンプロセスは、ユーザー起動であっても、本来は殺されない方が筋。
こういう非互換な変更を平気で入れてくるってことは、systemdのメンテナーは、従来から存在するプログラムとの互換性は気にしないってポリシーなんでしょうね。今後も同様な問題がたびたび起きそうな予感。
伝統的なinit(8)の代わりとして十分モダンで効率的で、かつsystemdのようにシステム全体をLinux cgroup(3)に過度に依存させるようなことを無神経に強要させない、穏やかな設計・実装方針のものが主流に置き換わって欲しい
プロセスを残すのにSIGHUPの無視を使うなんてのが筋の悪いやり方ですよね。
systemdはログインセッション毎にコンテナを作るので、ログアウト後もコンテナが残り続けるなんてのも問題。
> プロセスを残すのにSIGHUPの無視を使うなんてのが筋の悪いやり方ですよね。
どういう意味で筋が悪いのでしょうか？SIGHUPは、セッションの終了を示すシグナルですから、セッション終了時にプロセスが終了しないようにするためにSIGHUPを無視するというのは、ストレートな方法だと思うんですが…まあイマドキのプロセス構成だと、セッション終了時にSIGHUPが飛んでこないことが多いと思いますが、むしろそれはSIGHUP投げるように直すべきじゃないのかな。
OS設計のあるべき姿の話でしょ。
①あるユーザーセッションが消費する計算機資源は、そのユーザーセッションとライフサイクルを一致させるべき⇒プロセスも、他の計算機資源等同様、ユーザーがログアウトするのに合わせて終了するのがあるべき姿
②マルチユーザーシステムにおいては、プロセスは他のプロセスやシステムと協調的に動作すべき⇒システムからの終了シグナルを受けた場合は、それに従って終了するのがあるべき姿
伝統的なUNIXは、これらを無視した「行儀の悪い」スタイルが標準的な方法になっている。
現行のUNIXのやり方しか知らず、他のシステムの知識もないから、あるべき姿が見えないんだよ。
> ①あるユーザーセッションが消費する計算機資源は、そのユーザーセッションとライフサイクルを一致させるべき> ⇒プロセスも、他の計算機資源等同様、ユーザーがログアウトするのに合わせて終了するのがあるべき姿
もともとUNIXはそうなってますよ。セッションを管理するセッションリーダーをUNIXカーネルが認識し、セッションリーダーが死んだら、その子プロセスにはカーネルがSIGHUPシグナルを送って殺す仕組みがちゃんとあります。
> ②マルチユーザーシステムにおいては、プロセスは他のプロセスやシステムと協調的に動作すべき> ⇒システムからの終了シグナルを受けた場合は、それに従って終了するのがあるべき姿
これも当然ですね。そのためにSIGHUPシグナルが定義されてます。
> 伝統的なUNIXは、これらを無視した「行儀の悪い」スタイルが標準的な方法になっている。
伝統的なUNIXというよりは、GUIユーザー環境が、行儀が悪くできているというのが正しい表現だと思います。本来なら、GUIユーザー環境のセッションマネージャは、配下のプロセスが、セッション終了時にSIGHUPシグナルを受け取るように手配すべきでしょう。これは、setsid(2) したプロセスがGUIユーザー環境のプロセスを起動するようにするだけで済むので簡単なことです。そうせずに、daemon(3) API を呼んでデーモン化したプロセスまで殺すような変更をするから、今回、非難を受けているわけです。
> 現行のUNIXのやり方しか知らず、他のシステムの知識もないから、あるべき姿が見えないんだよ。
伝統的UNIXのやり方を知らないのは、はたしてどちらの側なのでしょうか…
わかってない。今回のsystemdがdeamonを殺すことについてはそのとおりだけど、元コメの「本来の姿」とはそのことを指しているわけじゃない。そもそものUNIXの設計として、SIGHUPシグナルをプロセスが無視できて、プロセスがそれを無視すると、あろうことかユーザーがログアウトしても残ってしまうって言うのが、OS設計のあるべき姿として問題だと指摘している。
Windowsみたいに、サービスでなければログアウト時にそのユーザーセッションのプロセスは強制的に全部殺すのがあるべき姿。
> Windowsみたいに、サービスでなければログアウト時にそのユーザーセッションのプロセスは強制的に全部殺すのがあるべき姿。
いやいや、それはありえない。GUIも持ってるけど、本業は計算処理で、裏で計算するし、ログアウト後、ログインし直したらGUIが復活するプログラムだってあっていい筈だし作れますよ。CLIのそういうプログラムなら沢山あるわけで。
実際、tmux や screen のユーザーがこれだけ沢山いるってのは、そういう、複数のセッションにまたがる作業の要求があるってことの証明ですよ。
あなた、Windows至上主義になっていて、本来できてしかるべきことができなくなってるってことが見えてないと思いますよ。囚人が檻の存在を自慢しているようにしか見えません。
じゃあwindows使ってればいいじゃない、そういうのが望まれるユーザーやマシンにはさこっちにまで枷嵌めにこないでよ押し付けがましいんだよ
一般的にはログイン状態を維持したままユーザーを切り替える機能があるんでGUIでもCUIでもそっちを使えばいい。
ユーザーから独立して動かすべき物を、普通のユーザーがボコボコ作って放置できる「だらしない」システムが正しい？
OSはただのランチャーですか？
> 一般的にはログイン状態を維持したままユーザーを切り替える機能があるんでGUIでもCUIでもそっちを使えばいい。
tmux や screen での経験から考えると、それじゃ全然機能不足ですね。少なくとも、物理端末から切り離して、別の物理端末から利用を継続できる仕組みが必要です。
remote desktop の場合、別ユーザーで接続しようとすると元のユーザーはログアウトくらうから機能が足りませんね。
Windowsのように、アプリケーションとセッションが切り離し不能だってのは制限でしかないと思います。デフォルトでは結びついているけど明示すれば切り離しできるUNIXモデルの方がずっと柔軟だし、それでも何の問題もないのに、わざわざ柔軟性を失いたいという根拠がよく分かりませんね。
> ユーザーから独立して動かすべき物を、普通のユーザーがボコボコ作って放置できる「だらしない」システムが正しい？
デフォルトでは、セッション終了時に殺すべきでしょうね。そのための仕組みは、UNIXの最初期から存在するし、最初期からセッション終了時に殺すようになってました。その仕組みを使ってないGUI環境があるのは問題です。
しかし、殺さないで残しておく仕組みも当然必要です。そのための仕組みが存在しないことを自慢するのは理解できませんね。
檻だなんだはどっちもどっちな気がするけど。
Windowsで言えばリモートデスクトップで×ボタンで閉じた状態と同じような状況をつくるためにtmuxとかscreen使ってるわけですよね(それ以外の機能もたくさんあるが、この話題で困る機能としては)。一時中断であってログアウトしてない状況を作りたい、そのための何かがありさえすればいいんじゃないの。ログアウトのあるべき論を話しててもしょうがないような。
Windowsでも複数セッションにまたがる…はたまにある。すごい長いインストールだとか。開発中のサーバー起動（まだサービスにする前段階）とか。なので「切断切れたら強制ログオフされるようになりました」みたいな変更は困る。Windowsでもおなじ。
# ところでtmuxとかscreenが放置されちゃってて不便みたいなことってあんまりないんですかね。
なんだかよくわからないスレッドだが，SIGHUPを無視するプロセスがいなきゃ問題ないし，無視するプロセスがいるっつーんならsystemdで殺されないように勝手に動くプロセスだってすぐに出てくるだろ．なんつーか，簡単に解決できる問題をむつかしくした上に，面倒になったからブルドーザーで全部壊してるようにしか見えない．
1. SIGHUPは端末の終了であって、デスクトップのセッションの終了とは別。2. プロセスの死に順によっては親子関係が失われてSIGHUPは届かない。
> 1. SIGHUPは端末の終了であって、デスクトップのセッションの終了とは別。
もともと端末の切断用だし、今でもそれが主な用途だというのは正しい。
しかし、セッションの概念および setsid(2)/getsid(2) システムコールの導入以降は、端末とは全く無関係であっても、orphaned process group に対しては、カーネルが SIGHUP を送ることが定められた。つまり、セッションの概念の導入以降は、必ずしも端末の切断とは関係なくても、SIGHUP はセッション終了時に送られるシグナルに変わったわけ。
これはもちろん、ジョブコントロールのマスターとなって動くシェルの
それはWindowsのエディションによる機能制限です。Windows Serverならデフォルトで2セッション同時に動かせます。さらに、リモートデスクトップCALを買って、機能を有効化すれば、ライセンスの許す限りいくつでもセッションを作れるようになります。
Windowsは普通にそうなってるよな。必要ならmachine-wideなサービスを作れっていうスタンス。systemdもそれを目標としてるんだろう。古参連中が理解できないだけで。
新しい酒は新しい革袋に。systemd-compatibleなユーザランドだけに浄化した新しいディストロでやってくれ。Windowsでは当たり前だからといって/bin, /bin/sbin, /usr/bin, /usr/share/binのバイナリに全部".exe"を付けたりはしないだろ?
Windowsでは当たり前だからといって/bin, /bin/sbin, /usr/bin, /usr/share/binのバイナリに全部".exe"を付けたりはしないだろ?
よ、呼んだ？
多分、付けた方がいい。
> 多分、付けた方がいい。
いったいどういう利点があるんでしょう？
ちなみに欠点はすごく沢山あります。一番ヤバいのは、プロセス起動するソフトウェアを全部書き換える必要が生じるところですね。今回の systemd とは比べ物にならないくらい悲惨に、互換性が壊滅します。
Cygwin の場合、現実問題として、.exe 付いてても大してメリットはない気がするんだけど、逆に .exe 付いてるからと言って大してデメリットが生じてるわけでもないよ。
間に噛んでる Cygwin 層のシステムコールが面倒見てくれるからユーザーが書くプログラムでは.exe 付いてることを意識しなければいけない場面はほとんどないしね。
いや cygwin は Linux じゃないから、「cygwin ではデメリットない」て話はオフトピックですよ。Linux じゃシステムコール層がそういう面倒みてくれないし。
それにメリット説明してないし。
そうは読めなかったなぁ。
って書いてあったから、てっきり Windows の /bin その他の話かと。
Cygwin でのメリットは、explorer から見たときに実行ファイルだって分かり易いとか、cmd や explorer から実行できるとかその辺かな？そういう使い方はあまりしないので、大したメリットではないけど、最低限 mintty とか bash とかは .exe 付いてないと使えない気がする。
まず、ファイルが実行可能かどうかはどこかに情報を書き込まなければゴミになる。ファイル名に書く必要はないがファイル名に書くのは互換性の点で優れている。
そもそも、Unixのデスクトップだって、.txtみたいな拡張子を導入して、拡張子が.txtだったらgeditで開いて、.htmlだったらfirefoxで開く、ということをごく当たり前にやってる。makeだって、拡張子の.oとか.cとか.soとかに依存した文化がある。実行ファイルにだけ拡張子をつけないのは悪しき慣例だよ。一端書き換えたら、全体的な複雑さは減る。
> ファイルが実行可能かどうかはどこかに情報を書き込まなければゴミになる。ファイル名に書く必要はないがファイル名に書くのは互換性の点で優れている。
Windowsとの互換性に優れているという意味なのでしょうか？でも、今や計算機の数ではiPhoneやAndroidの方が圧倒的に多いわけで、iPhoneやAndroidはLinuxと同様に、ファイルシステム自身に実行形式属性を記録して持っているわけです。むしろWindowsがiPhone/Android/MacOS/Linuxと同じ方法に変更した方が、互換性において圧倒的に優れているでしょう。
> 実行ファイルにだけ拡張子をつけないのは悪しき慣例だよ。一
プログラムで言うと○○リークとおなじですからね。今までが異常でUnixの嫌いなとこの１つでした。
initスクリプトもI/Fシカトが多くてイヤだったけどね。このあたりが組織ごとにバラバラ独自ルール、時によっては真逆の方針生んでたり、バカじゃね？と思ったもんです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stableって古いって意味だっけ？ -- Debian初級
本来はこっちが正しい (スコア:0)
ログアウトしたユーザーのプロセスは終了するのが本来の形。
Re:本来はこっちが正しい (スコア:1)
その昔UNIXマシンを多数のユーザで共有していた頃は、
「バックグラウンドでプログラムを動かしたままログアウトするな！リソース不足になるだろ！」
ってよく怒られたものでした・・・
Re:本来はこっちが正しい (スコア:1)
だってコンパイル終わらないんだもん
Re:本来はこっちが正しい (スコア:1)
いやいや、今回の件では、daemon(3) 呼んだプロセスまで殺されるんですよ。
デーモンプロセスは、ユーザー起動であっても、本来は殺されない方が筋。
こういう非互換な変更を平気で入れてくるってことは、systemdのメンテナーは、従来から存在するプログラムとの互換性は気にしないってポリシーなんでしょうね。
今後も同様な問題がたびたび起きそうな予感。
Re: (スコア:0)
伝統的なinit(8)の代わりとして十分モダンで効率的で、かつsystemdのようにシステム全体をLinux cgroup(3)に過度に依存させるようなことを無神経に強要させない、穏やかな設計・実装方針のものが主流に置き換わって欲しい
Re: (スコア:0)
プロセスを残すのにSIGHUPの無視を使うなんてのが筋の悪いやり方ですよね。
systemdはログインセッション毎にコンテナを作るので、ログアウト後もコンテナが残り続けるなんてのも問題。
Re: (スコア:0)
> プロセスを残すのにSIGHUPの無視を使うなんてのが筋の悪いやり方ですよね。
どういう意味で筋が悪いのでしょうか？
SIGHUPは、セッションの終了を示すシグナルですから、セッション終了時にプロセスが終了しないようにするためにSIGHUPを無視するというのは、ストレートな方法だと思うんですが…
まあイマドキのプロセス構成だと、セッション終了時にSIGHUPが飛んでこないことが多いと思いますが、むしろそれはSIGHUP投げるように直すべきじゃないのかな。
Re: (スコア:0)
OS設計のあるべき姿の話でしょ。
①あるユーザーセッションが消費する計算機資源は、そのユーザーセッションとライフサイクルを一致させるべき
⇒プロセスも、他の計算機資源等同様、ユーザーがログアウトするのに合わせて終了するのがあるべき姿
②マルチユーザーシステムにおいては、プロセスは他のプロセスやシステムと協調的に動作すべき
⇒システムからの終了シグナルを受けた場合は、それに従って終了するのがあるべき姿
伝統的なUNIXは、これらを無視した「行儀の悪い」スタイルが標準的な方法になっている。
現行のUNIXのやり方しか知らず、他のシステムの知識もないから、あるべき姿が見えないんだよ。
Re:本来はこっちが正しい (スコア:1)
> ①あるユーザーセッションが消費する計算機資源は、そのユーザーセッションとライフサイクルを一致させるべき
> ⇒プロセスも、他の計算機資源等同様、ユーザーがログアウトするのに合わせて終了するのがあるべき姿
もともとUNIXはそうなってますよ。
セッションを管理するセッションリーダーをUNIXカーネルが認識し、セッションリーダーが死んだら、その子プロセスにはカーネルがSIGHUPシグナルを送って殺す仕組みがちゃんとあります。
> ②マルチユーザーシステムにおいては、プロセスは他のプロセスやシステムと協調的に動作すべき
> ⇒システムからの終了シグナルを受けた場合は、それに従って終了するのがあるべき姿
これも当然ですね。
そのためにSIGHUPシグナルが定義されてます。
> 伝統的なUNIXは、これらを無視した「行儀の悪い」スタイルが標準的な方法になっている。
伝統的なUNIXというよりは、GUIユーザー環境が、行儀が悪くできているというのが正しい表現だと思います。
本来なら、GUIユーザー環境のセッションマネージャは、配下のプロセスが、セッション終了時にSIGHUPシグナルを受け取るように手配すべきでしょう。これは、setsid(2) したプロセスがGUIユーザー環境のプロセスを起動するようにするだけで済むので簡単なことです。
そうせずに、daemon(3) API を呼んでデーモン化したプロセスまで殺すような変更をするから、今回、非難を受けているわけです。
> 現行のUNIXのやり方しか知らず、他のシステムの知識もないから、あるべき姿が見えないんだよ。
伝統的UNIXのやり方を知らないのは、はたしてどちらの側なのでしょうか…
Re: (スコア:0)
わかってない。今回のsystemdがdeamonを殺すことについてはそのとおりだけど、元コメの「本来の姿」とはそのことを指しているわけじゃない。
そもそものUNIXの設計として、SIGHUPシグナルをプロセスが無視できて、プロセスがそれを無視すると、
あろうことかユーザーがログアウトしても残ってしまうって言うのが、OS設計のあるべき姿として問題だと指摘している。
Windowsみたいに、サービスでなければログアウト時にそのユーザーセッションのプロセスは強制的に全部殺すのがあるべき姿。
Re:本来はこっちが正しい (スコア:1)
> Windowsみたいに、サービスでなければログアウト時にそのユーザーセッションのプロセスは強制的に全部殺すのがあるべき姿。
いやいや、それはありえない。
GUIも持ってるけど、本業は計算処理で、裏で計算するし、ログアウト後、ログインし直したらGUIが復活するプログラムだってあっていい筈だし作れますよ。
CLIのそういうプログラムなら沢山あるわけで。
実際、tmux や screen のユーザーがこれだけ沢山いるってのは、そういう、複数のセッションにまたがる作業の要求があるってことの証明ですよ。
あなた、Windows至上主義になっていて、本来できてしかるべきことができなくなってるってことが見えてないと思いますよ。
囚人が檻の存在を自慢しているようにしか見えません。
Re: (スコア:0)
じゃあwindows使ってればいいじゃない、そういうのが望まれるユーザーやマシンにはさ
こっちにまで枷嵌めにこないでよ押し付けがましいんだよ
Re: (スコア:0)
一般的にはログイン状態を維持したままユーザーを切り替える機能があるんでGUIでもCUIでもそっちを使えばいい。
Re: (スコア:0)
ユーザーから独立して動かすべき物を、普通のユーザーがボコボコ作って放置できる「だらしない」システムが正しい？
OSはただのランチャーですか？
Re: (スコア:0)
> 一般的にはログイン状態を維持したままユーザーを切り替える機能があるんでGUIでもCUIでもそっちを使えばいい。
tmux や screen での経験から考えると、それじゃ全然機能不足ですね。
少なくとも、物理端末から切り離して、別の物理端末から利用を継続できる仕組みが必要です。
remote desktop の場合、別ユーザーで接続しようとすると元のユーザーはログアウトくらうから機能が足りませんね。
Windowsのように、アプリケーションとセッションが切り離し不能だってのは制限でしかないと思います。
デフォルトでは結びついているけど明示すれば切り離しできるUNIXモデルの方がずっと柔軟だし、それでも何の問題もないのに、わざわざ柔軟性を失いたいという根拠がよく分かりませんね。
Re: (スコア:0)
> ユーザーから独立して動かすべき物を、普通のユーザーがボコボコ作って放置できる「だらしない」システムが正しい？
デフォルトでは、セッション終了時に殺すべきでしょうね。
そのための仕組みは、UNIXの最初期から存在するし、最初期からセッション終了時に殺すようになってました。
その仕組みを使ってないGUI環境があるのは問題です。
しかし、殺さないで残しておく仕組みも当然必要です。
そのための仕組みが存在しないことを自慢するのは理解できませんね。
Re: (スコア:0)
檻だなんだはどっちもどっちな気がするけど。
Windowsで言えばリモートデスクトップで×ボタンで閉じた状態と同じような状況をつくるためにtmuxとかscreen使ってるわけですよね(それ以外の機能もたくさんあるが、この話題で困る機能としては)。
一時中断であってログアウトしてない状況を作りたい、そのための何かがありさえすればいいんじゃないの。
ログアウトのあるべき論を話しててもしょうがないような。
Windowsでも複数セッションにまたがる…はたまにある。すごい長いインストールだとか。開発中のサーバー起動（まだサービスにする前段階）とか。なので「切断切れたら強制ログオフされるようになりました」みたいな変更は困る。Windowsでもおなじ。
# ところでtmuxとかscreenが放置されちゃってて不便みたいなことってあんまりないんですかね。
Re: (スコア:0)
なんだかよくわからないスレッドだが，SIGHUPを無視するプロセスがいなきゃ問題ないし，無視するプロセスがいるっつーんならsystemdで殺されないように勝手に動くプロセスだってすぐに出てくるだろ．なんつーか，簡単に解決できる問題をむつかしくした上に，面倒になったからブルドーザーで全部壊してるようにしか見えない．
Re: (スコア:0)
1. SIGHUPは端末の終了であって、デスクトップのセッションの終了とは別。
2. プロセスの死に順によっては親子関係が失われてSIGHUPは届かない。
Re: (スコア:0)
> 1. SIGHUPは端末の終了であって、デスクトップのセッションの終了とは別。
もともと端末の切断用だし、今でもそれが主な用途だというのは正しい。
しかし、セッションの概念および setsid(2)/getsid(2) システムコールの導入以降は、端末とは全く無関係であっても、orphaned process group に対しては、カーネルが SIGHUP を送ることが定められた。
つまり、セッションの概念の導入以降は、必ずしも端末の切断とは関係なくても、SIGHUP はセッション終了時に送られるシグナルに変わったわけ。
これはもちろん、ジョブコントロールのマスターとなって動くシェルの
Re: (スコア:0)
remote desktop の場合、別ユーザーで接続しようとすると元のユーザーはログアウトくらうから機能が足りませんね。
それはWindowsのエディションによる機能制限です。Windows Serverならデフォルトで2セッション同時に動かせます。さらに、リモートデスクトップCALを買って、機能を有効化すれば、ライセンスの許す限りいくつでもセッションを作れるようになります。
Re: (スコア:0)
Windowsは普通にそうなってるよな。必要ならmachine-wideなサービスを作れっていうスタンス。
systemdもそれを目標としてるんだろう。古参連中が理解できないだけで。
Re: (スコア:0)
新しい酒は新しい革袋に。systemd-compatibleなユーザランドだけに浄化した新しいディストロでやってくれ。
Windowsでは当たり前だからといって/bin, /bin/sbin, /usr/bin, /usr/share/binのバイナリに全部".exe"を付けたりはしないだろ?
Cygwin (スコア:2)
よ、呼んだ？
uxi
Re: (スコア:0)
多分、付けた方がいい。
Re: (スコア:0)
> 多分、付けた方がいい。
いったいどういう利点があるんでしょう？
ちなみに欠点はすごく沢山あります。
一番ヤバいのは、プロセス起動するソフトウェアを全部書き換える必要が生じるところですね。
今回の systemd とは比べ物にならないくらい悲惨に、互換性が壊滅します。
Re:本来はこっちが正しい (スコア:2)
Cygwin の場合、
現実問題として、.exe 付いてても大してメリットはない気がするんだけど、
逆に .exe 付いてるからと言って大してデメリットが生じてるわけでもないよ。
間に噛んでる Cygwin 層の
システムコールが面倒見てくれるから
ユーザーが書くプログラムでは
.exe 付いてることを意識しなければいけない場面はほとんどないしね。
uxi
Re: (スコア:0)
いや cygwin は Linux じゃないから、「cygwin ではデメリットない」て話はオフトピックですよ。
Linux じゃシステムコール層がそういう面倒みてくれないし。
それにメリット説明してないし。
Re:本来はこっちが正しい (スコア:2)
そうは読めなかったなぁ。
って書いてあったから、てっきり Windows の /bin その他の話かと。
Cygwin でのメリットは、explorer から見たときに実行ファイルだって分かり易いとか、cmd や explorer から実行できるとかその辺かな？
そういう使い方はあまりしないので、大したメリットではないけど、最低限 mintty とか bash とかは .exe 付いてないと使えない気がする。
uxi
Re: (スコア:0)
まず、ファイルが実行可能かどうかはどこかに情報を書き込まなければゴミになる。ファイル名に書く必要はないがファイル名に書くのは互換性の点で優れている。
そもそも、Unixのデスクトップだって、.txtみたいな拡張子を導入して、拡張子が.txtだったらgeditで開いて、.htmlだったらfirefoxで開く、ということをごく当たり前にやってる。makeだって、拡張子の.oとか.cとか.soとかに依存した文化がある。実行ファイルにだけ拡張子をつけないのは悪しき慣例だよ。一端書き換えたら、全体的な複雑さは減る。
Re: (スコア:0)
> ファイルが実行可能かどうかはどこかに情報を書き込まなければゴミになる。ファイル名に書く必要はないがファイル名に書くのは互換性の点で優れている。
Windowsとの互換性に優れているという意味なのでしょうか？
でも、今や計算機の数ではiPhoneやAndroidの方が圧倒的に多いわけで、
iPhoneやAndroidはLinuxと同様に、ファイルシステム自身に実行形式属性を記録して持っているわけです。
むしろWindowsがiPhone/Android/MacOS/Linuxと同じ方法に変更した方が、
互換性において圧倒的に優れているでしょう。
> 実行ファイルにだけ拡張子をつけないのは悪しき慣例だよ。一
Re: (スコア:0)
プログラムで言うと○○リークとおなじですからね。
今までが異常でUnixの嫌いなとこの１つでした。
initスクリプトもI/Fシカトが多くてイヤだったけどね。
このあたりが組織ごとにバラバラ独自ルール、時によっては真逆の方針生んでたり、バカじゃね？と思ったもんです。