ロジカルシンキングを考えてみる

ロジカルシンキングと言う言葉があり、主にビジネスの世界で使われている。数社のコンサルタント会社が使っているようである。
そのロジカルシンキングとは、何なのかを検証してみよう。

ロジカルシンキングの定義は

ロジカルシンキング(logical thinking)とは、一貫していて筋が通っている考え方、あるいは説明の仕方のことである。

とされている。筋が通っている?考え方?または説明の仕方?この定義だとロジカル関係なくないかな?筋が通っていればロジカルシンキングになるということなのか?甚だ疑問が浮かぶ。

日本語だと論理思考、論理的思考と言われるようだが、議論の余地があるとwikipediaでは主張されている。
また、英語圏で一般的に用いられる言葉でなく、日本で浸透してるという意味では、和製英語であると言える。

まずロジカルシンキングの「シンキング」、日本語では「思考」とは何か。

思考(しこう、英: Thinking)は、考えや思いを巡らせる行動[1]であり、結論を導き出す[2]など何かしら一定の状態に達しようとする過程において、筋道や方法など模索する精神の活動である[3] 出典Wikipedia

思考とは、思いを巡らせる行動であり、精神の活動であると定義されている。
ロジカルシンキング、論理思考とは、論理的である、思いを巡らす行動であり、精神の活動であることを意味しようとしているのか。

次にロジカルシンキングのロジカル、理論について考えてる。この場合の理論は理論学の理論ではなく、筋が通っているという意味合いで理論という言葉を使っている。具体的に何とか理論を使うというものでもなく、いくつかの方法を使用した、思考であると言っている。理論という言葉が誤って使われているのだ。wikipediaに改善の余地があると指定されているのは、その不正確な言葉の使用が理由であると伺えよう。
さらに、思考という単語も使っているが、思考は思いを巡らす行動、精神の活動であって、直接にロジカルと繋がらない、独立した別なものである。このロジカルは、思考をコントロールするものでも、影響を与えるものでもない。
つまり、ロジカルシンキングという言葉は、不正確で誤った意味に捉えかねない紛らわしく不適切な言葉であるといえる。

fvwmに、fvwm-menu-desktop を使用し XDG Menusをメニュー追加

fvwmのメニューはカスタマイズが簡単にできるが、自動的に生成されるメニューはDebianメニューを使っていたが、
もっと便利なXDG Menusがあったのでこれを使えるように設定した。
StartFunctionsに以下を追加 

+ I Test (!f $[FVWM_USERDIR]/.XDGMenu) XDGRegen
+ I Read $[FVWM_USERDIR]/.XDGMenu

.XDGMenuファイルがないと、XDGRegenを実行し、そのファイルを読み込む。
XDGRegenは、以下で設定する。

DestroyFunc XDGRegen
AddToFunc XDGRegen
+ I PipeRead 'fvwm-menu-desktop --regen-cmd XDGRegen > \
    $[FVWM_USERDIR]/.XDGMenu; echo "Nop"'
+ I Read $[FVWM_USERDIR]/.XDGMenu

https://www.mankier.com/1/fvwm-menu-desktop

$avrdude メモ

$avrdude -P /dev/ttyUSB0 -b 19200 -c avrisp -p m328p 
$avrdude -P /dev/ttyUSB0 -b 19200 -c avrisp -p m328p -v -e -U lfuse:w:0xe2:m  

/etc/avrdude.conf

programmer
  id="ftdi";
  desc = "FT232R Synchronous BitBang";
  #type = "ft245r";
  type = "ftdi_syncbb";
  miso = 3;  # CTS X3(1)
  sck = 5;  # DSR X3(2)
  mosi = 6;  # DCD X3(3)
  reset = 7;  # RI X3(4)
;
sudo avrdude -c ftdi -p m328p  -P ft0 -b 4800
$sudo avrdude -b 19200 -c ftdi  -p m328p -P ft0 -v -e -U lfuse:w:0xff:m 
$sudo avrdude -c ftdi -p m328p  -P ft0 -b 19200 -F -v -e -U flash:w:/usr/share/arduino/hardware/arduino/bootloaders/atmega/ATmegaBOOT_168_atmega328.hex
http://eleccelerator.com/fusecalc/fusecalc.php?chip=atmega328p

raid1 片方消えていた

16.10を使用してたが、raid1の片方が消えていた。active raid1からデバイス名が消えていた。

$sudo mdadm --manage /dev/md1 --add /dev/sdd5

新たに追加で、追加できたが。なんでだろ。

後日また、消えた。sdd5が
再度addした。
大丈夫か Linux ubuntu16-10-64 4.8.0-37-generic #39-Ubuntu SMP Thu Jan 26 02:27:07 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

Ubuntu 16.10にしたら、ハイバネートできなくなった

http://askubuntu.com/questions/839147/hibernation-with-ubuntu-16-10-fails
これか?

richblのやり方だと起動時にカーネルパニックおこしたわ
crysmanのやり方は、わしの16.04のハイバネートとほぼ同じだが、画面が暗くなって反応しなくなった。
したがって、16.10はわしの環境だと、できないということなのかぁ。

/etc/initramfs-tools/conf.d/resume に RESUME=UUID=91ccfcbe-de30-457e-9998-953ea78588c6 に変更
/etc/default/grubの

GRUB_CMDLINE_LINUX_DEFAULT="net.ifnames=0 biosdevname=0 quiet splash resume=UUID=91ccfcbe-de30-457e-9998-953ea78588c6"

変更してみた
sudo update-initramfs -u
sudo update-grub
これでもだめだ

https://help.ubuntu.com/community/PowerManagement/Hibernate
これか?

Platform is the default and recommended mode of hibernation. Unfortunately, the “platform” mode of hibernation does not work on some systems with a broken BIOS. In such cases the “shutdown” mode of hibernation might work.

http://askubuntu.com/questions/768136/how-can-i-hibernate-on-ubuntu-16-04
ここにも書いてあるが

結果;うまく動かない

これは?

$sudo apt-get install hibernate
パッケージリストを読み込んでいます... 完了
依存関係ツリーを作成しています                
状態情報を読み取っています... 完了
以下の追加パッケージがインストールされます:
  uswsusp
提案パッケージ:
  915resolution
以下のパッケージが新たにインストールされます:
  hibernate uswsusp

これもだめ

https://ubuntuforums.org/showthread.php?t=2306178
これは?
http://d.hatena.ne.jp/kakurasan/20080421/p1
これは?
だめだな
Edit /etc/systemd/logind.conf to set HandleLidSwitch=hibernate (optional: permits hibernate to start on lid close)
やってみたどうだ?だめだった。HandleLidSwitchは、ラップトップとかで、そのキーが押された時の動作のようだ。
環境によってカーネルが動作できてない。
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1566302
結論 カーネル次第

inxi -GCS

これが原因か

http://askubuntu.com/questions/76488/system-wont-boot-unless-i-type-exit-at-initramfs-prompt

Boot Degraded RAID
Modify /etc/initramfs-tools/conf.d/mdadm
BOOT_DEGRADED=true
Update initram
sudo update-initramfs -u
Reboot

これか?
だめだった

http://opensuse.opensuse.narkive.com/IOLnQHP2/configuring-a-working-suspend-to-disk-method

これか?

→関連
関連投稿;Ubuntu16.04のサスペンド、ハイバネート

結末として。17.04 zestyに夢を託して、いじってみたが、やはりハイバネート失敗。
LTSに戻すしか方法はなさそうだ。

ちょっと待った!
17.04で遂にハイバネートできそう!
何度もテストをしていたが。ヒントを掴んだ気がする。

grubが関係してたのだ!
grub-installをした、システムでない、他のパーティションのシステムから起動させた、17.04でハイバネートができるようになった。しかし、grub-installを行ったシステムでは、ハイバネートできない。
これ大きなヒントになりそうですね。もう少し探ってみるか。

	recordfail
	load_video
	gfxmode $linux_gfx_mode
	insmod gzio
	if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
	insmod part_msdos
	insmod ext2
	set root='hd1,msdos7'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd1,msdos7 --hint-efi=hd1,msdos7 --hint-baremetal=ahci1,msdos7  14949105-0ead-4826-aab5-155b9042af46
	else
	  search --no-floppy --fs-uuid --set=root 14949105-0ead-4826-aab5-155b9042af46
	fi
	echo	'Linux 4.10.0-19-generic をロード中...'
        linux	/boot/vmlinuz-4.10.0-19-generic root=UUID=14949105-0ead-4826-aab5-155b9042af46 ro  resume=UUID=47ef2af5-e4cd-4f23-9f64-1466b3540905
	echo	'初期 RAM ディスクをロード中...'
	initrd	/boot/initrd.img-4.10.0-19-generic

grub起動時ここの1行から5行目まで削除してコントロールXで起動して、ハイバネートして。再起動時にも同様に行うと、ハイバネート起動に成功することができた。
ただ、毎回、削除するのも面倒だし。消して保存を考えないとならない。

という訳で、設定を保存するためには、どこをいじろうかな。
/etc/grub.d/10_linux にload_video,gfxmodeがあるんで、ここを編集した。
でも、ハイバネートからの起動に失敗することあるんだよね。

 diff /etc/grub.d/10_linux ./10_linux.org 
145,155c145,158
< #  if [ "x$GRUB_GFXPAYLOAD_LINUX" = x ]; then
< #      echo "	load_video" | sed "s/^/$submenu_indentation/"
< #  else
< #      if [ "x$GRUB_GFXPAYLOAD_LINUX" != xtext ]; then
< #	  echo "	load_video" | sed "s/^/$submenu_indentation/"
< #      fi
< #  fi
< #  if ([ "$ubuntu_recovery" = 0 ] || [ x$type != xrecovery ]) && \
< #     ([ "x$GRUB_GFXPAYLOAD_LINUX" != x ] || [ "$gfxpayload_dynamic" = 1 ]); then
< #      echo "	gfxmode \$linux_gfx_mode" | sed "s/^/$submenu_indentation/"
< #  fi
---
>   if [ "x$GRUB_GFXPAYLOAD_LINUX" = x ]; then
>       echo "	load_video" | sed "s/^/$submenu_indentation/"
>   else
>       if [ "x$GRUB_GFXPAYLOAD_LINUX" != xtext ]; then
> 	  echo "	load_video" | sed "s/^/$submenu_indentation/"
>       fi
>   fi
>   if ([ "$ubuntu_recovery" = 0 ] || [ x$type != xrecovery ]) && \
>      ([ "x$GRUB_GFXPAYLOAD_LINUX" != x ] || [ "$gfxpayload_dynamic" = 1 ]); then
>       echo "	gfxmode \$linux_gfx_mode" | sed "s/^/$submenu_indentation/"
>   fi
> 
>   echo "	insmod gzio" | sed "s/^/$submenu_indentation/"
>   echo "	if [ x\$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi" | sed "s/^/$submenu_indentation/"
157,159d159
< #  echo "	insmod gzio" | sed "s/^/$submenu_indentation/"
< #  echo "	if [ x\$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi" | sed "s/^/$submenu_indentation/"
< #

ハイバネートからの復帰に失敗することがあり、何とかならないものかと。
amdgpuが自分の環境だと、失敗の原因のようだ。
/etc/modprobe.d/blacklist.conf

#blacklist radeon
blacklist amdgpu

でblacklistにしとく。radeonだけkmsでロードされるようにする。
GRUBでradeon.modeset=1 radeon.dpm=0と記述することにより、ハイバネートが成功するようになった。

/etc/default/grub

GRUB_CMDLINE_LINUX_DEFAULT="resume=UUID=47ef2af5-e4cd-4f23-9f64-1466b3540905 radeon.modeset=1 radeon.dpm=0 "

/etc/grub.d/10_linux はオリジナルのものにしたが問題なくハイバネートと復帰ができた。

これで、継続してハイバネートできればよいが。

その後、一日数回ハイバネートしてるが、8日は無事に復帰できている。 

$uptime
 22:38:46 up 8 days, 14:14,  2 users,  load average: 0.89, 0.50, 0.49

つづく