ページへ戻る

+ Links

 印刷 

Is_OSASK_bad :: OSASK計画

osaskwiki:Is_OSASK_bad
ページ内コンテンツ

OSASKのここがだめなんじゃねーの？的質問への回答集 anchor.png

  • slashdotの人たちのあまりに今までの流れを知らない意見にがっかり。ということで作成。
    • まあそれまでを知らないから当然なんですが。
    • 他のところで見かけた質問もOKです。
  • 本文はKが独占的に編集。
  • 付け加えてほしい質問やその回答は、こめんと欄で教えてください。
  • 何でも回答すればいいわけではなく、明らかに的を外しすぎている基本的なことは、ここには書かない方針です。
    • どうしても質問の回答が知りたい人は、OSASK伝言板にかけばいいわけですしね。

あとは誰かが、

http://wiki.osask.jp/?Is_OSASK_bad の [xxxx]を見たか？

って書いてくれればいいわけです。

  • 関連リンク
    • navi：OSASK情報ナビゲータトップ
Page Top

目次 anchor.png

  • ［0001］ メモリレスアーキテクチャって他のOSと同じじゃん。名前が違うだけでしょ。
  • ［0002］ ドキュメントをもっと書いたほうがいいんじゃない。
  • ［0003］ OSASKって開発おそいね。
  • ［0004］ OSASKだってそのうちでかくて遅くなるさ。バージョンアップしていけば、過去の互換性を維持しつつ機能を追加していくことになるんだから。
  • ［0005］ なぜOSASKは（というかKは）、ユーザの意見を聞かないんだ。受け入れないんだ。公式に採用しないんだ。
  • ［0006］ OSASKはモノリシックカーネルなのか？ シェルやドライバなどに分かれていないのか？
  • ［0007］ ぐいぐい00で文字コード別に処理ルーチンがあるのは設計が悪いんじゃないか？
  • ［0008］ ぐいぐい00は関数の引数が多すぎて設計悪いんじゃないの？
  • ［0009］ ぐいぐい00の関数名がlib_で始まっているのはダサいよ。
  • ［0010］ OSASKのファイルサイズで圧縮した数字を使うのはずるい。
  • ［0011］ OSASKの実行ファイルヘッダは拡張性がない。○○もできない。
Page Top

