アカウント名:
パスワード:
同一マシンで走らせた場合、Linux版動作速度が遅くないですか?Windows用のものと比べると。 この辺が最新バージョンでは改善されると良いのですが。
いやマジで [slashdot.org]。
make -f client.mk build MOZ_PROFILE_GENERATE=1
でビルドした後、ビルドしたツリーの場所で実行する./src/dist/bin/firefoxと*.{gcda, gcno}がビルドしたツリーにできます。 そのあと、*.{o,a,so}を削除して、
make -f client.mk build MOZ_PROFILE_USE=1
とすれば-fuse-profileオプションでmakeしてくれますので、プロファイルに基づく最適化がされたバイナリが完成します。
IA32はレジスタの本数が少ないので、profileによってどの変数をレジスタに割り当てるべきかという判別だけでも結構性能に響いてきます(もちろん分岐予測なども関係しますが)。
既知の問題:Firefox 3.1 Beta 3 [hatena.ne.jp]
このβ版を使用しているユーザーが以前のFirefox 3.1α版またはβ版にダウングレードすると、保存していたパスワードが使えなくなります。
そもそもカルシウム不足とイライラの間に明白な関係は認められない [nifty.com]ですし。
そうです、本当に関係があるのは乳酸菌ですよ。
まあそうだけど、「β3なのにこんなバグが残ってるのかよ!」というのと、「この不具合は既に既知のもので開発者も把握済み」というのとでは、実際にパスワードが消えた時の安心感が違いますよ。
これはBug 467463を修正したがゆえの副産物で、3.1beta3を使ったあとで3.1alphaから3.1beta2を使った場合にのみ、保存したパスワードが読めないということのようです。同Bugの最後のコメントには次のようにありますが、「その関数は存在しない」というのは「リリース済みの以前のビルドには入ってない」ということでしょうか。まあ、そう心配することはないと思いますよ。
今日Gavinが言っていたけど、これをFF3.1B3のリリースノートに入れるほうが良いかもしれない...以前のFF3.1のビルドはパスワードマネージャのダウングレードロジックでヘマをやっていたし、この修正を入れたビルドを走らせた後、以前のビルドは保存されたパスワードを使えなくなるだろう。[v2からv1にダウングレードする関数を探しにいくが、その関数は存在しない。]この問題に限って言えばFirefox 2/3ユーザにとって問題にはならない、3.1はログインにmozStrageを使う最初のバージョンだから。将来も問題になることはないはずで、新しいコードは、将来の未知のDBスキーマの扱いについても、より適切に行うようになっている。 Justin Dolske 2009-01-22 20:12:13 PDT [mozilla.org]
今日Gavinが言っていたけど、これをFF3.1B3のリリースノートに入れるほうが良いかもしれない...
以前のFF3.1のビルドはパスワードマネージャのダウングレードロジックでヘマをやっていたし、この修正を入れたビルドを走らせた後、以前のビルドは保存されたパスワードを使えなくなるだろう。[v2からv1にダウングレードする関数を探しにいくが、その関数は存在しない。]
この問題に限って言えばFirefox 2/3ユーザにとって問題にはならない、3.1はログインにmozStrageを使う最初のバージョンだから。将来も問題になることはないはずで、新しいコードは、将来の未知のDBスキーマの扱いについても、より適切に行うようになっている。
Justin Dolske 2009-01-22 20:12:13 PDT [mozilla.org]
そもそも不具合だらけのFirefoxなんだから、おとなしく直されるの待っとけって話だな。直す早さだけは随一らしいから。http://news.cnet.com/8301-1009_3-10190206-83.html [cnet.com]http://japan.cnet.com/marketing/story/0,3800080523,20389465,00.htm [cnet.com]
履歴とブックマークの管理で、タグの中身を開くのが超遅くなった件はそのままだな。スマートブックマークで"uri=〜"という指定をすると正常に表示されないのもそのままだ。
ブックマークの説明文を検索でヒットさせないのはなぜだ。というか3.0リリース前に外された高度な検索機能はいつ復活するのだ。
Placesは、3.1で改善するどころか、さらに腐ったコードが増殖しているので、どうにもならんでしょう。目新しい機能ばかり追加されて、基本的な部分の改善が止まるというのは、いかにもオープンソースらしい展開ですが、これでもうFirefoxも先は長くないなと思ったり。きっとまた歴史は繰り返すんでしょうね。
3.1に限った話じゃなくてバージョン上がったとき全般の話だけど、Nightry Tester [mozilla.org]使えば全部じゃないけど動くよ。後、Gresemonkey、Firebug、TabmixPlusあたりは開発版使えば最新のバージョンで動くことも多い。
ではこれを。http://wikiwiki.jp/firefox/?%B8%DF%B4%B9%C0%AD [wikiwiki.jp]
ところで、拡張機能よりテーマとか言語パックの方がバージョン間での互換性が低いような気がしません?(バージョンチェックを無視した場合ね)
低いというより、テーマと言語パックについてはセキュリティ修正・安定性向上のためのバージョンアップ間(2.0.xとか3.0.xとか)以外では、そのテーマや言語パックを管理・開発している人間が実際にそのバージョンで確認して対応していない限り互換性はありません。これはある意味では現状におけるXULの仕様です。
バージョンアップ時に、既存のXULウィジットやテーマの持つスタイルのみを使って微調整を一切せず、既存のユーザインタフェースに使われているストリングのみを使えばテーマや言語パックも対応が必要ないでしょうけど、それはあまり現実的ではないです。
更新チェックはアドオンだけにするように設定しておけばいいんでないかい?
>母ちゃんのPCにプラグインといっしょにインストールしたとして
母ちゃんのPCに、プラグイン入れないと駄目なようなブラウザ入れるなよ。自分に降りかかる火の粉の元だろ・・・・
# Mac使わせておけばいいんですよ
Firefoxにアドオンを必要とするのはマニアだけです。
無いと不便なプラグインなんて Flash Player ぐらいのもんじゃないの?
# まあ、未だに拡張機能とプラグインを混同してるんだろうけど
アドオン ├ 拡張機能 ├ テーマ └ プラグイン
逆に、Windows Mobileが主流になっちゃえばいいんじゃない? とか思ったり思わなかったり...。
Googleはわからんけど、Appleに通信機器は任せたくない。
気のせいだと思いますよ。 Display Mail User Agent [mozilla.org]が対応しているメーラーの数はものすごく多いですし。
私の場合、メーラーはメールを送る時だけ使って、メールを読む時は自作のプロトコルハンドラでFirefoxに表示させています。imaps://foo@example.com/INBOX/ みたいな書式でブックマークに入れて。
ただ、これを自分以外の人が使えるか、というと、俄かに返答できません。何が言いたいかというと、別に無理やり開発コミュニティに話を繋げる必要はないんじゃないか、ってことなんですけどね。自分のために作って使っているというのでいいのではないでしょうか。
別ACですが。
> ブラウザーの選択肢は多いが> メーラーの選択肢は少ない気がする。
ただこれだけの発言に、
> さて、不満だけを述べても建設的ではありません。> 「あなたの選択肢」となるような、メーラーが少> ないと感じるなら自作してみては?
ここまで言っちゃうのは、OSSコミュニティの為になるのかね。
ぼくはならないと思う。
不平不満に対して「自分でやれ」と言えば全て解決した気になってしまう人もいるんです。そういう人に対して「暑い」と言えば、「脱げ」と言われかねないので気をつけてください。
#1531007では、「移行コストの問題などから、あなたの選択肢となりえないメーラが多いんだよ。不満を言っても始まらないから自作してみては?」と言ってるわけだ。
前半は真だと思うが、
メーラを自作するコストの大きさを考えると、後半は意図がわからない。
#!/bin/shcat /var/spool/mail/$USER
#1531007の「自作」は、そういう意味ではないだろ。
# ネタのつもりかもしれないが、ネタになってないし。
メーラーの自作を勧められただけなのにどうしてOSSの話と思っちゃったんだろう。
自作したらオープンソースで公開しなければならないのが/.Jの流儀だからでしょう
プライベートで送られてくるメールのヘッダをみると最近はwebメールの使用者が多いですねだから無問題では?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
最初のバージョンは常に打ち捨てられる。
Linux版の動作速度 (スコア:1)
同一マシンで走らせた場合、Linux版動作速度が遅くないですか?Windows用のものと比べると。 この辺が最新バージョンでは改善されると良いのですが。
いつも主観で書き込んでいます
WineでWindows版を走らせればいいんですよ (スコア:3, 興味深い)
いやマジで [slashdot.org]。
Re:WineでWindows版を走らせればいいんですよ (スコア:2, 参考になる)
GCC4でも採用されてるらしいので、じきに追いつくことを期待しましょう。
Re:WineでWindows版を走らせればいいんですよ (スコア:2, 参考になる)
でビルドした後、ビルドしたツリーの場所で実行する./src/dist/bin/firefoxと*.{gcda, gcno}がビルドしたツリーにできます。 そのあと、*.{o,a,so}を削除して、
とすれば-fuse-profileオプションでmakeしてくれますので、プロファイルに基づく最適化がされたバイナリが完成します。
IA32はレジスタの本数が少ないので、profileによってどの変数をレジスタに割り当てるべきかという判別だけでも結構性能に響いてきます(もちろん分岐予測なども関係しますが)。
Mac版の動作速度も遅い (スコア:1)
Re: (スコア:0)
既知の問題 (スコア:0)
既知の問題:Firefox 3.1 Beta 3 [hatena.ne.jp]
Re: (スコア:0)
Re: (スコア:0)
Re: (スコア:0)
Re: (スコア:0)
Re: (スコア:0)
Re:既知の問題 (スコア:3, おもしろおかしい)
そもそもカルシウム不足とイライラの間に明白な関係は認められない [nifty.com]ですし。
Your 金銭的 potential. Our passion - Micro$oft
Tsukitomo(月友)
Re:既知の問題 (スコア:2)
そうです、本当に関係があるのは乳酸菌ですよ。
=-=-= The Inelegance(無粋な人) =-=-=
Re: (スコア:0)
Re:既知の問題 (スコア:1)
Re: (スコア:0)
まあそうだけど、
「β3なのにこんなバグが残ってるのかよ!」というのと、
「この不具合は既に既知のもので開発者も把握済み」というのとでは、
実際にパスワードが消えた時の安心感が違いますよ。
Re:既知の問題 (スコア:4, 参考になる)
これはBug 467463を修正したがゆえの副産物で、3.1beta3を使ったあとで3.1alphaから3.1beta2を使った場合にのみ、保存したパスワードが読めないということのようです。同Bugの最後のコメントには次のようにありますが、「その関数は存在しない」というのは「リリース済みの以前のビルドには入ってない」ということでしょうか。まあ、そう心配することはないと思いますよ。
Re: (スコア:0)
そもそも不具合だらけのFirefoxなんだから、おとなしく直されるの待っとけって話だな。直す早さだけは随一らしいから。
http://news.cnet.com/8301-1009_3-10190206-83.html [cnet.com]
http://japan.cnet.com/marketing/story/0,3800080523,20389465,00.htm [cnet.com]
Places (スコア:0)
履歴とブックマークの管理で、タグの中身を開くのが超遅くなった件はそのままだな。
スマートブックマークで"uri=〜"という指定をすると正常に表示されないのもそのままだ。
ブックマークの説明文を検索でヒットさせないのはなぜだ。
というか3.0リリース前に外された高度な検索機能はいつ復活するのだ。
Re: (スコア:0)
Placesは、3.1で改善するどころか、さらに腐ったコードが増殖しているので、
どうにもならんでしょう。目新しい機能ばかり追加されて、
基本的な部分の改善が止まるというのは、いかにもオープンソースらしい展開ですが、
これでもうFirefoxも先は長くないなと思ったり。きっとまた歴史は繰り返すんでしょうね。
またプラグインの互換性が (スコア:0)
いまだに3対応してないプラグインばっかりで
こんな有様じゃ母ちゃんに勧められないよ…
Re:またプラグインの互換性が (スコア:3, 参考になる)
3.1に限った話じゃなくてバージョン上がったとき全般の話だけど、Nightry Tester [mozilla.org]使えば全部じゃないけど動くよ。
後、Gresemonkey、Firebug、TabmixPlusあたりは開発版使えば最新のバージョンで動くことも多い。
Re: (スコア:0)
Re:またプラグインの互換性が (スコア:1)
ではこれを。
http://wikiwiki.jp/firefox/?%B8%DF%B4%B9%C0%AD [wikiwiki.jp]
ところで、拡張機能よりテーマとか言語パックの方がバージョン間での互換性が低いような気がしません?(バージョンチェックを無視した場合ね)
Re: (スコア:0)
低いというより、テーマと言語パックについてはセキュリティ修正・安定性向上のためのバージョンアップ間(2.0.xとか3.0.xとか)以外では、そのテーマや言語パックを管理・開発している人間が実際にそのバージョンで確認して対応していない限り互換性はありません。これはある意味では現状におけるXULの仕様です。
バージョンアップ時に、既存のXULウィジットやテーマの持つスタイルのみを使って微調整を一切せず、既存のユーザインタフェースに使われているストリングのみを使えばテーマや言語パックも対応が必要ないでしょうけど、それはあまり現実的ではないです。
Re: (スコア:0)
Re:またプラグインの互換性が (スコア:1)
それまで動いてたプラグインが動かなくなるというのが珍しくないってことだ
母ちゃんのPCにプラグインといっしょにインストールしたとして
ボタンひとつのアップデートぐらいは任せられるけど、
似たような機能の別のプラグインに差し替えたり
開発版を拾ってきて更新したり
バージョンチェック回避のおまじないを唱えさせたり
そんなの期待できないだろ?
Re: (スコア:0)
更新チェックはアドオンだけにするように設定しておけばいいんでないかい?
Re: (スコア:0)
>母ちゃんのPCにプラグインといっしょにインストールしたとして
母ちゃんのPCに、プラグイン入れないと駄目なようなブラウザ入れるなよ。
自分に降りかかる火の粉の元だろ・・・・
# Mac使わせておけばいいんですよ
Re:またプラグインの互換性が (スコア:1, すばらしい洞察)
こんなものが2割超までシェアを伸ばしてるほうがおかしい
Re:またプラグインの互換性が (スコア:2, すばらしい洞察)
Firefoxにアドオンを必要とするのはマニアだけです。
Re: (スコア:0)
Re: (スコア:0)
無いと不便なプラグインなんて Flash Player ぐらいのもんじゃないの?
# まあ、未だに拡張機能とプラグインを混同してるんだろうけど
Re:ブラウザーの選択肢は多いが (スコア:1)
FennecはAndroidはJavaだからダメで、iPhoneは許可されていないからダメ [cnet.com]らしいですし…。
Opera MiniはよくAndroid版が出たなーと思ってたら、もともとJavaだった [opera.com]のですかね。
Re:ブラウザーの選択肢は多いが (スコア:1)
逆に、Windows Mobileが主流になっちゃえばいいんじゃない?
とか思ったり思わなかったり...。
Googleはわからんけど、Appleに通信機器は任せたくない。
Re: (スコア:0)
Re:ブラウザーの選択肢は多いが (スコア:1)
気のせいだと思いますよ。
Display Mail User Agent [mozilla.org]が対応しているメーラーの数はものすごく多いですし。
Re: (スコア:0)
ただ、メーラーはブラウザ以上にパーソナルなものですし、移行コストも高く、古くからのスタイルを変えられないという場合も多いです。
つまり世界には「あなたの選択肢」となりえないメーラーの方が、なりえるメーラーより多いのは確かでしょう。
さて、不満だけを述べても建設的ではありません。「あなたの選択肢」となるような、メーラーが少ないと感じるなら自作してみては?
Webブラウザに比べれば、メーラーの方が単純で作りやすいですよ。
#こうしてループしていく
Re:ブラウザーの選択肢は多いが (スコア:1, 興味深い)
私の場合、メーラーはメールを送る時だけ使って、メールを読む時は自作のプロトコルハンドラでFirefoxに表示させています。
imaps://foo@example.com/INBOX/ みたいな書式でブックマークに入れて。
ただ、これを自分以外の人が使えるか、というと、俄かに返答できません。何が言いたいかというと、別に無理やり開発コミュニティに話を繋げる必要はないんじゃないか、ってことなんですけどね。自分のために作って使っているというのでいいのではないでしょうか。
Re: (スコア:0)
別ACですが。
> ブラウザーの選択肢は多いが
> メーラーの選択肢は少ない気がする。
ただこれだけの発言に、
> さて、不満だけを述べても建設的ではありません。
> 「あなたの選択肢」となるような、メーラーが少
> ないと感じるなら自作してみては?
ここまで言っちゃうのは、OSSコミュニティの為に
なるのかね。
ぼくはならないと思う。
Re: (スコア:0)
不平不満に対して「自分でやれ」と言えば全て解決した気になってしまう人もいるんです。
そういう人に対して「暑い」と言えば、「脱げ」と言われかねないので気をつけてください。
Re: (スコア:0)
#1531007では、「移行コストの問題などから、あなたの選択肢となりえないメーラが多いんだよ。不満を言っても始まらないから自作してみては?」と言ってるわけだ。
前半は真だと思うが、
メーラを自作するコストの大きさを考えると、後半は意図がわからない。
Re: (スコア:0)
メーラくらいミニマムな機能のならほぼゼロだろ。ほれ、これで半分できた。
Re: (スコア:0)
#1531007の「自作」は、そういう意味ではないだろ。
# ネタのつもりかもしれないが、ネタになってないし。
Re: (スコア:0)
メーラーの自作を勧められただけなのにどうしてOSSの話と思っちゃったんだろう。
Re: (スコア:0)
自作したらオープンソースで公開しなければならないのが/.Jの流儀だからでしょう
Re: (スコア:0)
プライベートで送られてくるメールのヘッダをみると最近はwebメールの使用者が多いですね
だから無問題では?