デスクトップでLinuxが普及する必要はない 2
■ このスレッドは過去ログ倉庫に格納されています
>>149
いや、わたくしは既にLinux上のビルドはLinux上で完結させるように体制を変更いたしました。
もう少し使えるようになったら、VS上のLinuxターゲットをもう一度考えてみます。
現状ではデメリットが多い。 僕が一番wslを使えるんだぁ!!の人は一日中同じIDなんだけど、お仕事大丈夫?
まぁ、windowsとwslなんて使わず最初からlinuxで作れば楽だわな。 まあでも、これからはWSLの時代ですけどね(嘘)。 楽なんて評価は主観評価なんだし、windows上でvs使ってクロスでwsl使うのが楽って人がいてもいいんじゃね?
最初っからvsな人はvs以外はゴミ評価が多いし。 >>155
お前に求めてるのは、楽だ楽だってオウムのように繰り返し言うことじゃなくて、
何が楽なのかその説明をしろってことだよw wslって/procとか/devとかあって動作するの?wsl2なら動くと思うけど、wslのそこらを使うユーザーランドってどんな動きすんの? >>161
> wslって/procとか/devとかあって動作するの?
そこを提供してるのがWSLの仕事の一つなんだよ。
> wsl2なら動くと思うけど
逆にそっちのほうが難しい。なぜなら仮想マシンを使っていても理想的には
Windowsの情報を見るべきだから。その変換を行うためにMSはカーネルに手を入れてる。 wslでifconfigとかするとデバイスにはイーサネットアダプターとか表示されんの? >>163
理想的にはWindowsのドライバの情報が出るのが正しい。
なぜならデバイスドライバを管理してるOSはWindowsなのだから。
だけどそこまでは対応してない。
ifconfigの情報は表示されるが、WSLの役目として必要最小限のものだけ
つまりIPアドレスとかネットワークアダプタの情報は見れるが
デバイスドライバの情報は見れない。
別にLinuxでドライバ管理したいなんて思わないでしょ?
OSはWindowsなんだから。 >>164
うーん。じゃコマンド出力の結果に細かい差分があったり、wslでは使えないコマンドや考え方が発生する訳か。
てっきりwslのカーネル相当がキレイにエミュレートしてくるのだと思ってた。そこまでじゃないのか。
じゃ、面倒な事を意識する必要のないlinuxの方が俺には楽だな。utf-8のbomとかも面倒くせーし。 >>165
だからお前は勘違いしてるって言われるわけ
WSLはLinuxのエミュレータじゃない。
Linuxアプリを動かすための環境。
クラウドにおいてデバイスはすでに仮想化されてる
お前がやりたいことが何なのか知らんが、
そういうことはクラウドではやらない。下位の層で吸収されているべきもので
クラウドのデバイス(仮想マシンデバイス?)に依存したことはしない > utf-8のbomとかも面倒くせーし。
WSLと一切関係ない話 あといい加減、WSLの何が面倒で、実機を用意することの何が楽なのか書け 一応流されないように再掲しておくか
63 返信:login:Penguin[] 投稿日:2019/11/15(金) 08:54:26.84 ID:EAxyXkav [2/23]
>>61
でも普段からWSL使ってる立場で言うと、お前の提示してる条件はWSLでもめんどくさいよ。
64 自分:login:Penguin[sage] 投稿日:2019/11/15(金) 08:55:05.52 ID:KYbcJ9F4 [8/53]
>>63
なにか面倒くさいことでもあんの?
お互い実現方法でも比較してみようか?w
65 自分:login:Penguin[sage] 投稿日:2019/11/15(金) 08:56:04.00 ID:KYbcJ9F4 [9/53]
1つ目、WSLから現在のディレクトリをエクスプローラーで開く方法
$ explorer.exe .
以上(笑) 結局、Linuxそのものを作り出すんじゃなくて、
WindowsにLinuxのCLIツールを完備させるっていう
WSLの目的がわかっとらんのだよねw linuxの方が楽なのは既に稼働中の使い慣れた環境が手元にあり、わざわざ中途半端なwslを用意する必要がないから。
windowsよりlinuxの方が使い慣れてる俺にはwslダメじゃんとしか思えんよ。
linuxアプリを動かす環境がwindowsにあると便利な人にはいいのだと思うけどね。
俺にはwindowsはwindowsアプリを動かす環境なんでwslが楽と言われても、はぁ、そうですか?としか返せんわ。 >>171
WindowsにCLIコマンドを充実させるものなのに
中途半端ってどういう事?w 仮想PCよりも少ないオーバーヘッドでWindowsとLinuxを1台のPCで動かせるってのは
一般的には十分なメリットなんだが
鯖用途ならともかく、デスクトップ用とでWindowsとLinuxにそれぞれ物理的にPC1台って方がくっそ面倒だぞ 完全にLinuxと同じじゃないと何かが面倒らしいw
その面倒なものはなにと聞いても絶対に言わないwww 物理linux端末と比較してwslが面倒な所。
cliコマンドの動作差分が有る。
動作が遅い。
文字コードの違い。
そもそのwindows端末自体がくっそ面倒くさい。wslで十分な奴には楽なんだろ。 じゃあ具体的に聞こうか?
> cliコマンドの動作差分が有る。
どういう差分がある?
> 動作が遅い。
物理Linuxもスペックの差で動作は遅くなるが
実用可能な最低動作速度は?
> 文字コードの違い。
Windows NT系は昔からUnicode(UTF-16)で
UTF-8のWSLとは相互に変換されるが何で困った? 面倒なこと、困ったことを聞いてるのに、
違いがある点しか言わないのは
使ったことがないからわかんないのかな?
ググって知ったことしか書いてないようだ。 >>175
物理的に用意しなきゃいけないPCが2基って時点で確実に面倒だろw
デスクトップ用途なんだからモニターもキーボードもマウスもそれぞれに用意しなきゃなんないんだぞ >>177
動作差分はifconfigって自分で言ってたろ。動作差分がないってms担保してるの?大昔にtopコマンドのload averageが常に0.5とかいう記事みたけどね。
動作は同じハードウェアで動作するlinuxと等し事に決まってるじゃん。wsl1仮想なの?
wslが相互変換する?自動で?どう基準で?改行コードも?
wsl側のutf-8のlfなテキストをwindowsのメモ帳で開き、windows側のsjisのcrlfのテキストをwsl側のviで開けるの?
wslなんてmsが作ったcygwin程度って認識でふーん、powershellはダメだったんだって思う程度だよ。 >>180
> 動作差分はifconfigって自分で言ってたろ。
ifconfigの内容は物理マシンでもハードウェア構成によって違うだろ?
違いがあるからってなんだって言うんだ?
必要な情報は正しく出てるんだが?
俺が言ったことじゃなくて、お前が実際に試して困ったことを言ってないのか? >>180
> wslが相互変換する?自動で?どう基準で?改行コードも?
お前は基本から学ばないといかんようだなw
まず、ファイルの内容に関しては、Windowsでも
(今のメモ帳のデフォルトである)UTF-8で書けばいいだろ?
自動で変換するのはファイル名などに決まってる。
それで、何が困ったんだ?
> wsl側のutf-8のlfなテキストをwindowsのメモ帳で開き、windows側のsjisのcrlfのテキストをwsl側のviで開けるの?
だからそのために、メモ帳をバージョンアップしただろ。
viがsjisに対応してるかなんかviに聞けや(対応してるの知ってるが) >>180
> wslなんてmsが作ったcygwin程度って認識でふーん、powershellはダメだったんだって思う程度だよ。
思うだけで使ってないから知らんのだよ。
お前が ”想像で" 困るはずだと思ってることはなにもない >>179
ははは。そうだろ。
余計なwindows10端末を用意するのが面倒なんだよね。 >>184
普通の人にとっては逆なんだよ
Linuxのデスクトップ用に更にもう一基PCを用意するのが面倒 >>182
詭弁が激しいな。
windows側に既にあるsjisテキストはwsl側では変換するって事だろ。
メモ帳をアップデートとか、個々のアプリで対応とか本末転倒だろ。
まぁ、あんたの用途には便利なんだろうけど、俺の用途にはタダのゴミだよ。
俺の仕事でwindowsが必要なのはofficeファイル触る位だし、慣れてるlinuxデスクトップの方が便利。 ファイル名ならいざ知らず、ファイルの中身にどんな文字コードを扱うかなんてアプリ次第だろ下らねえ
てかそれこそお得意のCUIで変換でも何でもしろよ >>186
やっぱり基本がわかってないw
あのなぁ、Linuxでも昔はEUC-JPやら外国では色々あったんだぞ
その内容を表示できるかどうかは、アプリの仕事に決まってるだろ。
勝手にデータ書き換えるわけがない。
Windowsで作ってもUTF-8なら、それはUTF-8のデータだし、
UTF-8に対応しているアプリはそれを表示できる。
> メモ帳をアップデートとか、個々のアプリで対応とか本末転倒だろ。
まさか、LinuxはEUC-JPやSJISに個々のアプリは対応してなくて
例えば、vimは自力で対応してなくて。lessはどんな文字コードでも
表示できるとか思ってんのか?基礎知識なさすぎだろw
なんのために多言語対応テキストビューアのlvがLinuxの世界に存在してると思ってるんだよw VirtualBOX併用でWindows、Cygwin、WSL、Ubuntuが一つのPCで動く俺が勝ちだなw
Windows使わないとかクソな縛りはしてないし、Linuxじゃないとダメってバカなこともやってないしw
馬鹿で気違いは自縛自怨なつまらないPCライフ送ればいいと思うよw >>189
それだとDockerが動かなくないか?w
Docker Toolboxはまだあるんだっけか?
俺は作ったアプリのテストのために、それらに加えて
msys2(git bash)環境も揃えているな。仮想マシンはHyperV使ってる。
WSL2もHyperV技術を使用するし、VirtualBoxは早くHyperVと同居できるようになってほしいんだが。
VirtualBoxの方がハードウェア構成を柔軟に設定できるので >>188
どんだけ話を広げる詭弁を続けるつもりなの?バカなの?
linux無いの文字コードやコマンド振る舞いは無論わかってるよ。30年以上unix/linuxで飯食ってる俺にはwslのメリットがないし、あんたのニーズではwslで十分wなのもわかったよ。
wslが楽?ふーん。そーなんだ。よかってね。俺にはゴミだけど。って話なだけだって。カニ食ってる奴にカニカマ美味しいって言ってるようなモンでオカシイだろ。 ゴミというのは別に構わんが、
お前は理由を言ってないと指摘してるだけ。
俺は違いがあると困ったとは言っていない。
お前は困ったと言っているがその理由を言ってない。
そう指摘してるだけ。
事実なら反論しなくていいよ あとできないやつは、やたらと歴が長いことを自慢するよなw
そんなのあっという間に追い越せるのに >>192
差分での問題?
仮にlinux端末では動作するnicのipアドレスとサブネットマスクをデバイス単位で列挙するアプリやスクリプトがあって、コマンドの出力結果を正規表現でパースするテストするの面倒だろ。
wslでunaneするとlinuxって表示されるの?windowsって表示されるの?
30年云々はあんたがあまりにも低レベルなクドい話を続けるからもう少しアタマ使ってくれてもいいよってヒントね。 >>196
> 仮にlinux端末では動作するnicのipアドレスとサブネットマスクをデバイス単位で列挙するアプリやスクリプトがあって、コマンドの出力結果を正規表現でパースするテストするの面倒だろ。
何も問題ないがw
お前のそのスクリプトは、お前のハードウェアでしか動かんのか?
Windowsのハードウェア情報と全く同じゃないだけで、出力される形式は全く一緒なんだから、
なんの問題もなく正規表現でパースできるが?
Ubuntuに搭載されてるipconfigとバイナリファイルレベルで同じものを使ってるんだから
出力形式が変わるわけ無いだろ
> wslでunaneするとlinuxって表示されるの?windowsって表示されるの?
Linuxって表示されるが?w 念の為に言っておくと、ifconfigで表示される結果が
実際のハードウェア情報とは違うっていうのは俺の想像な。
さすがに仮想マシンを使ってるWSL2は違うと思うが、
WSL1だとぱっとみ見る限りmacアドレスとか一緒みたいだし
かなりWindowsのデバイス情報をそのまま提供してるようにも見える。 その手の振る舞いがwslの場合に違いがあるのかを評価試験する必要があるじゃん。
/devとか/procはwslにはあるの? ちなみに/procってmacOSには存在してないんだよな。
SolarisやBSDなんかもデフォルトでは存在しない。
POSIX的には必須じゃないからね。だから各Unix間で互換性もない。
Linuxの場合は/procにかなり依存してるので/procがないと
いろんなコマンドがまともに動かない。
だから当然WSLにも実装されてる。 報告によれば、wslは、VirtualPCやVMWareより遅い場合があるんですよね。 >>203
許容範囲なら問題なかろ?
そういや、この質問には答えずに逃げてたなw
> 動作が遅い。
物理Linuxもスペックの差で動作は遅くなるが
実用可能な最低動作速度は? そういやmacOSもCLIあるが、遅いのはなんでだろう?
CLI使ってる時の体感速度はcygwinと大差ないレベル。
前に聞いたらforkが遅いらしいが。 以前、ShiftJISのドキュメントやアーカイブファイル名などの扱いを確認したときは Linux実機も WSLも挙動は同じでした。化けるときは同じように化けます。
当時のLinux実機とWSLは共に、Debian Buster(testing) + Xfce >>206
そりゃそうだろうな。
わかってる人にとっては当たり前の話なんだが、30年も使っていても
惰性で使ってるだけで、そこらへんの基礎知識がない人もいるわけで
困ったもんだw
さてどこでどんな変換が行われてるかを、考察してほしい。
1. WSL上のUbuntuでdateコマンドを実行すると日本語で日付が表示される。
2. Windowsのネイティブの文字コードはUTF-16である。
3. コマンドプロンプトを起動した時の日本語Windowsのコードページは932(いわゆるSJIS)である。
4. その状態で、wsl上のdateコマンドを実行するために、wsl.exe dateと実行するとコマンドプロンプト上に日本語で日付が表示される。
5. wsl.exe date > date.txt とテキストファイルで出力し、メモ帳で開くとUTF-8ファイルとして開くことができる。
6. type date.txtを実行しテキストファイルの中身を表示すると文字化けしている。
7. wsl.exe cat date.txtと実行すると文字化けしていない。
Windowsの文字コードについて因縁をつけるなら、この挙動の理由を説明できるぐらいの知識がないとダメ よっぽど30年云々に引っかかってるみたいだな。若いの。
説明もクソもwsl使ってないんで知らんがな。つーか、その手のケアをしなきゃなんない辺りが面倒な所ね。nkfでも使って好きにすればいいじゃん。 そりゃ文字コードの違いを吸収する必要があるからね。>>207みたいな6のタイミングでtypeコマンドが入力するファイルがsjisを期待して動作する前にdate.txtをnkf等でsjisに変換しなきゃを文字化けすんだろ。
つーか、その手のチャンポンが面倒くせーからwindowsとwslみたいな状態で使わず、linuxだけで使ってる方が楽。
そもそもnkfなんて、windowsのエディタしか使えないクソ野郎が文字コードや改行コードに無頓着に出力したファイルを使う時に使うぐらいだってーの。 WSLは出てくるのが10年遅い
プログラマの脱Windowsの流れは止まんねーよ手遅れだバーカ 先見の明があるプログラマはとっくにwindowsなんて捨ててるけど、そうじゃないプログラマはvsにしがみついて離れない。その救済としてwslを片道切符的に用意して徐々にlinuxへの移行を促してるとかじゃねーの? WSL は、クラウド(Azure)のユーザーを増やすため、サーバーサイドで Linux
を動かすテスト環境を用意したということですかね。
しかし、Azureは、Windowsサーバーで動くんじゃないんですか? wslってGUIから上のレイヤ無いだろ?主張が斜め上過ぎねぇか?w >>213
Azure Virtual Machinesでは、Linuxを動かす仮想マシンをサーバー上に作れる
らしいです。
でもLinuxサーバーの良さは、OSが無料なのでレンタルサーバー代も安く済むこと
だったはずで、果たしてAzureがそのレベルの安さを持続的に実現できるのか
疑問ですね。株主への配当も考えれば安い値段で提供することは難しいはずです。 https://docs.microsoft.com/en-us/azure/virtual-machines/linux/tutorial-lamp-stack
Azure VMのLinux上にApacheサーバーをインストールすることが出来るらしい。
これで、何でもやり放題のサーバーが出来るのかもしれない。
三年契約で4.56ドル/月分を前払いするらしい。つまり、年間6,000円で使用できるんだ
そうだ。しかし、XreaのCoreServerやSAKURAなどと比べればそんなに安くは無いな。
サーバーに敢えて仮想マシンまで使って何かやる用途は限られると思うし。 そういえば、MonoはLinuxに対応していたのに、MSが買収後のXamarinは、
Linuxはサポートしなくなって、.NET CORE も、CUIのみでGUIはサポートせず。
結局、LinuxでC#を使ったGUIアプリを作るためには、古いMonoを使うしか
無い状況らしいです。それと同じで、WSLもLinuxの機能のうち、公式に
サポートしているのはCUIのみということのようですね。
つまり、MSは、Linuxは、サーバーOSとして必要なCUI部分だけをサポート
することで、自分の都合の良い部分だけを利用する一方で、
デスクトップOSとしてWindowsからLinuxへの乗り換えは防ごうとしている
ようです。Xamarinの買収も、放ってておけば、Windowsの地位が脅かされる
懸念があったのでそれを防ごうとしたようです。 >>156
ほんとだよ
gome3とかさ
カックカクのアニメーション切りたいだけなのに
別の設定アプリ入れなきゃいないけない
とか
なんだよ
一番メモリ食いなのにさ
シナモンは、ちゃんと標準で設定できて
超感動したんだけど
KDEは、設定できるだけじゃなくて
カクカクもしないでもっと軽かった >>218
だから、ポトペタでGUIアプリ作れる
Qtの話すると
すごい勢いで噛みついてくんのか? >>216
MS,Windows捨ててないじゃん。
そういうでたらめ通り過ぎた嘘ばかり言うから嘘つきだとか馬鹿とか基地外とか言われるんだぞ。
ちったぁ頭つかえよ、この能無し。 >>210
文字コードの違いを吸収してるのはどこって話なんだがw
LinuxでもLANGの設定、例えば、 LANG=ja_JP.EUC-jp にすると
いろいろ文字化けするだろ。Windowsのコマンドプロンプトでは
それがchcpだって話。
それよりも、なぜchcp(コードページ)が932なのに
WSLからの出力が文字化けしないと思う?
それはUnicodeだからだよ。
WindowsはUnicode対応だから、Unicodeに対応してるアプリ
(ようするにLinuxアプリ)と完全にデータのやり取りができる。
Unicodeに対応してないのはtypeコマンドという話。
そして、chcp 65001でUTF-8モードにすれば、typeコマンドはUTF-8として扱う。
WSLとコマンドプロンプトの相互運用が完全にできるわけ
(WindowsでもUnicode対応のコマンドだけを使うならchcp 932でも相互運用が可能)
お前が問題視している文字コードの違いは完全に吸収されている。 >>222
「>>218」にも書きましたが、実際、捨ててないと思います。
むしろ、デスクトップLinuxが流行らないようにあらゆる場所で巧妙に
戦略を立てているように感じられます。 >>224
C#の基盤であるところの.NET は、もともと、.NET FRAMEWORKが母体
になっていたのですが、MSとは関係の無いグループが .NET FRAMEWORK
互換のランタイム(?)である Mono を作ったのですが、その時は、C#の
標準GUIツールキットであるところのWinFormsもLinuxで動作していたようです。
その後、Monoは企業買収などを得て、名前が変わったXamarinへと開発の中心が
写ったそうです。ところが、それをMSが買収してしまいます。そして現在の
Xamarinは、Android, iOSでは動きますが、Linuxでは動かないそうです。
つまり、もともと.NET をLinuxで動かす目的で作られ始めたMonoの当初の
目的は今は全く消えてなくなってしまっているのです。もし、Xamarin
が昔のままLinuxをサポートしていたら、C#製のアプリがほとんど全て
Linuxでも動く事になってしまったことでしょう。それはWindowsの衰退
を招くことは明らかですから、MSは避けたと考えられます。Xamarinの
買収の主たる目的はそれだったと考えるのが妥当でしょう。つまり、
Linuxに塩を売るためではなく、むしろ、Linuxのデスクトップ版が流行る
のを阻止しようとしたのです。
また、.NET COREは、Linuxでも動くとされますが、CUIのみで、今のところ
GUIはサポートされていません。これも、CUI版Linuxは普及の既成事実があるので
諦める一方で、GUI版Linux、つまり、デスクトップ版LinuxにC#アプリが流出
するのを阻止するためと考えられます。MSは、次期 .NET COREは、GUIも
Linuxに対応するとしているのですが、恐らくのらりくらりと先延ばしにして
対応しないと思います。 >>215
> でもLinuxサーバーの良さは、OSが無料なのでレンタルサーバー代も安く済むこと
> だったはずで、
そうだよ。LinuxサーバーだとCALがいらない。
> 果たしてAzureがそのレベルの安さを持続的に実現できるのか
> 疑問ですね。
AzureはLinuxもWindowsも提供してるって知らないのか?
重要な点はWindowsサーバーが、Linuxサーバー並みの価格を実現できるかどうかだろ?
Azureに限らずどのクラウドサービスでもLinuxというOSの価格は無料
あとはインフラのコストということになる。
Windowsを使った場合は、インフラのコスト+CAL(ライセンス料)となるから高い。
例えばAWSだと、同じt3.mediumでLinuxは0.0416USD/時間で、Windowsだと0.06USD/時間
https://aws.あまぞん.com/jp/ec2/pricing/on-demand/
Windowsの方が14.5%ほど高いがその程度。
Azureだと、近いスペックのA2で、Linuxは$0.081/時間、Windowsは$0.121/時間
https://azure.microsoft.com/ja-jp/pricing/calculator/?service=virtual-machines
Windowsの方が15%ほど高い。
どちらもWindowsの方が高いが、この程度なわけだ。高いがCALほどではない。
なぜならCAL自体はクラウド業者が払っていて一般の利用者は払う必要がないから
【TIPS】CALが不要な「さくらのクラウド」Windows Serverプランでファイルサーバーを構築しよう!ユーザー数が増加するWindows Serverはクラウドで!
https://cloud-news.sakura.ad.jp/2016/05/24/fileserver-windows-server-on-sakuracloud/
クラウドの登場でLinuxサーバーとWindowsサーバーの価格は昔ほど大きな差はではなくなってる。 >>224
> むしろ、デスクトップLinuxが流行らないようにあらゆる場所で巧妙に
> 戦略を立てているように感じられます。
なんで、デスクトップLinuxが流行るように、MSが頑張らなければならないと思ってるんだ?w
MSは何もしてないだけだろ。
MSはWindowsとAzureを普及させるために戦略を立てているだけ
デスクトップLinuxは興味がない。
流行らないようにしてるんじゃなくて、何もしてないだけ。 >>225
なお、2ヶ月ほど前の2019/09/23 にリリースされた .NET Core 3.0では、
Windows版に限りWinFormsおよびWPFのサポートがされるように
なったのですが、Linux版では依然としてサポートされていません。 >>227
ですが、MSのXamarin買収が、Linuxのデスクトップ版を流行らせる
方向にMSが「舵を切った」などということを主張する人がいるのです。 Linuxのデスクトップを普及させたいなら、
Linux陣営が頑張るのが筋だと思うが、
MicrosoftがLinuxデスクトップにかんして何もしなければ、
流行らないように戦略を立ててると考える発想がおかしい
Linuxデスクトップの発展を、MSだよりにしてるから
いつまでたってもLinuxデスクトップはまともにならないんだろう >>229
> 方向にMSが「舵を切った」などということを主張する人がいるのです。
その主張をしてる人は、MSとはなんの関係もない人ですよね? >>227
「Linuxデスクトップ版の普及を阻止した」
事がばれてしまうと、独占禁止法違反が騒がれるので
「何もして無い」
ということにしておかないといけません。
Xamarin買収の本当の意図がばれるのを防ぐために、
クラウドでは仮想マシンでLinuxも使えるようにしておかなければ
なりませんでした。
ついでにWSLもCUIだけは選択的に動くようにして混乱させて
買収の真意がばれないようにする必要があったのです。 >>231
はい。それは、Linuxのステークホルダーでしょう。 >>232
だから、Linuxのデスクトップ環境の普及を、MSだよりにするのやめろってw
さっきから.NETでLinux版GUIアプリを作れるようにしてくださいって
MSにお願いばかりしてるじゃないかw .NETで対応してくれないと、Linuxデスクトップ環境は
普及しないって、終わってると思うんだよねw >>227
なにもしてないって言うけど
ザマリン買収したんでしょ?
まぁ、.NETのWebFormなんか
なんもしないで放置して
ウェードアウトしようとしてる
って
まるわかりだけど
いっつもコレからはこれニダ
って誘導しといて
始めたこと
ほっぽり投げてさ
もうMSの先導とか.NETなんか
使ったって良いことないって
さとったから
GUIアプリはQt
Webは非MSに切り替えてるけどね >>230
Monoはもともと.NETをあらゆる環境で使えるようにすることを目的として
生まれました。
そのころの Xamarinは、Linuxで.NETのGUIが動く目的を達成しつつあったのです。
C#の標準GUIツールキットであるWinFormsがLinuxで動いていたそうです。
Monoの開発母体が何度か買収されて、経緯は知りませんが、その遺志を受け継い
だのがXamarinだったのです。
それで、Xamarinが開発の中心になっており、Xamarinがなくなれば、Mono
の開発も弱まります。
ところが、MSがXamarinを買収します。
昔のXamarinでは動いていたLinux版WinFormsが、現在のXamarinでは
動かなくなりました。
これで果たして、MSは本当に「何もしなかった」ということが通用するでしょうか。
プログラムは修正されるとき、過去の機能が失われないように気をつけながら行います。
もし、そのような配慮なく修正すれば、過去の機能は失われます。
しかし、「過去の機能が失われることを配慮せずに修正」することが、
果たして「何もしなかった」という言葉に該当するのでしょうか。 >>223
はぁ。面倒くせーなぁ。
chcp 65001にしたところで既存のファイルの文字コードが変わらなくて、当然sjisのまま。wsl上のubuntuのutf-8のファイルで相互に読み込むと、ユーザーは文字コードの違いを常に意識する必要があるだろ。
最近のlinuxなら最初っからutf-8でユーザーは文字コードの違いを意識する必要がない。
どっちが楽なのかなんてクッソ素人でもわかんだろ。文字コードの違いを完全に吸収してる?ハハハ。>>207 でchcp付きで実行してログをここに貼ってみそ。 >>236
XamarinはMS買収前から、
Linux GUIには対応していません >>238
> chcp 65001にしたところで既存のファイルの文字コードが変わらなくて、当然sjisのまま。
それはLinuxでも同じですよw 知らないんですか?www >>238
> 最近のlinuxなら最初っからutf-8でユーザーは文字コードの違いを意識する必要がない。
おかしいですね。最近のWindowsなら、メモ帳のデフォルトはUTF-8だから
ユーザーは文字コードの違いを意識する必要がないんですがww >>238
ほんとWindowsはめんどくさいよ
LinuxデスクトップのQtCreaterでサクッと
書いたアプリを
Windowsでビルドしようと思ったら
文字コードがどうのこうって
エラー祭りで
ビルドできない
マジでめんどくさい >>230
過去のXamarinでは、C#の標準GUI版ツールキットであるWinFormsを
使ったC#アプリがLinuxでも動いていたのです。ところが、
MSがXamarinを買収してしばらくたった現在、なぜか過去に達成し終えた
その機能が失われました。MSは、本当に「何もしなかった」のでしょうか。 >>239
でも、ザマリンがmono買収してから
買収したんでしょ? >>238
> >>207 でchcp付きで実行してログをここに貼ってみそ。
これでいいっすか?
https://imgur.com/ZyM4055
WSLとの相互運用完璧ですわwww >>241
おいおい。メモ帳だけじゃないだろ。bom付きの問題は黙ってるつもり? >>246
> Xamarinの前身のMonoは、WinFormsをx11に変換する能力を持っているそうです。
今のMonoも、WinForms対応です(笑)
https://www.mono-project.com/docs/gui/winforms/
Monoの現在のgithubプロジェクト
https://github.com/mono/mono
精力的に開発続行中ですね! >>248
> おいおい。メモ帳だけじゃないだろ。bom付きの問題は黙ってるつもり?
BOM付き? メモ帳のデフォルトはBOM無しUTF-8ですが? >>249
ところが、Xamarinは、Linuxに対応していません。 ■ このスレッドは過去ログ倉庫に格納されています