回答集 anchor.png

  • 日付はこのページでの項目作成日です。

  • [0001](2003.08.21) メモリレスアーキテクチャって他のOSと同じじゃん。名前が違うだけでしょ。
    • [[［OSASK 2958］>OSASK:2958]]からの一連のスレッド

  • [0002](2003.08.21) ドキュメントをもっと書いたほうがいいんじゃない。
    • ドキュメントをたくさん書けばもっとプログラムを書けと言われ、プログラムばかり書いていたらもっとドキュメントを書けと言われる、これが今までの歴史です。
    • Kのページのhtmlだけで、1.3MBあります。たいていが質問に対する回答です。これをまとめ直すべきだという意見はありますが、そういうまとまった文章を作るとしたら、ゆうに1年は開発が止まりかねません。それにそんなことはKでなくても時間があれば誰でもできます。
    • このページが、そのまとめ直しのきっかけのつもりでもあります。

  • [0003](2003.08.21) OSASKって開発おそいね。
    • そうですね。
    • OSだけを作ればいいんじゃなくて、アプリも作っていますし、開発環境も作っています(ネイティブ、クロス共)。アプリを作るためのチュートリアルも書きますし、質問があれば答えていますし、漢字変換辞書まで作っています。
    • 既存のコンパチ品を作るという路線なら、既存のものがほぼそのまま使えるから開発は早くなるでしょう。設計も真似すればいいだけですし、説明もしなくていいですしね。OSASKはそうではないから開発は遅いです。でもその代わり、既存のどれよりも軽くて速くなっています。僕は既存と似たり寄ったりものに興味はなく、こうなることを分かっていて選んだ道です。だからあなたは不満かもしれませんが、僕は満足です。
    • （似たような文章を何度か書いた記憶があるのですが、どこに書いてあるのか発見したらこめんと欄で教えてください。）

  • [0004](2003.08.21) OSASKだってそのうちでかくて遅くなるさ。バージョンアップしていけば、過去の互換性を維持しつつ機能を追加していくことになるんだから。
    • OSASKはバージョンアップの際に、APIレベルで自分の過去のバージョンとの互換性を保つ理由はなにもありません。互換性がほしければ、APIブリッジかエミュレータドライバでカバーします。それがエミュレータOSというものです。
    • このAPIブリッジやエミュレータドライバは付けたり外したりできるものです。だからエミュレータやAPIブリッジを使わなくていいアプリだけを使うなら、将来にわたって常にOSASKはコンパクトかつ高速でいられます。むろん過去のソフトウェア資産を生かすときは、それなりには大きくなりますが、常に大きくなっているほかのOSよりはマシだというが、Kの見解なのです。
    • [[［OSASK 2097］>OSASK:2097]]からの一連のスレッド

  • [0005](2004.04.15) なぜOSASKは（というかKは）、ユーザの意見を聞かないんだ。受け入れないんだ。公式に採用しないんだ。
    • 理由１：みんなの意見を取り入れて、対立するときは多数決などで決定して、そうやってみんなが満足できるひとつのソフトウェアを作るやり方は有効です。しかし僕はOSASKではそうしないほうがいいと思いました。当初の信念を堅持し、それを貫き通し、これと共存できない意見は却下することで、設計に一貫性が保てて、「結局何が特徴なんだかよくわからないOS」になることを未然に防いでいます。もちろんプロジェクトリーダが優秀なら、みんなの意見を取り入れつつも、しっかりとした特徴をもつOSを開発することは十分に可能だろうと思います。ただ僕がOSASKにそれを求める気がないだけです。
    • 理由２：僕は僕に反対する意見が間違っているとは思いません。僕のOSASKの方針上は取り入れられないけれども、ぜひその可能性は探ってほしいです。ですから新規にプロジェクトを立ち上げるなり、OSASK計画からフォークするなりしてほしいです。そうすればお互いに競争関係になれて切磋琢磨できますし、たくさんのOSプロジェクトがあれば、一つや二つがトラブルで挫折しても全滅は避けられます。僕は別のOS開発プロジェクトにも微力ではありますが積極的に協力をしていきます。
    • 理由３：僕にとってのオープンソースは、「文句があるなら自分で直せ。ソースがあるんだから要望を無視しても文句を言うな。それでできないんだったらあきらめるか、もしくはできるようになるまで勉強してくれ。」という意味です。まあソースが公開されていなくても特許などで妨害しない限りは、文句を言われる筋合いではないとは思いますが、まあ僕としてはソースも公開しているのですから、要望を受け入れないからといって失礼には当たらないと思っています。要望を受け入れてもらえなくて、でも自分で勉強していつかやってやるぞ、という気にもならないとしたら、その要望は所詮その程度なのです。僕は自分の人生をかけて自分の要望をかなえることを優先しているだけで、ユーザの要望に応えるという契約をしたわけではありません。開発者はユーザの要望に応えるべきとか、開発者はユーザの増加を願っているはずだ、などの一方的な仮定はしないでください。僕は第一に僕自身のために作っているのであって、自分以外のユーザの利益はそれに次ぐものです。僕の方針が気に入らない人にまで使ってもらうつもりは毛頭ありません。

  • [0007](2004.05.04) ぐいぐい00で文字コード別に処理ルーチンがあるのは設計が悪いんじゃないか？ 他のOSはこんなにタコじゃないぞ。
    • 普通のOSの場合、特定の文字コードをAPIの標準にしています。日本語DOSはシフトJISですし、日本語WindowsはシフトJISとUnicodeです。OSASKでは複数の言語を混在表示したいという思想から、まずシフトJISの採用は候補から消えました。また将来的には超漢字級の文字種を扱わなければいけないという要請から（これはエミュレータOSである以上、避けられないことです。特定のOSのアプリ（超漢字のアプリ）を容易にはエミュレーションできないような設計は、エミュレータOSとしては失格でしょう）、Unicodeで満足するわけにもいきませんでした。OSASKは文字（厳密にはフォント片）を32bitの整数で表現します。
    • ここで普通のOS設計者のセンスだと、自分が考えた文字コード体系を押し付けて、それでプログラムを記述しろというのでしょう。自分の文字コード体系によほどの自信があるならそれでもいいですが、ぐいぐい00はそこまで自信過剰ではありません。また、実際問題としてたいていの日本語はシフトJISで書くと少ないバイト数で書けますし、現存する多くのテキストはシフトJISで書かれているでしょう。韓国語はEUCで書かれることが一般的です。これらからの文字コード変換を簡単に扱えるAPIをあらかじめ用意しておくことは、現実問題として理にかなっていると考えます。
    • なおCのライブラリ関数を見るとなにやらシフトJISの文字列表示APIがあるように錯覚するかもしれませんが、あれはstaticライブラリで、中身は文字コード変換API＋汎用文字表示APIを呼んでいるだけです。ASCIIの文字表示ルーチンがあるように見えるのも錯覚で、これも中身は汎用文字表示APIの呼び出しです。

  • [0008](2004.05.04) ぐいぐい00は関数の引数が多すぎて設計悪いんじゃないの？
    • [[［OSASK 2158］>OSASK:2158]]をまず読んでください。
    • で補足したいことは、つまり引数の数はうまくマクロを書けばどうにでもできるということです。これは結局C言語上の問題であって、APIそのものの問題ではありません。しかしそれでも、とにかく「現状では」使いにくいかもしれません。KのようなC言語のセンスのない者ではなく、センス良い人が<guigui00.h>に代わるものを作ってくれればと思っています。

  • [0009](2004.05.04) ぐいぐい00の関数名がlib_で始まっているのはダサいよ。構造体名はLIB_で始まる上にtypedefされてないし。これをやめるだけでもソースがすっきりするのに。
    • OSASKは完成したOSではなく今後APIが増えていくことが容易に予想されます。そこで考えていただきたいのですが、新しくできたAPI関数名が既存のアプリの関数名と衝突してしまうと、そのアプリのソースはわざわざ古い<guigui00.h>を持ち出してこないとmakeできなくなります。ということでそれを避けるために、関数名はlib_～にして、さらに構造体名はLIB_～にしてあるわけです。typedefしていないのは、どうせなら各自が自分のお気に入りのヘッダファイルを作り、そこでもっと使いやすい名前にtypedefしてほしいかなと。 
      /* "mylib.h" */
