【RaspberryPi】1ボードPCを語るスレ17【Pine64】
■ このスレッドは過去ログ倉庫に格納されています
neo3はneo2より基板はでかいけどヒートシンクは大きさ変わらずかむしろ小さい? $2のケースは放熱性能が心配な造り。冷却ファンを内蔵できる空間を用意して欲しかった。せっかく冷却ファン用コネクタも付いたんだから。 プラケースだからちょっと心配なんだよね だから1.3GHzに抑えてるのかもしれないけど ヒートシンク、付属のか別売りなのか・・・ Storeで 追加アイテム・リストに無いから、付属と思って良いのかな 最近あちこちでラズパイを産業用途で使ってるけどOSってそのままラズビアンを使ってるのかね ライセンスってどうなってるんだろ ラズビアンのライセンス読めばいいんじゃないの? なんで読まないの?アホなの? 読んでまで知りたいわけじゃなく、 思い付きで気になったから知ってるやつがいたら答えて頂戴って程度の質問なんだろ お前にはそういうことはおらないのか? >>151 なんでそんなに攻撃的なの? 発達障害か自閉症なの? そもそも産業用途で使うと何か問題になりそうな要素があるの? 気になるなら読めばいいし、読んでわからない部分があって質問するならまだ理解できるが 産業用途とか関係なく他者のソフトを使うならそのライセンス条項を遵守して使う必要があるってだけの話 ただOSSは商売に使うなら〇〇をしないとダメとかの条項があったりするから製品に組み込むならちゃんと調べとかないと危ないよ GPL汚染とかでググればライセンスに違反して訴えられた例とか出てくる Raspberry Pi OS(Raspbian)のカーネルに手を加えていなければライセンス違反には ならないだろうけど、産業利用のプロトタイプならちゃんと調べなよ 最近だとNewTek NDIがGPLライセンス違反でFFmpegのサポート取り消されて ライブラリから削除されたりしてる >>158 > Raspberry Pi OS(Raspbian)のカーネルに手を加えていなければライセンス違反にはならないだろうけど いや、お前がちゃんと調べろよw 改変してなくてもライセンス違反になるケースもあるし改変しててもちゃんとやればライセンス違反にはならんよ そもそもGPLって改変してもいいよ、でもみんなで共有しようねっていう思想だし 結局ケースバイケースだから自分でライセンスちゃんと読めってことだな >>163 普通の企業がカーネルの改変までやるケースはそんなに多くない GPLの問題はカーネルにリンクした独自開発のデバイスドライバまでソース公開を要求されることにある なのでGPL「汚染」って言われる 防寒コート内全裸を義務づけ 町中歩くときはおっぴろげる必要がある でも工場内歩くときにおっぴろげるのって 実質クローズドと同じじゃないの? だってその防寒コート変態オッサン、工場の外出ないもん >>164 多くないってGPL汚染で有名なSFCのBusyBox訴訟はほぼそれ由来で起きてるんだが GPL汚染は派生物にもソースコード開示を要求するコピーレフト型ライセンスが原因だよ BusyBoxでは派生物をバイナリ配布してるケースが軒並みやられた形 >>166 で、BusyBoxとカーネル改変になんの関係が?w >>164 それはフリーソフトウェアの総本山FSFの主張で オープンソースの立場とは違う https://japan.cnet.com/article/20101831/ 今も事情は変わらない >>168 だから何? オープンソースの立場って{誰|どこの団体}のことを言ってるのかわからんけど、FSFから見たら所詮外野の戯言にしかなってないよ そのオープンソースの立場って奴が使えるカーネルを提供してくれるなら話は別だがw FSFも実際に裁判したことはないけど NVIDIAやAMDに手を引かれると使い物にならなくなるのがわかってるから というわけでデバイスドライバの公開要求が来ても 「NVIDIAもAMDもデバイスドライバずっとプロプライエタリだけどねw」 と返事して炎上させるなり黙殺するなりお好きなように GPLの例外条項にOSが含まれている。OSと言い張れる範囲であれば回避可能 あとCランタイム等の一部も例外条項に入っている てかGPLつってもソースコードの開示権を有するのは成果物の所有者に限る ラズパイをそのまま使ってクライアントに納品した場合、クライアントからソースコードを 要求されたら渡す必要が出てくるかもしれないが不特定多数に公開する必要はない 自社内でラズパイを使っているなら配すらない >>170 FSFはライセンス違反してる案件を全て見つけて提訴しろと?w それはともかくその手のドライバは動的リンクで動的リンク先にまでGPL汚染が適用されるかはかなり(個人的には多分わざと)曖昧だよ >>171 > GPLの例外条項にOSが含まれている。 初耳なんだが、ソースある? >>173 GPLv2 TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATIONの2 Linuxカーネルを使用しつつ同時にプロプライエタリなコードを実行しているケースのよりどころはこれと思われる ただし統一見解はなさそうだし、裁判で通用するかは知らん >>170 AMDは何年も前からLinuxのドライバをオープンソースにしていて、CUDAをRadeon上で実行できる ROCmなどRadeonのGPU+GPGPUドライバを全面的にオープンソースで開発しているよ ttps://github.com/RadeonOpenCompute/ROCm Linuxのプロプライエタリドライバはすでにレガシー扱いで非推奨 AMDが直接配っているドライバは ttps://amdgpu-install.readthedocs.io/en/latest/install-overview.html#stack-variants ・Pro: recommended for use with Radeon Pro graphics products. ・All-Open: recommended for use with consumer products. Radeon Proはプロプライエタリドライバ推奨でそれ以外の一般グラボはオープンソースドライバ推奨 ただ実際はこのドライバよりROCmの方が最先端でWindowsのドライバより高機能 >>174 3 のこの部分じゃないの? However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. これは簡単に言うとGPLなプログラムを配布する時にOSまでは含まなくてもいいよって話 そうでないと例えばWindows用のプログラムは配布できなくなるから OS自体がGPLなら当然ソース提供は必要だよ AndroidスマートフォンやPlayStation Classicはライセンス上の矛盾は存在しないのか? 誰も証拠を示して答えられまい そもそもFSFの見解だってイコール著作権者の見解とは限らないしな >>178 矛盾が存在すると言うなら具体的に指摘しなよw スマホで良く使用されるQualcomm製 SoCのドライバを含む技術情報はNDAで保護されていて公開されていない PlayStation ClassicはLinuxベースでありエミュレータもGPLのPCSX ReARMedを使用している。QEMU等も同様だが トランスレートでGPLの影響下から逃れられるかは明確になっていない >>180 >>172 にも書いたけどドライバに対するGPL汚染の扱いは曖昧だよ Playstation Classic の件はどこが矛盾してるのかよくわからん OSとアプリは基本互いにGPL汚染はしないよ エミュレータ:GPL プログラム:プロプライエタリ これらが同じ仮想メモリ空間にロードされ協調して実行される これがリンクではないと言い張れるのか。もしくはGPLにそのような例外が記述されているのか GPLに関してはオレオレ解釈が横行している。「みんなで渡れば怖くない」状態であり訴訟リスクは相応に存在する >>183 エミュレータ=オペレーティングシステム?それ通るの? もっと言えば>>177 が逆向きに適用可能だとはGPLには書いていない 慣例的にそのように解釈されていると言うだけで明文化されているわけではない >>186 その説明は矛盾がある 「ソースコード→コンパイラ→機械語」と「ソースコード→インタプリタ→機械語」で何が違うのだ? 後者でGPLの影響下から逃れられるのなら前者も同様になってしまう さらに最近はインタプリタと言いつつJITも珍しくないしこの場合処理のフローは前者の方が近いと言える >>187 技術系のメディアでもないしその記事の正確性は疑わしい MOMOの機体内バスはCANを使用しているけどラズパイにCANはない STM32等で十分だろうしラズパイを使うメリットも見えてこない 試作時に使用してたとか荷物の方にラズパイを使った物もあるという話なら判らないでもない >>189 > 「ソースコード→コンパイラ→機械語」と「ソースコード→インタプリタ→機械語」で何が違うのだ? インタプリタで機械語? まあJITの話を含めたとして、それらの違いは生成した成果物をソースとは別にして配布して実行できるかどうかが違う どんなに予算をかけてもバグをゼロにする事はできないのだ >>192 ソースコード&コンパイラの配布パッケージ←多くはないが午後のこ〜だなど前例はある ソースコード&インタプリタの配布パッケージ←今時の非コンパイラ処理系なら大抵ある はどうなるんだ?これに関してGPLの文も絡めて筋の通る説明は出来ないと思うよ >>186 だってGNUの主張であってGPLライセンスを採用している全てのプロジェクトに適用される根拠にはならないし >>194 > ソースコード&コンパイラの配布パッケージ←多くはないが午後のこ〜だなど前例はある > ソースコード&インタプリタの配布パッケージ←今時の非コンパイラ処理系なら大抵ある > はどうなるんだ? 意味わからん、ソースコード配布してるならGPL的にはなんの問題もないだろw >>196 GPLが強制するのは自分のソースコードの公開だけではない 例えばプロプライエタリなコードを一緒に利用できるか否かは重要な要素では GPLと干渉するライセンスはいっぱいある >>197 だから何? ライセンス競合してるから使えないって言うだけの話でしょ 何も矛盾はないと思うけど 特にOSがプロプライエタリな場合、OSのコア機能以外にも多数のアプリやライブラリが付属していたりする そしてアプリ開発時にそれらの機能をアテにする実装も半ば標準化していたりする Windowsを例に挙げると、WindowsAPIは良いとしても.NET類、DirectShowFilter、DirectX、各種COM・・・etc MS Office依存は流石に減ったけど開発でこれらが使えるか否かで実装のコストはもちろん性能面の差も発生する ラズパイなんか使ってロケット作るからまた失敗したのか >>199 で? GPLの矛盾はどこに行ったんだよw >>201 GPLはプロジェクトとしてコピーレフトを求めているのにプロプライエタリなライブラリを呼び出していたら矛盾しているだろ Windows用のアプリだと珍しくないぞ >>203 だからそんなケースには使っちゃだめって話だろ どこも矛盾してないぞ >>199 が書いてるものの多くは、GPLの「システムライブラリ例外」に該当するのでは? それなら、プロプライエタリなものであっても、そのライブラリを使ったGPLなソフトに問題はないよ。 >>204 だめっつっても実際にそういう使われ方をしている物があるだろ デバイスドライバしかりファイルシステムしかり >>205 GPLにシステムライブラリの定義は書いていない 皆が自分が思うシステムライブラリで運用しているのが現状 GPLと信者は怖いよ ソースの流用とかもあるけど利用者が実行してるアプリやwebサイトがどういうものを使ってどういうコードで動いてるか 利用者自身が確認できるレベルにしたいんだ GPL脳だとwindows使うと裏で何をやられてるかわからないから気持ち悪くなるんだって お前はLinux使うときに実際にLinuxのコード確認して使ってるのかと思うけど 本当に突き詰めちゃったらOpenBSDの人クラスやな NanoPi R2S にメタルケースキットが出てるね そこにCPU温度のグラフが書いてあるけど、ヒートシンクだけだとかなり熱い NanoPiNEO3のプラケース、大丈夫なんだろうか・・・ お上の決めたルールは曲解してでも従うのがジャパニーズ奴隷根性 なぜそのルールが決まったのか?本質的なルールの意味は何か?とは決して考えないのだ まぁどうでもいいけど ルーターには16MBついてるOrangeがちょうど良い >>206 > だめっつっても実際にそういう使われ方をしている物があるだろ ライセンサーがダメと言ってる事を無視して使う奴がいると言うだけのことでしょ GPL自体は何ら矛盾してないけど? > GPLにシステムライブラリの定義は書いていない 心配なら自分でライセンサーに確認すればいいだけのこと >>207 別にLinuxの全てを知りたいわけじゃない、コマンドとかドライバーの動きで気になった部分とかを確認したいってだけの話 GPLについてクリアにすることなんて、ここでできるわけじゃないからほどほどに。 >>214 それな。 ここでやってもただのオナニーでしかない。 ソフトウェア板でやればいい話。 その手のスレッドがあるだろ。知らんけど。 GPLには矛盾があるんだ〜 って言ってるシッタカ君が粘着してるだけでしょ まあ、Raspberry Pi以外のSBCだってLinuxやBSD使うわけでしょ? Raspberry Piに限った話ではないよな Linuxが嫌ならFreeBSD使えばいい Raspberry PiだってFreeBSD使えるよ? Linuxの場合、Raspberry Piほど対応のいいSBCはなくなったな Ubuntu Server 20.04なんてリリース当初から公式がサポートしてるし >>209 もう注文しちゃったけど後からメタルケース追加とかされたらショックだな 100パーセント負荷をかけ続けるような用途に使うつもりはないが >>222 簡単なスケジューラーとメモリー管理程度なら Ubuntuはイジメ問題があるから避けたいところだな。 ttps://news.mynavi.jp/article/20160413-a115/ ttps://www.ines-solutions.com/column/a77 ttps://kuenishi.hatenadiary.jp/entry/2020/01/13/231033 ぼくのかんがえた(ry状態。もうぐちゃぐちゃw これ、NVIDIAのプロプラドライバも同様だよな >>221 俺も注文済みだけど、メタルケース追加される気がする 無線無しの機種だから、秋月あたりが取り扱う事を期待してるよ 最近は小容量だとSSDとSDカードの値段ほとんど変わらんな SSDブートに切り替えていく しかも NVMe のほうが SATA より安かったりする。 普通のSDカードに使うのって廃棄の1つ手前のギリギリ良品のやつとかいう話を聞いたがどうなんやろ 1番いいやつは業務用SSDとかが持っていくとかなんとか クラスタになってるやつ面白そうだなと思ったんだが、Etherのハブを使わないで USBにTCP/IPを流してクラスタ内の相互接続はUSBにしてしまえないのかな? TCP/IP over USBじゃ速度が遅いのかな? Ethernet over USBってよく知らんが、あるのに使われないってことは制約があるとか速度出ないんじゃない? USBで、ホストとデバイスが区別されない対等な接続モードってあるの? ないならクラスタの相互接続法としては使いづらくない? USBでつないでも結局専用のハブ(ルータ機能内蔵)に相当するものが必要ならUSB経由にする必要がない それで終わり デバイスのハードの対応が必要ならなおさら出番なし スター接続じゃなくてバス接続だとしたらポートを2つ占有してしまう それ用に外部にハブをつけるならなおのこと使う意味がない 良かれと思って余計面倒なことをする 歴史の偉人も通ってきた道でもある nanoPi NEO3買おうか迷う zeroPi買ったばっかりなんだけどなあ 買いなさい ZeroPiと違ってA53だぞ、64bitだぞ 何に使うかなんて、その時に考えればよろしい ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる