  |
はてなキーワード: Linuxディストリビューションとは
最初のプログラミング言語として最もおすすめなのは、Bourne (Again) Shell。通称sh(bash)です。shはUNIXの標準的なシェルであり、bashはその拡張です。現在、多くのLinuxディストリビューションでは、bashが標準のシェルです。以下、これらのシェルの上で動作するコマンド言語およびそれによって作られたプログラムを指して「シェルスクリプト」と呼ぶことにします。
シェルスクリプトを最初のプログラミング言語におすすめする理由は、主にその実用性にあります。ほとんどのプログラミング学習者にとって、プログラミングで実現したいことは、「10000以下の素数を求める」などの教科書の課題のようなものではなく、大量のファイルから情報を検索するとか、インターネットから定期的にコンテンツを取得する、などの具体的なタスクのはずです。シェルスクリプトを使えば、後者のような実用的なプログラムを手軽に作成できます。一方、多くのプログラミング入門書には、制御構文などの細かい説明はあっても、後者のようなトピックはあまり載っていません。というのも、そのような機能は汎用的なプログラミング言語（C、Java、Python、Rubyなど）のコアの機能ではないからです。それらの機能は通常、ライブラリによって提供されます。したがって、汎用的なプログラミング言語で実用的なことをしようと思えば、外部モジュールの読み込みや、場合によってはパッケージ管理ツールを使ったライブラリのインストール方法などを学ばなければいけません。これらは、初学者にはいささかハードルが高いです（たとえば、Webフロントエンドのツール群を初学者が独学でインストールするなどは、ほぼ不可能でしょう）。一方、シェルスクリプトでは、grep、sed、awkのようなシェル上のユーティリティは全て、他の言語における組み込みの関数と同様です。つまり、モジュールのインポートや初期化処理などを行わずに使用することができます。
また、シェルスクリプトは、より本格的な言語やフレームワークへステップアップする過程としても非常に適しています。プログラミング入門書ではほとんど語られないことですが、プログラミングにおいては「プログラミング言語以外の技術」がプログラミング言語自体と同様に重要です。たとえば、ファイルやディレクトリを操作するには、OSのファイルシステムにアクセスしなければいけませんし、インターネットからコンテンツを取得するには、HTTPというネットワークプロトコルを知らなければいけません。シェルスクリプトを使う場合、それら「プログラミング言語以外の技術」を自然に利用します。それらは、プロのエンジニアを目指す上でも欠かせない知識です。また、多くのプログラミング言語では、制御構文を用いて変数の値を更新していくプログラミングスタイルが取られます。一方、シェルスクリプトでは、コマンドの出力を他のコマンドの入力に渡してデータを変換するプログラミングスタイルが取られます。後者のスタイルは、現代のソフトウェア開発では多くの場合、良いスタイルだと認識されています。シェルスクリプトを最初に学ぶことで、そのような良いプログラミングスタイルが身につきます。
シェルスクリプトを体系的に学ぶならば、次の文献が信頼できます。
大坂なおみの優勝で、ラケットが市販の物というので、かっこいいなって思った。
エースパイロットでもカラーリングだけ違うけど量産機乗ってるみたいなキャラがいい。
昔、BackTrackというペネトレーション特化型のLinuxディストリビューションがあったでしょ
ワナビーは憧れてた人が多かったんよ
なんか中二心をくすぐる雑誌とかで紹介されたりしてさ。
で、痛い話なんだけど
BackTrackっていう名前はかっこいい名前のまま憧れててさ
そのワナビーコミュニティの中では、時代はkaliみたいな雰囲気になってたんだけど(皆ちゃんと使いこなせてないけど)
「俺は使いやすいからあえて古いBackTrack使ってっから」って言ったりしてさ
完全のあれよね。古いシステムだけど技でそれを補う的なストーリーを演出してたよね。
実際はリポジトリも閉じちゃってバージョンアップできないし、カーネルのバージョンも何年も前のやつで止まってるのよね
でもそんな実際的な不具合は使いこなせてないからわかんないわけよ。
ぶっちゃけOpenSSLとか古いまんまだから、当時の新し目の暗号スイート使えないしさ。他にもブラウザも古いしさ。
ペネトレーションテストするOSがペネトレイタブルな状態ってすごい恥ずかしいよね。
まあ、当時はそんなのもわかるはずもなく、間違ったかっこいい演出しちゃたけど、あれは笑われてたなと思うよ。
はじかしぃ
現在では事実上、結果だけを見るのであればWindowsやMac、UNIX、Linuxなどで実現可能な課題は変わらない。
ただ、商業的に一定の予算を持って開発されたプロプライエタリなアプリケーションソフトウェアの中には、その実現可能な課題までの手順を省力化できるものが多い。
システムは実装の違いがあれどPOSIXを基準に実装され(サブシステムとしてPOSIX基準を実装している場合もある)、操作性はCommonUserAccessを参考として実装されていることが大半でOSが違ってもほぼ迷わず操作することが可能だ。
これまで、こう言った話題の類似したものに「iPhoneを求める子供へAndroid端末を買い与えるのは虐待か？」などがある。
今回の話題の発端となったエントリでは娘さんはCLIP STUDIO PAINTを求めるまで、Linuxディストリビューションの1つであるUbuntuをある程度は使えていた様子が見て取れる。
更にUbuntuではファイルのドラッグ＆ドロップによる移動操作などが当然可能であるが、娘さんはCLIの基礎的な操作まで行えるようになっており、PCスキルは同年代の子供よりも「できるほう」のようだ。
学校教育ではWindowsに触れていたようだが、Linuxの特性上デスクトップ環境を変更することによって見た目や操作性を著しく変化させることが可能で、娘さんからすると「パソコンによって見た目や操作性に多少の違いはあるもの」という認識だったようで、WindowsとLinuxのOSプラットフォームとしての違いをそこまで気にしていなかったようだ。
娘さんは今回の件でWindowsとLinuxの違いを認識していくようになるであろうが、この違いを経験することがプラスになるのかマイナスになるのかは、まだまだ稀少な事例過ぎて判別が難しいように思われる。
ただ、少なくともWindowsとLinuxの違いに良くも悪くもストレスは感じるのではないかと推測できる。
例を挙げれば、よく言われるようにLinuxにはPhotoshopやIllustratorは提供されておらず、ゲームの選択肢も少ない。逆にGIMPなどX Window Systemを前提に実装されているGIMPなどのアプリケーションはLinuxの方が軽く、パッケージ管理システムによるアプリケーション管理の容易さなどがある。
ちなみに父親はWindowsは高価なので誕生日プレゼントとしてならばWindowsを買える(おそらくCLIP STUDIO PAINTも同時購入)という道を示していた。
いい記事なのだが、いくつか反論や補足が必要だと思ったので書く。
このGPLのコンパイラとはGNU bisonやGCC(GNU Compiler Collection)について指しているのがほぼ明確なのでそれらについて書く。
確かに著作権法を元にしたライセンスは、ソフトウェアの出力結果に対してソフトウェアの著作権ライセンスが影響しないと解釈するのが妥当であるというのは正しい。
ただしこれは"著作権ライセンス"に限った話である、つまり著作権ライセンスでは不可能な制約がEULAなどでは課すことが可能であるということを意味する。
詳しくはGNUの書いた記事の"契約を元にしたライセンス"という項を読むと良い。以下に引用する。
https://www.gnu.org/philosophy/free-sw.html
ほとんどの自由ソフトウェアのライセンスは、著作権を元にしています。そして著作権によって課することができる要求には制限があります。もし、著作権を元にしたライセンスが、上記に記した自由を尊重するならば、まったく予期しない他の種類の問題があることはありそうもないでしょう(予期しないことはまま起こりますが)。しかし、ある自由ソフトウェアのライセンスは、契約を元にするもので、契約はもっと広範な制限を課することが可能です。これは、そのようなライセンスが、容認できないほど制限が強く、不自由でありうる、いくつもの形態がありうることを意味します。
わたしたちは、起こりうるすべてのことをあげることはできないでしょう。もし、契約を元としたライセンスが利用者を(著作権を元としたライセンスでは無理な形で)異常に制限するならば、そして、それがここで正当だと述べられていないのならば、それについて検討しないといけないでしょうし、そのライセンスは、不自由であると結論づけるかもしれません。
また元の記事の著者はGCCやbisonがGNU GPLのような強いコピーレフトで保護されたソフトウェアでも、それによって作成された著作物はGPLにならない(つまりコンパイラやパーサーのライセンスを継承しない)ことを根拠に考察しているようだが、実はbisonやGCCのGPLにはライセンスに対する例外が付属していることを考慮すべきである。
GCCやbisonの著作権保持者であるFree Software Foundationは著作権法の話をするとき、たいていアメリカ合衆国を想定しているがこれらの自由ソフトウェアが広く使われるあたって、著作権法とそれを元にしたライセンスが異なった解釈をされることがありうることをおそらく危惧している、そのため出力に対してソフトウェアのライセンスが影響しないことを確実にするためにこれらの例外を規定しているのではないか。
この二つの理由から、元記事の議論は世界中に対して広く配布するFLOSSディストリビューションでは(非常に残念ながら)鵜呑みに出来ないと私は考える。
加えて言えば、たとえフェアユースの規定が全世界的に利用できて、営利目的でなければ利用できたとしても、
自由.0: どんな目的に対しても、プログラムを望むままに実行する自由
(i.e. オープンソースの定義 6項 利用する分野に対する差別の禁止)
がある限り、そのような制限をディストリビューションは受け入れられないだろう。
またOracle vs GoogleのJavaのAPI訴訟はケースとしてはかなり特例であり、
一般に広く適用すればlibcすら当てはまるのではないかと私は思っている、
これを根拠にしてよいのならばそもそもコンピューター業界がひっくりかえるのではないか。
少なくともUbuntuのようなプロジェクトにおいて、私は断固反対である。
というのは現状ほぼすべてのWeb翻訳(例外があれば教えて欲しい)はプロプライエタリないし、それと同じ結果をもたらすSaaSSだからである。
Webブラウザを介して使う翻訳サービスはSaaSSの代表例であり、ユーザーがコンピューターの計算のコントロールを
持つべきであるという自由ソフトウェアの思想と明らかに相容れないものである。
このようなサービスを利用することの弊害として、(例えば)Google翻訳に翻訳処理の計算を依存することにより、ユーザーの入力をGoogleが常に把握することが挙げられます。
もちろんこれはあまり良いことではない。
多くのFLOSSシステムディストリビューションは自由なソフトウェアを主に入れるというガイドラインを持っている。
アーカイブのごく一部にnon-free(Ubuntuならrestricted/multiverse)なソフトウェアがあるが、
これは事実上妥協の産物であり、排除しても大した問題がないならば配布から除外することに多くのディストリビューション関係者は異論を挟まないだろう。
また例えばDebianはあるソフトウェアがDFSG(Debian フリーソフトウェアガイドライン)に適合するフリーソフトウェアであったとしても、それがガイドラインに適合しない著作物に依存する場合、contribというセクションに閉じ込めており、それは公式のシステムの一部ではないとしている。(建前ではcontrib/non-freeセクションはユーザー向けの付加サービスとされる)
Ubuntuコミュニティで新規に作られた著作物がコミュニティの哲学に反する物に依存するというのは、かなり致命的である。
たとえ奇跡が起こり、例外的にGoogle翻訳や一部のプロ用翻訳ツールがBSDライセンス(Launchpad上での翻訳用ライセンス)での出力を許したとしても決して褒められたものではない。
Ubuntuのbug#1に"Ubuntuソフトウェアは自由である。常にそうであったし、今後も常にそうである。自由ソフトウェアは万人に望むままの方法で使い、望むままの人間と共有できる自由を与える。この自由は多大な利点である。"とプロジェクト創始者であるマーク・シャトルワースが書いていることをよく考えるべきである。
https://bugs.launchpad.net/ubuntu/+bug/1
この反論を読んだ読者の中にはあまりにGNUプロジェクト寄りに思想が傾いていると思う者がいるかもしれないが、
いわゆる"Linuxディストリビューション"の中には数多くの重要なGNUソフトウェアがシステムの根幹をなす形で入り込んでおり(例えばGCC,bash,glibc etc...)
またUbuntuの派生元となったDebianの成立経緯にはやはりFSFが関わっている。
さらに言えば、システムの保守を手伝う人の中にはシステムがフリーだからボランティアで頑張っているという人もいると思う。(ほとんどではないかもしれない)
のでUbuntu周りの話に限ってはこういった観点で見てもよいと思ったので書いた。
先生、GeckoとアドオンはFirefoxではかなり中心的な部分を占めるものだと思います！
アドオン機能の無いFirefox、GeckoじゃないFirefoxを見限る信者は数多いと思います！
これらを横に置いてしまうと、話すことが激減してしまいます。
Gecko系（Seamonkey,Galeon,K-Meleon他）に対して同胞とみなしてる場合も多いと思います！
非IE連合的な纏まり（WHAT WGメンバの支持派とか）も形成されてると思います！
Macは、OS XがUNIXの一種であることから、UNIX-Linux-OS Xの緩い繋がりが形成されてる場合もあると思います！
Linuxディストリビューションも、パッケージシステム（deb系等）ごとに緩い繋がりが形成されてる場合があると思います！
こういう複数勢力にまたがる支持層はどうすればいいのでしょうか？