#include <guigui00.h>
#define lib_openwintitle(size, window) \
   lib_opentextbox(0x1000, 0, 0, size, 0, 0, 0, window, 0x00c0, 0)
typedef struct LIB_TEXTBOX TBOX;

  • [0010](2004.05.04) OSASKのファイルサイズで圧縮した数字を使うのはずるい。それならこっちはlzhやzipで圧縮したものと比較して当然だ。
    • 最初に言っておくと、これは一理あると思います。そういう比較でやり直すのもありです。
    • もう一方の見解として、やはりOSASKは圧縮をかけた状態で比較するべきだという考えも同時に持っています。一応紹介しておきます。
    • OSASKでは圧縮がかかったままで利用可能にするということを非常に重視しています。すなわち圧縮率よりも展開速度重視です。だからlzhとくらべて比較したらたぶんOSASKが不利でしょう。もしlzh圧縮した状態でもOSのデフォルトで実行可能なら、lzh圧縮での比較も意味があると思いますが、そうでないのならただ自分の都合の良い数字を出したいだけのような気もちょっとします（ただバイナリの複雑さの比較として圧縮後のサイズを使って比較することもあるので、その観点ではあえて圧縮して比較するのも意味があります。その場合は公平を期するために同じ圧縮アルゴリズムを使うといいでしょう）。
    • こんなふうに圧縮を意識してOSを設計している以上、圧縮した状態で比較するほうが現実的だと思います。特にOSASKの場合は圧縮するほうが一般的ですし。

  • [0011](2004.05.04) OSASKの実行ファイルヘッダは拡張性がない。だから小さくて当然だ。（もしくは）ファイルヘッダから想像するとOSASKの実行ファイルは○○ができないはずだ、云々。
    • そんなことはいえないと思います。OSASKの実行ファイルヘッダの考えは、まず非常に拡張性のある形式を考えて、その中で現状では使えなかったりなくてもそれほど困らない情報をカットした「圧縮形式」です。最初のシグネチャが圧縮形式であることを示すようになっています。まあヘッダのタイプが何種類かあると考えていただいてもいいです。
    • 複数の種類があるなんてずるいというかもしれませんが、たいていの場合で短い形式で済むのなら、そういう形式をわざわざ用意しておくのはむしろ合理的に思います。複数の形式を扱うせいで苦労するのはOSであって、その分OSがでかくなっているでしょう。ですからこの点を非難するならOSのサイズを非難するべきです。
