Linux使ってて普及するわけないと思った時 93 [無断転載禁止]©5ch.io
■ このスレッドは過去ログ倉庫に格納されています
0001login:Penguin
2017/01/23(月) 00:24:08.01ID:zHhdN0NO語れや ハゲ
■前スレ
Linux使ってて普及するわけないと思った時 92
http://hayabusa6.2ch.net/test/read.cgi/linux/1483944383/
0002login:Penguin
2017/01/23(月) 08:36:38.53ID:aTkp2on20003login:Penguin
2017/01/23(月) 09:08:43.52ID:YT4f9otF0004login:Penguin
2017/01/23(月) 12:48:42.61ID:vZr1JwZlhttp://hayabusa6.2ch.net/test/read.cgi/linux/1485098519/
先に立ったスレから使おう。
ここは重複スレだから94スレとして使おう。
0005login:Penguin
2017/01/23(月) 13:55:58.60ID:/wAkkOLaお前も憤死
0006login:Penguin
2017/01/23(月) 14:49:30.72ID:b9JqMB95/etc/inittab のrunlevelを 3 再起動するとCLI画面起動。 5設定だとGUI起動したような。
鯖運用時はGUIは触らないし省メモリ、CPU負荷軽減を兼ねて3設定で再起動していた。
0007login:Penguin
2017/01/23(月) 15:27:24.45ID:zUeJ4RRWまぁ、デスクトップ環境の大半が鈍重でうんざりするのは分かるけど、
その鈍重な腐れデスクトップ環境でさえ、操作せず放置しておけば負荷は無いだろ。
0008login:Penguin
2017/01/23(月) 20:31:11.77ID:etfDEnKO『UNIXという考え方』という本ではX11の設計はボロカスに言われてるよ
腐ってるのはX Window Systemなんです
本の中でX11の次に出てくるものはすばらしいものだと予言されてるけど
Waylandはどんなものなんかね
0009login:Penguin
2017/01/23(月) 20:43:01.00ID:rNmZCiJE線の世界の思想で平面の世界を評価することが間違いだよ。
0010login:Penguin
2017/01/23(月) 20:55:51.52ID:pLQp/Lfp今時のウィンドウシステム作ろうって動きあったんだな
そりゃそうだよな、そういうコンセプトでMIT系ライセンスで土台を固めて、
コモンコントロールや汎用のファイル選択の類のダイアログをツールキットより下で
用意しなきゃ開発者はやってられんわなぁ
Xlibとソース互換のwaylandのライブラリを提供するか、waylandにXサーバ実装で
実行時に互換したりとかすればスムーズに代替できるとは思うが、どうなるのかねぇ
0011login:Penguin
2017/01/23(月) 21:32:54.11ID:qo+YNAJZ0012login:Penguin
2017/01/23(月) 21:48:23.81ID:pLQp/Lfpこの程度の事も理解できないなら黙ってろ
XlibはただのTCPクライアントのライブラリっつーかサブルーチン集みたいなもんだ
0013login:Penguin
2017/01/23(月) 22:17:49.45ID:rNmZCiJE互換性は、それようのラッパ層を別に持たせるほうが良いと思う。
0014login:Penguin
2017/01/23(月) 22:22:24.71ID:pLQp/Lfp修正するどころかメンテナ不在のパッケージ類もなきにしもあらずだろうし・・・
根元で互換取るか、waylandにXサーバ乗せるか、でもなけりゃ、
Windowsみたいにxming常駐させるとかでもしないと収拾つかんだろうて
0015login:Penguin
2017/01/23(月) 22:29:47.60ID:rNmZCiJEヘタに互換性維持を考えたらダメになると思う。
0016login:Penguin
2017/01/23(月) 22:39:21.90ID:pLQp/LfpメモリやCPUリソースの無駄だけど、xmingみたいな前例があるし、確実だし・・・
UnityはUnityでGPLでmirとかやってるし、mirもwaylandも流行るかどうか知らんけど
GUI関連はよ何とかしてほしい
0017login:Penguin
2017/01/23(月) 22:52:43.59ID:FErSGPiXサーバや組込みで使われてるけどPCで使われない理由を端的にかつ明確に表現しているな。
0018login:Penguin
2017/01/23(月) 22:54:22.93ID:1fo6kmTI0019login:Penguin
2017/01/23(月) 23:01:10.66ID:pLQp/LfpやっぱXサーバの機能を実行させて、クライアントのバイナリそのままで
ソケット跨いだ先のサーバが互換取るのか
0020login:Penguin
2017/01/23(月) 23:03:08.01ID:aiwmZ5GUGUIは個人的な好みが激しく出るから、欲しいなら自分で作れってのがLinux
あとSSHでリモート操作したいって奴が多いのもある
これ、http://forest.watch.impress.co.jp/docs/news/1040399.html
なんてWinはGUIなのに、LinuxだとSSHでもしたいもんだからこんなインターフェース
ソース公開だからWinのGUIのようにしたければ自分してねだろ
0021login:Penguin
2017/01/23(月) 23:05:15.24ID:1lFfL7Wc0022login:Penguin
2017/01/23(月) 23:11:51.74ID:pLQp/LfpXlibの正体すらわかってなさそうな無知な煽りは馬鹿にされて当たり前だろう
加えて俺はマイナーな物でも知らないなら知らないで知ったかぶったりはしない
0023login:Penguin
2017/01/23(月) 23:40:21.39ID:bIIhFUCYでもwaylandを知った上でこんなこと書いてるから只のアホに違いないが
> コモンコントロールや汎用のファイル選択の類のダイアログをツールキットより下で
> 用意しなきゃ開発者はやってられんわなぁ
0024login:Penguin
2017/01/23(月) 23:54:39.48ID:pLQp/Lfpwaylandはさっき概要を読んだばかりで深く知ってる訳じゃないが、
真ん中はwaylandに限った話をした訳じゃない
「ツールキットより下」って言ってんじゃん
大体Windowsのコモンコントロールだってシステムが用意してる物のあれば
コモンコントロールに見せかけてビジュアルスタイル対応とか言って
後から追加したDLLのコントロールだったり、フォルダ選択ダイアログに至っては
システムとして提供してる訳じゃない上にインターフェースがシェルAPIの
IDLIST_ABSOLUTEやらRELATIVEやらみたいなCOMオブジェクトだったり
（その辺を知らない作者のフリーウェアのフォルダ選択ダイアログで
初期フォルダが設定されなかったりするのはIDLIST使わなきゃってのが周知されてないから）
コモンコントロールの定義自体が曖昧
俺が言いたいのはそういった標準を準備しやすい土台（ウィンドウシステム）があれば
ツールキットの下にも自然とコモンコントロールみたいな標準を作る動きが
出てくるんじゃないかって事
0025login:Penguin
2017/01/23(月) 23:57:51.71ID:iY6Sn59tGUIをスクラッチビルドするとか非現実的すぎ。
似たような機能の中途半端なものが大量に再生産されるのがLinux文化といえばソレまでだけど、完成品が少なすぎる。
0026login:Penguin
2017/01/24(火) 00:41:03.16ID:JQCm7uaK出来合いの完成品ものが欲しければWinで良い。
Linuxの場合は組み合わせでソフトを完成させるのが多い
ある処理をするためのGUIを用いたソフトを作るのに、自分ができる言語のpythonでGUI等作り、
で処理エンジンはスピード必要で(自分はC/C++できないから)誰かがC/C++で書いたもを使う
って感じ。で、別な奴はjavaScript(GUI)＋C/C++エンジンでやるかもしれない。
これがLinux。
そんな感じだからwindowマネージャも色々あるし、そして、ユーザがデスクトップを好き勝手に弄っている
俺ソフトのGUIは、好きな・出来る言語で好きにつくりなよ＞＜
0027login:Penguin
2017/01/24(火) 01:19:11.65ID:7G+JQhNpそれに物によってはプロジェクト一式公開されてる
オプソなのはLinuxだけじゃない
0028login:Penguin
2017/01/24(火) 03:38:26.38ID:1REuQ5W+5.7. デスクトップ環境
https://www.freebsd.org/doc/ja_JP.eucJP/books/handbook/x11-wm.html
GPLをできるだけ避けるFreeBSDすらデスクトップ環境はGNOME、KDE、Xfceだ。
Waylandが実用化したらQtとGTK+3とCompizはWaylandにも対応するだろう。
しかしWaylandはMITライセンスのツールキットを作る動機にはならない。
X Window SystemもMITライセンスだから作るならWaylandを待つ必要はない。
●ディスプレイサーバ
X Window System (MIT)
Wayland (MIT)
Mir (GPL、Unity8が使用予定)
●ウィジェット・ツールキット
Qt (LGPL)
GTK+ (LGPL)
Nux (LGPL?)
●コンポジット型ウィンドウマネージャ
KWin (GPL、Qtを使用)
Metacity (GPL、GTK+2を使用)
Mutter (GPL、GTK+3を使用)
Compiz (MIT、Xlibを直接使用)
●デスクトップ環境
KDE (GPL/LGPL、Qtを使用)
GNOME (GPL/LGPL、GTK+を使用)
Unity (GPL/LGPL、Nuxを使用)
0029login:Penguin
2017/01/24(火) 03:55:05.89ID:7G+JQhNpコモンコントロールみたいなものの作りやすさは構造的な問題
Xlibからコントロール（GUI部品）作るってのは、MFCで言うとこの
CButtonやCEditやリストツリーその他諸々を一切使わずに
CWndから派生して全部作らなきゃならないみたいな縛りに近い
加えて、Winだとウィンドウメッセージのルーティングに割り込んだり、
コントロールが載ってるウィンドウがWM_NOTIFYを解釈すれば
どのコントロールにどんなイベント（メッセージ）が発生したのかがわかるから
いちいち下位のコールバックルーチンに更にコールバックルーチンを登録して
呼び出して貰ったり、イベントリスナみたいな物で下位にコールバックを登録したりみたいな
手間が掛からない
ところがXlibにはメッセージのルーティングみたいな概念も何もない
良くも悪くも単純だから素直に下位を隠蔽しようとしても、
せいぜいイベントリスナみたいなのが限界
0030login:Penguin
2017/01/24(火) 08:52:17.86ID:1REuQ5W+しかしウィジェット・ツールキットがLGPLなのでアプリケーションに影響する場合がある。
だからMITライセンスのツールキットが欲しいと言い続けている人がいるわけだ。
●X Window System
アプリケーション デスクトップ環境(GNOME)
↑↓ ↑↓
ウィジェット・ツールキット(GTK+)
↑↓
Xクライアントライブラリ(Xlib)
↑↓
X Window System
↑ ↓
↑ ウィンドウマネージャ(Compiz)
↑ ↓
↑ OpenGL
↑ ↓
キーボード GPU
●Wayland
アプリケーション デスクトップ環境(GNOME)
↑↓ ↑↓
ウィジェット・ツールキット(GTK+)
↑↓
Waylandコンポジタ(Compiz)
↑ ↓
↑ OpenGL
↑ ↓
キーボード GPU
0031login:Penguin
2017/01/24(火) 08:53:42.76ID:1REuQ5W+Enlightenment
https://ja.wikipedia.org/wiki/Enlightenment
https://www.enlightenment.org/distros/ubuntu-start
ツールキットがLGPLでないデスクトップ環境がすでにあるじゃないか。
EnlightenmentでアプリケーションをEFLとリンクすれば問題は解決だ。
それをGNOME/KDE上で動かしてもアプリケーションにLGPLは及ばない。
MITライセンスのツールキットを新たに開発する必要などない。
●X Window System
アプリケーション デスクトップ環境(Enlightenment)←BSDライセンス
↑↓ ↑↓
ウィジェット・ツールキット(EFL)←BSDライセンス
↑↓
Xクライアントライブラリ(Xlib)
↑↓
X Window System
↑ ↓
↑ ウィンドウマネージャ(Compiz)
↑ ↓
↑ OpenGL
↑ ↓
キーボード GPU
0032login:Penguin
2017/01/24(火) 09:19:49.14ID:7G+JQhNpこれに何の疑問も抱かないのか？
0033login:Penguin
2017/01/24(火) 10:02:11.12ID:1REuQ5W+EFLの欠点を知っているなら具体的に書いてくれ。
Enlightenment Foundation Libraries
https://en.wikipedia.org/wiki/Enlightenment_Foundation_Libraries
>License BSD license et al.
File:Free and open-source-software display servers and UI toolkits.svg
https://en.wikipedia.org/wiki/File:Free_and_open-source-software_display_servers_and_UI_toolkits.svg
0034login:Penguin
2017/01/24(火) 15:46:34.55ID:eFcd4YUJGCCにlibcは無い
clang/llvmにもlibcは無い
必要な時はglibc、uclibc、musl、newlib、Bionic libcなどを利用する事が多い
0035login:Penguin
2017/01/24(火) 16:17:04.17ID:7G+JQhNpEだけでなんて開発したことねぇし
それはGNOMEやGTKみたいにデスクトップ環境やウィンドウマネージャが
違ってても動くの？どんなIDEやエディタがデザイナ提供してるの？
0036login:Penguin
2017/01/24(火) 16:49:30.12ID:7G+JQhNp> ツールキットがLGPLでないデスクトップ環境
これを正確に言い換えると
> LGPLでないツールキットを利用して作られてるウィンドウマネージャ
これだけの話であって、アプリがどのツールキットを使うかと
ツールキットがどのDEorWMで使われてるかには何の因果関係もない
相関関係があるとしたらそのバイナリの完全な動作の為に
DEやWMの縛りがあるかどうかだけ
それと、何を誤魔化そうとしてるのかわかったよ
>>30-31にコモンコントロールを割り込ませるとどうなるの？っと
0037login:Penguin
2017/01/24(火) 17:11:50.61ID:1REuQ5W+GCCランタイムライブラリ例外とFAQ
https://www.gnu.org/licenses/gcc-exception-3.1-faq.ja.html
>libgcc, libstdc++, libfortran, libgomp, libdecnumber, libgcov
>とGCCで配布されるそのほかのライブラリが含まれます。
GCCとglibcはセットだと思い込んでいたが、決まってないみたいだね。
コピーレフトでないlibcはmusl(MIT)、Bionic libc(BSD)、BSD libc(BSD)だ。
LLVM、GCC libstdc++をBSDライセンスのlibc++へ置き換え
http://news.mynavi.jp/news/2010/05/18/045/
脱GPLを目指すFreeBSD、FreeBSD 10ではC++標準ライブラリも脱GPL
https://srad.jp/story/11/10/01/0514213/
脱GPLの理由
https://opensource.srad.jp/comment/2027924
GCCとClang/LLVMでライブラリが違うのはC++だった。
0038login:Penguin
2017/01/24(火) 17:47:10.39ID:7G+JQhNpEFLにも欠点があって他のはコモンコントロールに相当するGUI部品の
挙動が不完全だったり、javaに逃げても可変数のメニューの項目が
正しく描画されなかったり、物によってはダイアログの概念すら省略されてたり
GUIに問題あり過ぎて、きっちり作ろうとするとGPL汚染を免れない、と
そりゃGUI不要な方面やGoogleみたいな美味しいとこだけ掠め取れるようなとこにしか使われん
0039login:Penguin
2017/01/24(火) 18:23:15.27ID:1REuQ5W+こちらも今日EFLに気がついて色々調べている最中だ。
>デスクトップ環境やウィンドウマネージャが違ってても動くの？
HOWTO: Enable Compiz under Bodhi (Enlightenment)
http://jeffhoogland.blogspot.jp/2010/12/howto-enable-compiz-under-bodhi.html
Enlightenment
https://ja.wikipedia.org/wiki/Enlightenment
>KDEやGNOMEのアプリとも連携する。
>どんなIDEやエディタがデザイナ提供してるの？
Eflete - EFL Edje Theme Editor
https://phab.enlightenment.org/w/projects/eflete/
Enlightenment's Edje Has A Nice, Easy-To-Use Theme Editor Under Development
https://www.phoronix.com/scan.php?page=news_item&;px=MTcyNTA
>それと、何を誤魔化そうとしてるのかわかったよ
こちらにはさっぱりわからないから気のせいだ。
>コモンコントロールを割り込ませるとどうなるの？
足りないコモンコントロールをどうすれば追加できるかという話か?
ツールキットの上に独自処理を載せる。
その方法で無理ならツールキットを改造するか諦める。
X Window SystemがWaylandに置き換えられても同じだろう。
>>38
>EFLにも欠点があって
>>35の事を言っているなら結論を急ぎすぎだろう。
0040login:Penguin
2017/01/24(火) 18:48:28.72ID:7G+JQhNp> ツールキットの上に独自処理を載せる。
MFCに例えると、GUI部品１つ１つについてCWndどころかCControlから派生して
ツールキットがそれぞれ独自に実装しなきゃ、まともなGUI部品として使えないって事っしょ
Winの場合はMFCやATLや.NETやVCLやその他諸々、ツールキットの下に
コモンコントロールが存在していてそれを利用できる
そしてサブルーチンと違って、ハンドラの類はコールバックして貰う機構を下位に
頼らなければならないが、それをLinuxとかで良く使われるようなツールキットみたいに
コントロール毎に登録したりする必要もない
（JavaのSWTですらリスナを１つ１つコントロールに登録する方式）
ウィンドウのクラスを派生してWM_NOTIFYを処理する様に変更するだけで
コントロールのクラスを派生せず、そのまま貼り付けるだけで
イベントが発生したコントロールを判別してイベントの種類を把握して応答できる
そういう機構がないXの場合、下位がコントロール毎にハンドラを記憶して
イベントが発生する度にコントロールがハンドラを呼び出したりしなきゃならない
そのハンドラの記憶の為のメソッド類は、当然応答し得るイベントや
取得or設定できる情報を超えた自由度は得られない
それを自前で実現しようとすると、SWTのリスナの登録を
ウィンドウの派生クラスで処理するラッパーを自前で書き上げる位の労力を必要とする
加えて、カスタムコントロール類を作ろうとすると、その構造に引きずられる
ツールキットより下の段階でコールバックの機構を共通化して
コモンコントロールみたいな誰でも使えて挙動が同じになるような物を提示しとかないとダメだよ
ツールキットのレベルでウィンドウのインスタンスがイベント処理できるようにするにしても
カスタムコントロール作ろうとした途端、ツールキットの他のコントロールと同じように
ウィンドウのインスタンスへのルーティングとかしなきゃならなかったりだろうし、えっらい大変だぞ
0041login:Penguin
2017/01/24(火) 19:03:20.52ID:gNcfQPy7よくわからんが、色々気に入らんなら自分で俺プロジェクト立ち上げて
やりたいことを実現すれば良いんじゃないのか
0042login:Penguin
2017/01/24(火) 19:05:12.78ID:7G+JQhNpプロジェクト立ち上げてWinで発明された車輪を再発明するくらいならVS使う
で、hello world にあちこちから拾ってきたソース貼り付けて実験してみたが、
waylandもwl_callback_add_listenerとかでいちいちコントロールとイベント毎に
コールバックルーチン設定しなきゃならんっつー方式に見えるな
ネットワーク透過のオーバーヘッド削除して今風の構造にしましたってだけ？
過大な期待した俺が無知だったって事でおｋ？
0043login:Penguin
2017/01/24(火) 19:12:52.20ID:gNcfQPy7そういうんなら、Win専科になればいいんじゃないのか？
あと、なんでLinuxを使おうとしているんだ？ Winが良いならWinを使えば良い
0044login:Penguin
2017/01/24(火) 19:16:32.21ID:uCQzpukhLinuxはダメだな、の一言で済むことになにをごちゃごちゃと。
0045login:Penguin
2017/01/24(火) 19:26:54.86ID:7G+JQhNpLAMPの類が動くから使ってるだけ
Linuxとアプリを使うのと、Linuxで動く物を作る気になるかどうかと、
Linuxで動く物を実際に作ってるかどうかは別
>>44
Linuxがダメなんじゃない、Linuxの上に載ってる物が不完全だったりGPLだったりなのがダメ
0046login:Penguin
2017/01/24(火) 19:28:30.75ID:HU3F0HYbストールマンがクソ
0047login:Penguin
2017/01/24(火) 19:51:58.68ID:jPkyEyt9GUIアプリをベンダー提供のライブラリーで書くことに慣れると、ライブラリー汚染が進んで
ドラッグ中毒に似た症状を示すようになる。慣れたライブラリーが使えないと禁断症状を発して
手が震え、キーボードからソースコードの一行も打てなくなる。みたいな。可哀想にね。
0048login:Penguin
2017/01/24(火) 19:56:09.22ID:7G+JQhNp慣れだけが問題なら.NETみたいなリッチなとこからMFCへの逆戻りだけでなく
MFCから.NETへの移行にも問題が起こるだろう
GPLでないツールキット類の完成度が低過ぎたり配布に制限を課せられるのが問題
0049login:Penguin
2017/01/24(火) 20:04:11.61ID:gNcfQPy7WinでLAMPだめなのか
じゃ、LAMPをwinで動くようにしたほうが良いんじゃないのか
0050login:Penguin
2017/01/24(火) 20:17:29.12ID:7G+JQhNp既にWin用のもあるって知ってるけど、鯖用は鯖用で別のPCに分離して
環境あんまり汚したくないし、Win7だけだとvistaのライセンスしかないLOOX/U50との
ファイルがやり取りできないから（LMか何かのバージョン落とせばセキュリティを
犠牲にして、双方向で共有にアクセスしに行けるのは知ってるがやりたくない）
BSDのsamba通せるファイル鯖は外せないし、何よりペネトレーションテストじゃ
WinはKaliより出来る事が少ない上に面倒
加えてうちのPCには殆どROMドライブないからPXEBOOTに使えるtftpとnfsの環境は
残しておきたいとか、個人的な理由
ついでに付け加えると、殆どのPCにXサーバはインストールすらしてない
常にCUIのログインプロンプトを表示し続けてるようなもの
それでもターミナル開けるのはvncのデーモンにフレームバッファさせて
Xrdp越しにディスプレイマネージャ毎GUI引っ張ってこれる（あくまで広いCUI用だが）
別に俺はCUIを否定しないし困りはしない・・・普及はしないだろうけどな
0051login:Penguin
2017/01/24(火) 21:08:35.17ID:jPkyEyt9ドラッグにもいろいろあってな。というのと同じだね。
基底クラスからスクラッチでガンガレば教祖になれるおw
0052login:Penguin
2017/01/24(火) 21:25:33.41ID:7G+JQhNpいつの頃からかMFCのダイアログにCFrameWnd貼り付けてもスプリッタできなくなったりして
ダイアログ用のスプリッタを自前で用意したり、
複数選択可能なツリーコントロールに修正したり、
CMFCListCtrlの系列がオーバーライドしてイベント塞き止めてるのを
自前で更にカスタマイズしてわかりやすい様にコールバックを増やして
わかりやすい様に整理したクラスを自前のライブラリ集に用意したり、etc
それだけでもくっそめんどくさかったからなぁ
スクラッチから実用に耐えられる位にまでコモンコントロールに相当する物を
片っ端から実装するって、大学の難題数問ってより、小学校のドリルん百冊ってレヴェル
0053login:Penguin
2017/01/24(火) 21:39:09.68ID:soK5NYqmDEにはない。
以上。
0054login:Penguin
2017/01/24(火) 21:39:25.23ID:jPkyEyt9君の話がツマラナイのは結局 MFC中毒患者のグダグダな戯言しか語っていないところ。
依存症を治療したくてココにるのだろうが、結局禁断症状に耐えられなくて、ドラッグ漬けに
後戻り。田代をみたいにね。
0055login:Penguin
2017/01/24(火) 21:48:59.63ID:7G+JQhNp別にけなしたくて書いてる訳じゃないから黙ってたが・・・
ちょいとこぼしちまった糞なSWTや辛うじて使い物になってるGTK+をこき下ろしてやろうか？
0056login:Penguin
2017/01/24(火) 21:56:07.33ID:jPkyEyt9ヤクの売人の薀蓄みたいなものだから、やらんでいいよ。
0057login:Penguin
2017/01/24(火) 22:01:27.25ID:7G+JQhNp比べちまったらMonoやJavaひっくるめて持ち出しても勝負にならんだろうしなぁ
ドラッグだのヤクの売人だのでレッテル貼り＋人格否定でしか退けられんだろうなぁ
0058login:Penguin
2017/01/24(火) 22:11:19.99ID:7G+JQhNp鍵にするハッシュの生成、たったこれだけ
SHA256CryptoServiceProvider^ hash = gcnew SHA256CryptoServiceProvider();
array<BYTE>^ tbyUserHash1 = hash->ComputeHash( tbyUserKey1 );
それにC#で必要だったusingは必要ない（スコープ外れたら勝手に破棄される）
.NETも大分良くなったからなぁ、jpg出力したストリームをexcelみたいに
大元のドキュメントに出力する時もストリームを受け取って流すだけ
fsDest = gcnew FileStream( strDestFile, FileMode::Create,
FileAccess::ReadWrite, FileShare::None, 4096,
FileOptions::SequentialScan );
stream->CopyTo( fsDest );
C++/CLIから派生したのと比べ始めたら勝負にすらなってない
0059login:Penguin
2017/01/24(火) 23:52:55.36ID:gNcfQPy7C++/CLIを使っている奴は少ないだろ
そのコードをWinのC++で書いたらどうなコードになるんだ？
0060login:Penguin
2017/01/24(火) 23:56:43.44ID:7G+JQhNpハッシュならCNGかCryptAPI使うんじゃね？
後者はnewせずにそのままフレームワークかSTLのストリーマをスコープ内に生成かね
C++/CLIの系列使ってる人は確かに少なそうだが
リバースエンジニアリングが問題にならないとこならC#使えばいい
Linuxで使えるようなツールキット類じゃC++/CLIの系列やC#とじゃ
とてもじゃないけど比べ物にならなかったからMFCで例えてやったのに・・・
0061login:Penguin
2017/01/25(水) 00:04:39.91ID:BnnWiaaV>>58のようにコードを出してくれよ
0062login:Penguin
2017/01/25(水) 00:07:31.26ID:C0/wLocTttp://replication.hatenablog.com/entry/2014/07/11/014621
0063login:Penguin
2017/01/25(水) 00:18:26.96ID:C0/wLocT全く同じネットワーク入出力できるからな
証明書のコンテナとやりとりする時にCryptoAPIの一部使う必要はあるが、
わざわざCryptoAPIにSSLのアルゴリズム指定して鍵取り出してだとかする必要もない
当然 OpenSSL LibreSSL リンクしてライセンスに引っ張られる心配もない
0064login:Penguin
2017/01/25(水) 00:39:04.85ID:BnnWiaaVそんなにWin良いのに、鯖ではダメなLinuxがシェア大きいんだ？
WinはLinuxよりずっと開発が楽なんだから、デスクトップ同様にLinuxより大きくて良いような感じがするが
0065login:Penguin
2017/01/25(水) 00:41:57.19ID:C0/wLocTWinはクライアントライセンスが必要でLinuxは全部無償だからじゃね？
おまけに鯖ならGPLのコードだろうと何だろうとクライアントユーザには公開しなくていいからな
大体SSLの用途って鯖だけじゃないからな、クライアントにも使うからな
0066login:Penguin
2017/01/25(水) 12:13:29.81ID:DYfPGLbD0067login:Penguin
2017/01/25(水) 17:10:20.74ID:shsqucSS0068login:Penguin
2017/01/25(水) 17:25:23.39ID:C0/wLocT0069login:Penguin
2017/01/25(水) 18:13:52.50ID:BXXUOOVO0070login:Penguin
2017/01/25(水) 18:28:26.89ID:KWtCgFe+その点、窓のアプリ開発はカネになる。
0071login:Penguin
2017/01/25(水) 18:40:09.16ID:C0/wLocT営利目的であろうと、機能や容量みたいな制限がついてても
企業に無償版を作って貰えるだけであれだけ世界が変わる
0072login:Penguin
2017/01/25(水) 20:44:38.05ID:K7JLYTWzクライアントアプリケーション開発にしてもマルチプラットフォーム対応でJavaでAndroidかSwiftでiOSだろうし
Winのソフトウェア開発が儲かるなんて何年前の話だ
0073login:Penguin
2017/01/25(水) 20:52:33.05ID:C0/wLocTそれにマルチプラットホームのクラウドだけが全てじゃないだろ
Javaとかメニュー表示の時点でこけたり（最近だと可変数のメニューが
１画面に収まらなくなると背景消去すらせずに再描画されない不具合）
アイテム課金のFPSやDropBoxみたいなサービスみたいにWinにしてくれって思う
0074login:Penguin
2017/01/25(水) 20:53:48.86ID:C0/wLocTちゃんとライセンスされてる筈だが、どこのサイト？企業名は？
0075login:Penguin
2017/01/25(水) 21:03:43.50ID:Lg0KEC7U0076login:Penguin
2017/01/25(水) 21:05:55.08ID:C0/wLocT殆どｇｇらず記憶だけで書いてるからちょいとしたミスや情報古かったりなのは簡便
>>75
JavaとかでWinMac泥iOS問わずきっちり動いてくれればね
ところが現実問題、このプラットホームだと不具合が出るだの何だのでもうね
否定はしないけどそんなのを謳い文句にするならきっちり仕上げてくれよと
0077login:Penguin
2017/01/25(水) 21:29:34.27ID:K7JLYTWzマルチプラットフォームでクラウドアプリケーション化してるのが全てだよ
MSは10年以上前からWinの市場規模が小さくなるの予見して仮想化とクラウドに舵切ってるわけ
0078login:Penguin
2017/01/25(水) 21:36:33.81ID:C0/wLocT”完全に”商用ソフトが消え去った訳じゃないし、消える事はないのでは？
とてもクラウドにデータ流せないような企業の事務系の業務やら、
Maya3DMAXやら動画編集やらクリエイティブ系やら、
スタンドアロンやイントラの商用ソフト無しで完結するってんならソフト名教えて欲しいわ
0079login:Penguin
2017/01/25(水) 22:08:11.42ID:K7JLYTWzMSOffice365筆頭にAdobe Creative CloudとかAutodesk Fusion360とかな
クラウド利用しないソフトウェアを開発するほうが時代の流れに逆行してるわ
0080login:Penguin
2017/01/25(水) 22:14:44.12ID:C0/wLocTけど企業が実際に企業秘になるようなデータやオーサリング前のraw動画や
その他諸々、暗号化されてると言われようと本当にイントラの外に投げると思うか？
そんなん聞いたことねぇ
0081login:Penguin
2017/01/25(水) 22:17:27.07ID:K7JLYTWzVPN使ってない会社なんて今時ないぞ
意味分かってんだろうか
0082login:Penguin
2017/01/25(水) 22:18:26.79ID:C0/wLocT石ころ（Linuxの上に載ってるユーザランド）を宝石に見せかけて
開発を促そうだとか宣伝させようだとか扇動しようってったって無理があり過ぎるんだよ
専用クラだってサイトのインストールボタン自体Win、Mac、泥iOSでわかれてるのが殆ど
WinMacスマホに加えてLinuxも同じJava専用クラで動きますなんて記憶にないんだが
0083login:Penguin
2017/01/25(水) 22:20:43.85ID:C0/wLocT中小はともかく、azbilとか一部上場のどこぞとか絶対VPNとか通させないぞ
コンプライアンスが甘いブラックや企業秘がそんなに重要じゃない雑魚企業は知らんが
■ このスレッドは過去ログ倉庫に格納されています