Page Top

どこそこの掲示板にこんな質問があったよ、の報告欄 anchor.png

Page Top

新規の批判的意見欄 anchor.png

↑ここに書くよりはimpressionsなどのふさわしいところに書いてくれたほうが助かります

Page Top

こめんと欄 anchor.png

  • 誰か暇があったら、ML番号のところにへリンクを貼ってください。naviのように。 -- K 2003-08-21 (木) 02:45:20
  • MLをテキストを番号だけのファイルにして、InterWiki使ってリンクさせるとかどうだろ。 -- .mjt 2003-08-21 (木) 03:56:42
  • テスト　[[ML:1024]] I'm feeling luckyにすれば完璧かな。。 -- .mjt 2003-08-21 (木) 04:04:55
  • してみました。[[ML:3333]]のようなリンクを書くことでMLに直接ジャンプすることが出来ます。InterWikiNameにはまだ議論の余地が有ると思うのでリンクの置き換えはしません。というより、直接リンクしたほうがいいのは言うまでも無いです。楽な方法論。 -- .mjt 2003-08-21 (木) 04:20:16
  • かっこいい！ -- K 2003-08-21 (木) 04:21:03
  • MLのInterWikiNameはGoogleの検索機能を使っています。それなりの制度はありますが確実では有りません。 -- .mjt 2003-08-21 (木) 04:21:08
  • 内部的な目標は高くもって公開的な目標は1年くらいで到達可能なものにすれば煽られないのでは? -- 2003-08-21 (木) 16:21:25
  • ここは主に回答集の保守のための欄なので、ここに書いてある内容へレスをいただいても、ちょっと困ります。ということで、impressionsに引っ越し。 -- K 2003-08-21 (木) 16:29:58
  • あれ、ひょっとして、回答集への追加のリクエストだったのかな。その場合は、どこそこでこんな質問がありますが、どうですか？みたいに提案してください。とにかくここは質問コーナではありません。質問とかはimpressionsにどうぞ。 -- K 2003-08-21 (木) 16:44:57
  • 目次と解答欄で、内容がだぶるのは良くないので、#contentsなり、 ＆aname(hoge);使うべきかと。 -- 名無しさん 2004-04-15 (木) 21:00:23
  • いい案だと思うので、SandBoxで練習してみます。 -- K 2004-04-15 (木) 23:20:07
  • 内容のダブりを改称しないほうが読み手にやさしいので、このままにしました。また＃contensだとページをまたげないのでやめました（将来的に質問がうんと増えて、このページは目次だけになって、配下のページにジャンプする感じにしたいなと）。＃contentsの表示形式も僕の好みじゃないですし、目次は長い質問分を要約したいこともあるでしょうし。 -- K 2004-04-16 (金) 19:11:45
  • USBマウスが使えないところが決定的にダメなんじゃねーの＞OSASK -- 名無しさん 2004-05-07 (金) 16:03:39
  • あのう、ここにそういう意見を書かれても困ると2003.08.21 16:29:25に書いたのですが・・・。 -- K 2004-05-07 (金) 17:44:46
  • まあ良く出る話のような気もしますね。しかし素直にFAQを改定したほうがいいのでは？既出質問的に言えば「名前の付け方が悪い、別の意味にとられやすいものをよく独自の解釈で使っている。」って感じ？このページタイトル的には回答集よりむしろ批判点抽出のほうが似合いそうな気がする。 -- 名無しさん 2004-05-07 (金) 19:41:20
  • そういう意見もぜひimpressionsに書いてほしいです。ここはサマリページです。・・・が、まあこめんと欄をもう一個作れば親切かな。ということで加工開始。 -- K 2004-05-07 (金) 19:51:37
  • いや、まだわかってない気がする。「Is_OSASK_bad」を質問集ページとして「こめんと欄」がその保守用みたいな使い方だと結構紛らわしいのでは？って言いたかっただけなんだけどね。 -- 名無しさん 2004-05-07 (金) 21:11:31

↑上記2つに該当しない場合はここに書いてください

Last-modified: 2009-12-01 (火) 00:00:00 (JST) (319d) by k-tan
ページ別名: 未設定
ページ作成: k-tan
サイト管理: lina