侵入改竄検知システム AIDE を使うメモ

■侵入改竄検知システム AIDE を使うメモ
 長くIDSとしてOsirisを使ってきたが時勢に合わなくなってしまったので、CentOS/ScientificLinuxに標準装備されているAIDEを使ってみたメモ。

■インストールと簡単な使い方
[code]# yum install aide

設定編集(コメント充実)
# vi /etc/aide.conf
R = p+l+i+n+u+g+s+m+acl+selinux+xattrs+md5

初期化
# aide -i

比較用DB作成
# cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

比較
# aide -C

通常用途
# aide -u[/code]

■CentOS5系でselinuxで問題が出るケースの設定変更例
[code]# vi /etc/aide.conf

R = p+l+i+n+u+g+s+m+acl+xattrs+md5
L = p+l+i+n+u+g+acl+xattrs
> = p+l+u+g+i+n+S+acl+xattrs

DIR = p+l+i+n+u+g+acl+xattrs

PERMS = p+l+i+u+g+acl

DATAONLY = p+l+n+u+g+s+acl+xattrs+md5+sha256+rmd160+tiger[/code]

■Prelink関連のエラーが出る場合の設定変更例
[code]# sed -i ‘/^PRELINKING=yes$/s/yes/no/’ /etc/sysconfig/prelink
# /usr/sbin/prelink -ua[/code]

■cron用script例
[code]# vi /root/script/aide.sh
#!/bin/bash

/usr/sbin/aide -u
/bin/cp -fr /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz[/code]

■MyNETS用改竄検知設定例(/var/www/sns/wwwをSNS rootとする)
[code]# vi /etc/aide.conf
# MyNETS SNS DIR
/var/www/sns/www NORMAL
!/var/www/sns/www/img
!/var/www/sns/www/var[/code]

■参考リンク
http://pooh.gr.jp/?p=9633
http://blog.cecily.jp/kotou/51/
http://aikotobaha.blogspot.jp/2011/11/rhel-aide.html

, , , ,
とりあえず付けておく無駄ではなかったなまぁまぁ読めたちょっと役に立ったかなかなり良かったかも (まだ評価されていません)
Loading...

CentOS6/ScientificLinux6にmroongaを導入する

■CentOS6/ScientificLinux6にmroongaを導入する
 CentOS6/ScientificLinux6にはmysql5.1.xが導入されていて、日本語全文検索にtritonnが利用できないので、後継プロジェクトになっているmroongaを導入し、日本語全文検索を可能にする。実際の手順はほぼmroongaの公式HPの通り。

 mroonga
 http://mroonga.github.io/ja/

■インストール(mysqlは導入済み)
[code]# rpm -ivh http://packages.groonga.org/centos/groonga-release-1.1.0-1.noarch.rpm

※ScientificLinux6は以下のbaseurl修正を行う
# vi /etc/yum.repos.d/groonga.repo
baseurl=http://packages.groonga.org/centos/6/$basearch/

# yum makecache
# yum install -y mysql-mroonga groonga-tokenizer-mecab

# mysql -u root -p
mysql> show engines;
mysql> INSTALL PLUGIN mroonga SONAME ‘ha_mroonga.so’;[/code]

■動作確認方法
[code]# mysql -u root -p
mysql> show engines;
mysql> use test;
mysql> create table diaries ( id INT primary key auto_increment, content varchar(255), fulltext index (content) ) engine = mroonga default charset utf8;
mysql> INSERT INTO diaries (content) VALUES (“明日の天気は晴れでしょう。”);
mysql> INSERT INTO diaries (content) VALUES (“明日の天気は雨でしょう。”);
mysql> SELECT * FROM diaries WHERE MATCH(content) AGAINST(“晴れ”);[/code]
検索できればOK。
検索スコアでソートは以下で確認。
[code]mysql> INSERT INTO diaries (content) VALUES (“今日は晴れました。明日も晴れるでしょう。”);
mysql> INSERT INTO diaries (content) VALUES (“今日は晴れましたが、明日は雨でしょう。”);
mysql> SELECT *, MATCH (content) AGAINST (“晴れ”) FROM diaries WHERE MATCH (content) AGAINST (“晴れ”) ORDER BY MATCH (content) AGAINST (“晴れ”) DESC;[/code]

■tritonnデータからの移行
 tritonnでダンプしたデータのうち以下の部分を修正する(ストレージモードで利用)

[code] FULLTEXT KEY `fullindex` (`body`) /*!50100 WITH PARSER `mecab` */
) ENGINE=MyISAM AUTO_INCREMENT=100 DEFAULT CHARSET=utf8;
 ↓
 FULLTEXT INDEX (`body`)
) ENGINE=mroonga AUTO_INCREMENT=100 DEFAULT CHARSET=utf8;[/code]
これで新しいDBへインポートすればOK。

, , , ,
とりあえず付けておく無駄ではなかったなまぁまぁ読めたちょっと役に立ったかなかなり良かったかも (まだ評価されていません)
Loading...

CentOS6.xのELrepo Kernel パラメータ差分メモ

■CentOS6.xのELrepo Kernel パラメータ差分メモ
 前記事で導入したELrepoのKernel3.0.68とCentOS6.3のkernel2.6.32のkernelパラメータの差分を取ってみたのでメモしておく。

以下のコマンドで取得したパラメータをそれぞれのカーネルで起動して取得。
[code]# sysctl -a[/code]

kernel情報とdiffを取った結果。
[code]# uname -a
Linux localhost.localdomain 3.0.68-1.el6.elrepo.i686 #1 SMP Mon Mar 4 00:29:41 EST 2013 i686 i686 i386 GNU/Linux

# diff k3s.txt k2s.txt
45c45
< fs.dentry-state = 10635 4581 45 0 0 0 --- > fs.dentry-state = 10781 5172 45 0 0 0
47,51c47,51
< fs.epoll.max_user_watches = 345206 < fs.file-max = 100510 < fs.file-nr = 672 0 100510 < fs.inode-nr = 9825 756 < fs.inode-state = 9825 756 0 0 0 0 0 --- > fs.epoll.max_user_watches = 331776
> fs.file-max = 100902
> fs.file-nr = 672 0 100902
> fs.inode-nr = 9968 218
> fs.inode-state = 9968 218 0 0 0 0 0
56a57
> fs.mqueue.msg_default = 10
57a59
> fs.mqueue.msgsize_default = 8192
63d64
< fs.pipe-max-size = 1048576 70a72 > fs.quota.warnings = 1
85a88
> kernel.exec-shield = 1
87d89
< kernel.ftrace_enabled = 1 94a97 > kernel.kexec_load_disabled = 0
100c103
< kernel.kptr_restrict = 0 --- > kernel.kptr_restrict = 1
107c110
< kernel.msgmni = 1740 --- > kernel.msgmni = 1736
110c113
< kernel.osrelease = 3.0.68-1.el6.elrepo.i686 --- > kernel.osrelease = 2.6.32-279.22.1.el6.i686
116c119
< kernel.panic_on_oops = 0 --- > kernel.panic_on_oops = 1
129,131c132,134
< kernel.pty.nr = 1 < kernel.random.boot_id = f6ba4b47-c313-4466-9e3f-2e96cae9d48c < kernel.random.entropy_avail = 1247 --- > kernel.pty.nr = 2
> kernel.random.boot_id = 31a3cfc3-28b9-4b80-a174-7c8af4ae3590
> kernel.random.entropy_avail = 131
134c137
< kernel.random.uuid = 11a6f5a8-2b73-402a-8f3c-d24da95c6ccb --- > kernel.random.uuid = 0ec9460c-05d5-4552-9855-9705f3dee9a0
138c141,142
< kernel.sched_autogroup_enabled = 1 --- > kernel.sched_autogroup_enabled = 0
> kernel.sched_cfs_bandwidth_slice_us = 5000
140c144,146
< kernel.sched_latency_ns = 6000000 --- > kernel.sched_compat_yield = 0
> kernel.sched_features = 3183
> kernel.sched_latency_ns = 5000000
142c148
< kernel.sched_min_granularity_ns = 750000 --- > kernel.sched_min_granularity_ns = 1000000
150a157
> kernel.shm_rmid_forced = 0
153a161,163
> kernel.slow-work.max-threads = 4
> kernel.slow-work.min-threads = 2
> kernel.slow-work.vslow-percentage = 50
155d164
< kernel.stack_tracer_enabled = 0 158c167 < kernel.threads-max = 15806 --- > kernel.threads-max = 15876
163c172
< kernel.version = #1 SMP Mon Mar 4 00:29:41 EST 2013 --- > kernel.version = #1 SMP Wed Feb 6 00:31:03 UTC 2013
165c174
< kernel.watchdog_thresh = 10 --- > kernel.watchdog_thresh = 60
171d179
< net.core.netdev_tstamp_prequeue = 1 173c181 < net.core.rmem_default = 114688 --- > net.core.rmem_default = 188416
178c186
< net.core.wmem_default = 114688 --- > net.core.wmem_default = 188416
398,420d405
< net.ipv4.netfilter.ip_conntrack_buckets = 16384 < net.ipv4.netfilter.ip_conntrack_checksum = 1 < net.ipv4.netfilter.ip_conntrack_count = 16 < net.ipv4.netfilter.ip_conntrack_generic_timeout = 600 < net.ipv4.netfilter.ip_conntrack_icmp_timeout = 30 < net.ipv4.netfilter.ip_conntrack_log_invalid = 0 < net.ipv4.netfilter.ip_conntrack_max = 64172 < net.ipv4.netfilter.ip_conntrack_tcp_be_liberal = 0 < net.ipv4.netfilter.ip_conntrack_tcp_loose = 1 < net.ipv4.netfilter.ip_conntrack_tcp_max_retrans = 3 < net.ipv4.netfilter.ip_conntrack_tcp_timeout_close = 10 < net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait = 60 < net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 432000 < net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait = 120 < net.ipv4.netfilter.ip_conntrack_tcp_timeout_last_ack = 30 < net.ipv4.netfilter.ip_conntrack_tcp_timeout_max_retrans = 300 < net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_recv = 60 < net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_sent = 120 < net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_sent2 = 120 < net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait = 120 < net.ipv4.netfilter.ip_conntrack_udp_timeout = 30 < net.ipv4.netfilter.ip_conntrack_udp_timeout_stream = 180 < net.ipv4.ping_group_range = 1 0 425d409 < net.ipv4.route.gc_interval = 60 436a421 > net.ipv4.route.secret_interval = 600
440c425
< net.ipv4.tcp_adv_win_scale = 1 --- > net.ipv4.tcp_adv_win_scale = 2
445d429
< net.ipv4.tcp_challenge_ack_limit = 100 447d430 < net.ipv4.tcp_cookie_size = 0 463c446 < net.ipv4.tcp_mem = 21180 28243 42360 --- > net.ipv4.tcp_mem = 81984 109312 163968
473c456
< net.ipv4.tcp_rmem = 4096 87380 903776 --- > net.ipv4.tcp_rmem = 4096 87380 3497984
487c470
< net.ipv4.tcp_wmem = 4096 16384 903776 --- > net.ipv4.tcp_wmem = 4096 16384 3497984
489c472
< net.ipv4.udp_mem = 21180 28243 42360 --- > net.ipv4.udp_mem = 81984 109312 163968
506d488
< net.ipv6.conf.all.force_tllao = 0 535d516 < net.ipv6.conf.default.force_tllao = 0 564d544 < net.ipv6.conf.eth0.force_tllao = 0 593d572 < net.ipv6.conf.eth1.force_tllao = 0 622d600 < net.ipv6.conf.lo.force_tllao = 0 697c675 < net.ipv6.route.gc_elasticity = 9 --- > net.ipv6.route.gc_elasticity = 0
704c682
< net.ipv6.route.min_adv_mss = 1220 --- > net.ipv6.route.min_adv_mss = 1
710c688
< net.netfilter.nf_conntrack_count = 16 --- > net.netfilter.nf_conntrack_count = 1
717c695
< net.netfilter.nf_conntrack_max = 64172 --- > net.netfilter.nf_conntrack_max = 64432
746c724
< net.nf_conntrack_max = 64172 --- > net.nf_conntrack_max = 64432
756a735
> vm.extra_free_kbytes = 0
764,766c743
< vm.min_free_kbytes = 44904 < vm.min_slab_ratio = 5 < vm.min_unmapped_ratio = 1 --- > vm.min_free_kbytes = 3794
769d745
< vm.nr_hugepages_mempolicy = 0 772d747 < vm.numa_zonelist_order = default 785c760 < vm.zone_reclaim_mode = 0 --- > vm.would_have_oomkilled = 0[/code]

, ,
とりあえず付けておく無駄ではなかったなまぁまぁ読めたちょっと役に立ったかなかなり良かったかも (まだ評価されていません)
Loading...

CentOS5.xのELrepo Kernel パラメータ差分メモ

■CentOS5.xのELrepo Kernel パラメータ差分メモ
 前記事で導入したELrepoのKernel3.0.66とCentOS5.9のkernel2.1.18のkernelパラメータの差分を取ってみたのでメモしておく。

以下のコマンドで取得したパラメータをそれぞれのカーネルで起動して取得。
[code]# sysctl -a[/code]

diffを取った結果。
[code]# cat k3-diff-k2.txt
2d1
< debug.exception-trace = 1 26c25 < dev.cdrom.info = Can write RAM: 1 --- dev.cdrom.info = Can write RAM: 0 29c28 < dev.cdrom.info = drive name: sr0 --- dev.cdrom.info = drive name: hdc 36a36 dev.rtc.max-user-freq = 64 41c41 < fs.dentry-state = 6192 4181 45 0 0 0 --- fs.dentry-state = 3892 2599 45 0 0 0 43,47c43,46 < fs.epoll.max_user_watches = 200546 < fs.file-max = 50584 < fs.file-nr = 224 0 50584 < fs.inode-nr = 5754 354 < fs.inode-state = 5754 354 0 0 0 0 0 --- fs.file-max = 51100 fs.file-nr = 192 0 51100 fs.inode-nr = 3429 136 fs.inode-state = 3429 136 0 0 0 0 0 59d57 < fs.pipe-max-size = 1048576 66c64,65 < fs.quota.syncs = 0 --- fs.quota.syncs = 20 fs.quota.warnings = 1 71d69 < kernel.auto_msgmni = 1 74d71 < kernel.bootloader_version = 1 75a73 kernel.cap-bound = -257 77d74 < kernel.core_pipe_limit = 0 82,83c79 < kernel.ftrace_dump_on_oops = 0 < kernel.ftrace_enabled = 1 --- kernel.exec-shield = 1 90,91d85 < kernel.io_delay_type = 0 < kernel.keys.gc_delay = 300 96,97d89 < kernel.kptr_restrict = 0 < kernel.kstack_depth_to_print = 24 103c95 < kernel.msgmni = 1001 --- kernel.msgmni = 16 105,106c97,98 < kernel.nmi_watchdog = 1 < kernel.osrelease = 3.0.66-1.el5.elrepo --- kernel.nmi_watchdog = 0 kernel.osrelease = 2.6.18-348.1.1.el5 111,112c103 < kernel.panic_on_io_nmi = 0 < kernel.panic_on_oops = 0 --- kernel.panic_on_oops = 1 114,116d104 < kernel.perf_event_max_sample_rate = 100000 < kernel.perf_event_mlock_kb = 516 < kernel.perf_event_paranoid = 1 118d105 < kernel.poweroff_cmd = /sbin/poweroff 121d107 < kernel.printk_delay = 0 126,127c112,113 < kernel.random.boot_id = 883b8f61-6fd5-42fb-9287-c08e4aaa7d3b < kernel.random.entropy_avail = 457 --- kernel.random.boot_id = ed819e04-5a67-4c80-b57c-00953773b11e kernel.random.entropy_avail = 354 130c116 < kernel.random.uuid = 1c11957b-b8e2-4e0b-bab1-dec3633f88b5 --- kernel.random.uuid = 55467d54-5ae5-4b5b-a8c8-f3fabea6264e 132c118 < kernel.randomize_va_space = 2 --- kernel.randomize_va_space = 1 134,145c120 < kernel.sched_autogroup_enabled = 1 < kernel.sched_child_runs_first = 0 < kernel.sched_latency_ns = 6000000 < kernel.sched_migration_cost = 500000 < kernel.sched_min_granularity_ns = 750000 < kernel.sched_nr_migrate = 32 < kernel.sched_rt_period_us = 1000000 < kernel.sched_rt_runtime_us = 950000 < kernel.sched_shares_window = 10000000 < kernel.sched_time_avg = 1000 < kernel.sched_tunable_scaling = 1 < kernel.sched_wakeup_granularity_ns = 1000000 --- kernel.sched_interactive = 2 150a126 kernel.softlockup_thresh = 60 153,154c129 < kernel.threads-max = 7957 < kernel.timer_migration = 1 --- kernel.threads-max = 15976 156,160c131,133 < kernel.usermodehelper.bset = 4294967295 4294967295 < kernel.usermodehelper.inheritable = 4294967295 4294967295 < kernel.version = #1 SMP PREEMPT Thu Feb 21 15:32:49 EST 2013 < kernel.watchdog = 1 < kernel.watchdog_thresh = 10 --- kernel.vdso = 1 kernel.vdso_populate = 0 kernel.version = #1 SMP Tue Jan 22 16:24:03 EST 2013 166d138 < net.core.netdev_tstamp_prequeue = 1 168,170c140,141 < net.core.rmem_default = 114688 < net.core.rmem_max = 114688 < net.core.rps_sock_flow_entries = 0 --- net.core.rmem_default = 110592 net.core.rmem_max = 110592 172,174c143,144 < net.core.warnings = 1 < net.core.wmem_default = 114688 < net.core.wmem_max = 114688 --- net.core.wmem_default = 110592 net.core.wmem_max = 110592 178c148 < net.core.xfrm_larval_drop = 1 --- net.core.xfrm_larval_drop = 0 190d159 < net.ipv4.conf.all.arp_notify = 0 201d169 < net.ipv4.conf.all.proxy_arp_pvlan = 0 206d173 < net.ipv4.conf.all.src_valid_mark = 0 215d181 < net.ipv4.conf.default.arp_notify = 0 226d191 < net.ipv4.conf.default.proxy_arp_pvlan = 0 231d195 < net.ipv4.conf.default.src_valid_mark = 0 240d203 < net.ipv4.conf.eth0.arp_notify = 0 251d213 < net.ipv4.conf.eth0.proxy_arp_pvlan = 0 256d217 < net.ipv4.conf.eth0.src_valid_mark = 0 265d225 < net.ipv4.conf.eth1.arp_notify = 0 276d235 < net.ipv4.conf.eth1.proxy_arp_pvlan = 0 281d239 < net.ipv4.conf.eth1.src_valid_mark = 0 290d247 < net.ipv4.conf.eth2.arp_notify = 0 301d257 < net.ipv4.conf.eth2.proxy_arp_pvlan = 0 306d261 < net.ipv4.conf.eth2.src_valid_mark = 0 310c265 < net.ipv4.conf.lo.accept_source_route = 0 --- net.ipv4.conf.lo.accept_source_route = 1 315d269 < net.ipv4.conf.lo.arp_notify = 0 326,327c280 < net.ipv4.conf.lo.proxy_arp_pvlan = 0 < net.ipv4.conf.lo.rp_filter = 1 --- net.ipv4.conf.lo.rp_filter = 0 331d283 < net.ipv4.conf.lo.src_valid_mark = 0 432d383 < net.ipv4.ping_group_range = 1 0 437d387 < net.ipv4.route.gc_interval = 60 441a392 net.ipv4.route.max_delay = 10 443a395 net.ipv4.route.min_delay = 2 449c401,402 < net.ipv4.rt_cache_rebuild_count = 4 --- net.ipv4.route.rt_cache_rebuild_count = 4 net.ipv4.route.secret_interval = 600 452,453c405 < net.ipv4.tcp_adv_win_scale = 1 < net.ipv4.tcp_allowed_congestion_control = bic reno --- net.ipv4.tcp_adv_win_scale = 2 455d406 < net.ipv4.tcp_available_congestion_control = bic reno 457d407 < net.ipv4.tcp_challenge_ack_limit = 100 459d408 < net.ipv4.tcp_cookie_size = 0 462c411 < net.ipv4.tcp_ecn = 2 --- net.ipv4.tcp_ecn = 0 465,466c414 < net.ipv4.tcp_frto = 2 < net.ipv4.tcp_frto_response = 0 --- net.ipv4.tcp_frto = 0 471,475c419,422 < net.ipv4.tcp_max_orphans = 8192 < net.ipv4.tcp_max_ssthresh = 0 < net.ipv4.tcp_max_syn_backlog = 128 < net.ipv4.tcp_max_tw_buckets = 8192 < net.ipv4.tcp_mem = 12177 16239 24354 --- net.ipv4.tcp_max_orphans = 4096 net.ipv4.tcp_max_syn_backlog = 1024 net.ipv4.tcp_max_tw_buckets = 180000 net.ipv4.tcp_mem = 12288 16384 24576 485c432 < net.ipv4.tcp_rmem = 4096 87380 519648 --- net.ipv4.tcp_rmem = 4096 87380 524288 492,493d438 < net.ipv4.tcp_thin_dupack = 0 < net.ipv4.tcp_thin_linear_timeouts = 0 499c444 < net.ipv4.tcp_wmem = 4096 16384 519648 --- net.ipv4.tcp_wmem = 4096 16384 524288 501c446 < net.ipv4.udp_mem = 12177 16239 24354 --- net.ipv4.udp_mem = 49056 65408 98112 504,517d448 < net.ipv4.xfrm4_gc_thresh = 32768 < net.netfilter.nf_log.0 = NONE < net.netfilter.nf_log.1 = NONE < net.netfilter.nf_log.10 = NONE < net.netfilter.nf_log.11 = NONE < net.netfilter.nf_log.12 = NONE < net.netfilter.nf_log.2 = NONE < net.netfilter.nf_log.3 = NONE < net.netfilter.nf_log.4 = NONE < net.netfilter.nf_log.5 = NONE < net.netfilter.nf_log.6 = NONE < net.netfilter.nf_log.7 = NONE < net.netfilter.nf_log.8 = NONE < net.netfilter.nf_log.9 = NONE 525c456 < vm.dirty_ratio = 20 --- vm.dirty_ratio = 40 528,530c459 < vm.extfrag_threshold = 500 < vm.highmem_is_dirtyable = 0 < vm.hugepages_treat_as_movable = 0 --- vm.flush_mmap_pages = 1 534,536c463,467 < vm.lowmem_reserve_ratio = 256 32 32 < vm.max_map_count = 65530 < vm.min_free_kbytes = 2883 --- vm.lowmem_reserve_ratio = 256 256 32 vm.max_map_count = 65536 vm.max_reclaims_in_progress = 0 vm.max_writeback_pages = 1024 vm.min_free_kbytes = 2896 539,542c470 < vm.nr_overcommit_hugepages = 0 < vm.nr_pdflush_threads = 0 < vm.oom_dump_tasks = 1 < vm.oom_kill_allocating_task = 0 --- vm.nr_pdflush_threads = 2 545a474 vm.pagecache = 100 548,549c477 < vm.scan_unevictable_pages = 0 < vm.stat_interval = 1 --- vm.swap_token_timeout = 300 550a479 vm.topdown_allocate_fast = 0 552a482 vm.vm_devzero_optimized = 1[/code]

, ,
とりあえず付けておく無駄ではなかったなまぁまぁ読めたちょっと役に立ったかなかなり良かったかも (まだ評価されていません)
Loading...

CentOS5.xでdstatの–top-ioオプションを使う

■CentOS5.xでdstatの–top-ioオプションを使う
CentOS5.xで極短時間でもI/O負荷を上げているプロセスを特定する方法としてdstatを使うことでそれが可能です。しかしdstatの–top-ioオプションはketnel2.6.20以上が必要で、CentOS5.x標準のkernel2.6.18では利用できません。そこでCentOS5.xでもそれを利用する方法を調べてみました。

dstat
http://dag.wieers.com/home-made/dstat/dstat.1.html

今回はELrepoというハードウェアリポジトリから3.0系のkernelを導入します。
ELrepoはCentOS/RedHat用のリポジトリで、既存のソフトウェアパッケージ群と整合性があります。kernelアップデートしても既存のソフトウェアが勝手にバージョンアップされることはありません。

[code]# rpm -ivh http://elrepo.org/elrepo-release-5-4.el5.elrepo.noarch.rpm
# vi /etc/yum.repos.d/elrepo.repo

[elrepo-kernel]
name=ELRepo.org Community Enterprise Linux Kernel Repository – el5
baseurl=http://elrepo.org/linux/kernel/el5/$basearch/
mirrorlist=http://elrepo.org/mirrors-elrepo-kernel.el5
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-elrepo.org
protect=0

# yum update
# yum install kernel-lt kernel-lt-devel
[/code]

kernel3.0で起動するとudevの起動時にエラーメッセージが出るので以下を修正。
[code]
# vi /etc/udev/rules.d/05-udev-early.rules
ACTION==”add”, SUBSYSTEM==”scsi”, WAIT_FOR_SYSFS=”ioerr_cnt”
 ↓
#ACTION==”add”, SUBSYSTEM==”scsi”, WAIT_FOR_SYSFS=”ioerr_cnt”

※iscsiが使われていないこと。iscsiを有効のまま使う場合は以下。
ACTION==”add”, SUBSYSTEM==”scsi”, KERNEL==”[0-9]*:[0-9]*”, WAIT_FOR_SYSFS=”ioerr_cnt”

# reboot
[/code]

起動画面で3.0kernel選択、起動後に起動kernelを確認する。
[code]
# uname -r
3.0.66-1.el5.elrepo を確認
[/code]

これでdstatのフル機能が利用できるようになります。
dstatは最新版をインストールします。
[code]
# wget http://dag.wieers.com/home-made/dstat/dstat-0.7.2.tar.bz2
# tar jxvf dstat-0.7.2.tar.bz2
# cd dstat-0.7.2
# ./dstat -alt –top-io –top-bio –top-cpu –top-cputime –top-cputime-avg –top-mem
[/code]

各ディスクやネットワーク単位でトラフィックを取得する場合
[code]# ./dstat -cdnlt -N eth0,eth1,total -D sda1,sda2,sda3,total –top-io –top-bio –top-cpu –top-cputime –top-cputime-avg –top-mem[/code]

ファイルに書く場合は2つ方法があります。

CSV用のカンマ区切り(画面も表示)
[code]# ./dstat -cdnlt -N eth0,eth1,total -D sda1,sda2,sda3,total –top-io –top-bio –top-cpu –top-cputime –top-cputime-avg –top-mem -o filename[/code]

terminal画面の出力をそのまま保存(画面表示無)
[code]# ./dstat -cdnlt -N eth0,eth1,total -D sda1,sda2,sda3,total –top-io –top-bio –top-cpu –top-cputime –top-cputime-avg –top-mem > filename[/code]

これによって1秒ごとにサーバの動作状況とその時に最も活動しているプロセスとその対象をいくつかの指標でログに取得できます。

, ,
とりあえず付けておく無駄ではなかったなまぁまぁ読めたちょっと役に立ったかなかなり良かったかも (まだ評価されていません)
Loading...

■ロジクール Ultimate Ears 350vi レビュー (後)
 fansfans.jpのキャンペーンで「iPhone対応! ロジクール・高音質、遮音性イヤフォン Ultimate Ears モニタープレゼント」に応募したら幸運にもUltimate Ears 350viのモニターに当選することができたので、エージング無し評価の前編に続いてエージング後の後編をお送りしたいと思います。エージングはホワイトノイズで60時間行いました。今回は比較のためスマホ3機種を2週間(通勤時間を含めていろいろなシチュエーションで)使ってみて、各機種毎での使用感を中心に350viの最適な使い方を探ってみた内容を書いていきたいと思います。

1)iPhone4S (iOS6.0.1)
 エージング前と比較してブーミーさが抑えられて低音がややはっきりとして聴きやすくなった印象。イコライザをBass Reducer設定にしなくてもそれなりに聴ける感じ。中域もしっかり出て聴きやすいものの、反面高域がやや伸び切れないというかかなり高い音域がカットされているような印象が強く出てきたように感じてしまいました。尖った部分が削れて丸くなっているような物足りなさです。Bass Reducer設定ではそれが多少緩和されるものの、やはり高域に物足りなさを感じます。女性ボーカルの繊細さはやや控えめな感じですが、声のリアル感はよく出ていて、コーラスなどの聴き分けもエージング前よりもそれなりにはっきりしているので解像感が上がっているようです。低域が締まって中域が向上したことで高域の物足りなさがよりはっきり出てきたという感じでしょうか。
 音楽を聴いている分にはやや高域が物足りない感じが出るのですが、Webラジオなどの低ビットレートの音源を聴くケースではいやなノイズ感が抑えられていて非常に聴きやすく疲れにくいというのが実感できました。元よりヘッドセットという点を考えると通話等の低ビットレートの音声利用時を想定したノイズ対策がされているものと考えていいのかもしれません。個人的にはPodcastやWebラジオは350viでならより積極的に聴きたいと思えるなぁと感じました。

2)Arrows X F-05D (Android 4.0.3)
 こちらもイコライザオフでまずは確認。MicroSDにiPhone4Sと同じ曲を入れてPlayミュージックで再生した評価です。残念ながら他機に比べて軽くやや浮ついた軽い印象の音になっており、必ずしも悪いものではないのですが聴き比べると残念な感じです。350viは単なる低音強調型のヘッドセットかと思っていたのですが、むしろスマホ本体の音質をかなりストレートに表現するタイプのヘッドセットかもしれないと思うようになりました。F-05Dではイコライザでバスブーストや3D効果などの強調が可能なのですが、調整するほどバランスが悪くなる印象で個人的には350viとの相性が非常によくないと感じました。正直F-05Dであまり長く聴いていたくないと思いました。350vi自体はiPhoneシリーズ用と銘打っているので、Androidで利用するために敢えて選ぶ方はいないと思いますが、リモコンも中央ボタンでの再生と一時停止しか利用できず、音量調整もダブルクリック等での曲操作もできないので注意が必要です。

3)HTC Radar (WIndows Phone 7.5)
 こちらにはWinodws Phone 7 Connector改めWindows Phone.appとなった専用転送ツールから曲を転送しています。残念ながらiTunesで購入した曲はDRM無しのデータでも転送してくれないので(同じ曲がAndroidでは再生できているのに…)、自リップ曲のみ転送してのチェックでした。以前のレビューでも書いていますが、HTC Radarは音質がHTCらしいしっかり締まった低音と硬質感のあるキレイな高音が特徴で音楽プレイヤーとしても非常に気に入っているスマホです。今回350viとの組み合わせでは双方の長所がうまく発揮されているようで、3機種中最も好みのバランスの音になりました。350viの特徴としてカットされているような高域部分は改善されることはないのですが、元々の硬い感じの高域がちょうど聴きやすく緩和されるというか耳に優しい感じになり、しっかり低音はしっかりのまま素直に再生されて密度感のあるとてもまとまりのある音楽になります。奥行き感はあまり感じないのですが、横への広がりは解増感の高さも加わって非常にいい感じです。これは音楽用途でオススメできる組み合わせだと思うのですが、ヘッドセットしては中央ボタン長押しの音声入力呼び出し以外一切リモコンが機能しない(何故長押しだけ使えるのか…orz)という残念仕様なので、わざわざこのために買う必要はないと言わざるを得ません…。この辺りの操作性は共通にして欲しいなぁと率直に思いました…。

 ということで、残念ながらヘッドセットとして各種操作を期待する場合にはiPhoneシリーズしか実用にならないことも確認できたので、いろんなデバイスで使いたいガジェットマニアな皆さんにはオススメできないのですが、iPhoneシリーズをお持ちでWebラジオやPodcastを中心に利用される方には、聴き疲れも少なく十分にオススメできるのではないかと思います。むしろWebラジオなどは結構長時間聴き続けることもあると思うので、そういう方には嬉しい製品になるような気がします。後、アニメ動画を見る場合でも聴き疲れが少なくて良かったですね。通勤途中で音楽などを聴き流すような感じで使われる場合にもいいかなと思います。350viを使って感じたのは、自室でじっくり音楽を聴くような用途では微妙でも、耳に負担をかけない音質で通勤や聞き流しに便利な「疲れない音」のバランスを狙っているんだろうなということでした。低音の調整は個人の好みで必要かなと思いますが、「聴き疲れない音」をお探しの方は試してみられてもいいかもしれません。

, ,
とりあえず付けておく無駄ではなかったなまぁまぁ読めたちょっと役に立ったかなかなり良かったかも (まだ評価されていません)
Loading...

■Mac mini late 2012 Core i7 2.6GHzの放熱対策
 サブマシンの代替で購入したMac mini late 2012 Core i7 2.3GHzがメインマシンのiMacより高性能になっていたので、いっそのことと思いメインマシンもMac mini late 2012 Core i7 2.6GHzに交換することにした。一応少しだけクロックアップしたのと、ディスクがやはりネックになるので速度改善のためSeagateのST750LX003に交換してみた(Fusionドライブは高いので…)。メモリはもちろん16Gに換装済み。実際に使い始めてみるとノーマルのMac miniより明らかに発熱が多い。やや発熱多めと言われていたST750LX003のせいだけでなく、ちょっと負荷のかかる処理をするとCPU温度が96度とかとんでもなく上がってしまうので、やむを得ず強制空冷のため以下のパーツを追加購入した。

 AINEX ファン用USB電源変換ケーブル CA-010
 AINEX ケース用14cmファン OMEGA TYPHOON G CFZ-140GL

 ケース用の静音ファンをUSB電源で動かしてMac miniの天板に向けアルミ筐体全体を冷やしてしまおうという方法だ。CFZ-140GLは14cmの大型ファンで回転数が800rpmと少ないことでノイズが非常に少ない(耳を近づけてもほとんど聴こえない)のに、そこそこ風量が実感できるので選択してみた。とりあえず以下のような感じで本体を立て本体内蔵ファンは上方排気をしやすくした上で、壁との間にCFZ-140GLを差し込む感じでファンの風を天板に当てるだけで思った以上に効果が発揮されることがわかった。

IMG_0936IMG_0937

 室温19度のところ、ファン無しの状態では57〜60度前後で安定していたCPU温度がファン設置後は50〜53度程度に下がっており、部屋の温度がある程度低い場合は効果が大きいことが確認できた。自室には自宅サーバが数台稼働しているため基本暖房を入れていない。これでしばらくは十分対策になりそうなので、安定させるための台を工夫することでよしとすることにした。

 Mac miniは前モデルでも発熱が大きかったらしく、ファン追加で放熱対策をされているブログをいくつも見かけたが、実際に90度越えなどを見てしまうとやはりなんとかしなくてはと思ってしまう。Mac miniの放熱対策とノイズ対策に悩んでいる方には上記ファンとケーブルの組み合わせは十分オススメできると思う。しばらく様子を見つつ、エンコード等で高温状態が長く続きそうなケースではファンを追加することも含めて運用の検討をしていきたい。

,
とりあえず付けておく無駄ではなかったなまぁまぁ読めたちょっと役に立ったかなかなり良かったかも (まだ評価されていません)
Loading...

■ロジクール Ultimate Ears 350vi レビュー (前)
 fansfans.jpのキャンペーンで「iPhone対応! ロジクール・高音質、遮音性イヤフォン Ultimate Ears モニタープレゼント」に応募したら幸運にも当選することができたので、早速簡単なレビューを書いておこうと思います。応募する時には一応モニター希望機種を指定でき600viを希望したところ、当選したのは350viでした。350viの特徴は「迫力のある低音重視設計」…むむむ、個人的に低音重視ではなく寧ろ繊細さクリアさとか艶重視なのでちょっとこれはミスマッチだぞと思いつつ、いつものことながらfansfans.jpさんが関与されるイベントでは「商品についての率直なご感想の掲載を」と、ちゃんと感じた通りに書いていいというお墨付きの一文が封入されていたので、ミスマッチ前提で感じた通りに書くことにしますw 今回レビューに敢えて(前)としたのは、開封直後に視聴した音とホワイトノイズでエージングした後の音を比較してみようと思ったからです。数日後に書くつもりの(後)では、エージングでどのような変化があったか比較になるように書ければと思っています。

 ということで今回はキャンペーンの募集要項にもあったようにiPhoneでのモニターが前提となりますので、いつも利用しているiPhone4Sで試してみることにしました。ちなみに日常で最も利用時間の長いヘッドホンはAKG K601で、自宅での音楽はこれをメインで聴いています。次点がこれまでのスマートフォンレビューでも度々登場するVictorのHA-FXC71とHA-FXT90LTDになります。どれも低音も十分に楽しめる製品ですが、高音が繊細でよりキレイに出るところを好んで使っているので、低音寄りの設計とされている350viでの試聴は最初やや不安を伴うものでした。その当りのバイアスがかかっている前提で以下をお読みいただければと思います。

 iPhone4Sのミュージックの設定は通常通り最初はイコライザをオフにしてスタートしました。350viには標準で5サイズのイヤーピースが付いてくるのですが、標準で付いているものが耳にぴったりで圧迫感も強くなかったので、その状態でリスニングを始めることにしました。装着感は良好でコンパクトな本体は耳の一部に当たってしまうようなこともなく非常に快適な感じです。遮音性はそれほど高いとは思いませんでしたが十分かと思います。タッチノイズはやや多めかなと感じましたが、HA-FXC71とはそれほど大きく変わりません。iPhone4Sではリモコンも利用可能で、ボタン操作も細い割にクリック感もほどほどにあり使いやすい印象です。あまり操作に迷うことはありません。通常は音量を上下のボタンで、真ん中のボタンで再生停止ができるようになっています。

 さて、実際に聴いてみた音の最初の印象は「これはブーミー過ぎる」というものでした。iPhone4Sは標準でも他機種と比べ比較的低音が出る方のスマートフォンだと思うのですが、350viとの組み合わせでは静かな室内で試聴した時に、低音ばかりが強調され聴くに堪えないものでした。締まった迫力のある低音ならまだしも、比較的広がり感のあるやや軽い印象の低音で女性ボーカルですらやや太ましく感じるほどに低音がかぶってしまうので、ちょっとこれはひどいと感じるレベルでした。ベースやドラムの音こそ一番に聴きたいという方には最適なのかもしれませんが、音のバランスとしては低音に全体が飲み込まれてしまって高音やボーカルの中音域もすべてスポイルされてしまったように感じました。ただ、解像感は感じることができ複数のボーカルの重なり具合などがVictorのものよりも聴き分けられそうな印象がありました。

 そこでiPhone4Sのミュージック設定からイコライザをBass Reducerにして再度聴いてみたところ、ブーミーだった低音はすっかり鳴りを潜めほどよい感じの低音(ややもの足りないくらい)に収まりました。そしてボーカルもすっきりとし解像感が非常に上がってきて、かなりよいバランスで聴けるようになりました。女性ボーカルやイージーリスリング系ではこちらの設定の方が圧倒的によいと思われました。350viでは音場にあまり奥行き感は感じられないのですが、解像感があることでエフェクトのかかり具合などが比較的よくわかるのと、ボーカルやコーラスのひとりひとりの声や位置の違いはそれなりに感じるので、使っているヘッドホンによってはこうした部分ではっと気付くような発見があって楽しいかもしれないなと思いました。少なくともHA-FXC71よりははっきりと違いを感じられたので素性は良さそうです。

 350viの宣伝的長所を否定するようで申し訳ないのですが、iPhone4Sで350viを利用する場合には音楽をバランス良く聴こうとするならBass Reducerを設定するのがいいのではないかと思いました。他にもイコライザ設定はあるのですが、単純に低音を抑えることが一番ヘッドホンの全体的な良さを引き出せているように感じました。開封直後ということもあり、おそらくまたエージングで音は変化してくると思うので、他のスマートホンも含めた音の比較は後編でお送りしたいと思います。

, ,
とりあえず付けておく無駄ではなかったなまぁまぁ読めたちょっと役に立ったかなかなり良かったかも (1 投票, 平均値/最大値: 4.00 / 5)
Loading...

■AMD FX-8350のベンチマーク
ということでAMDブロガー勉強会でいただいたFX-8350バルクとASUS SABERTOOTH 990FX R2.0を使って早速マシンを組んでみたので、たぶんあまり一般的でない方法でベンチマークをとってみたメモ。マシンの構成はこんな感じ。

■構成パーツ
ケース
CORSAIR Carbideシリーズ CC-9011015-WW(550D) ¥12,300
CPU
AMD FX-8350
CPUクーラー
ENERMAX 冷却 CPUクーラー ETS-T40-TB ¥3,000
マザー
ASUS SABERTOOTH 990FX R2.0
ATX電源
玄人志向 500W 80PLUS Platinum KRPW-PT500W/92+ ¥8,400
メモリー
A-DATA〈XPG Gaming series〉DDR3-1866 AX3U1866GC4G9B-DG2 4Gx2 ¥4,400(合計8G)
SSD
Micron C300 MTFDDAC064MAG-1G1(2.5インチ 64G)手持ち
VGA
PowerColor Go! Green HD6750 1GB GDDR5 手持ち

合計金額 28,100円(新規購入分のみ)

■ベンチマーク手法
SiliconPower製4G USBメモリにUbuntu 12.10をインストールし、ベンチ用にfio・orion・handbrakeを追加する。マシンをUSBメモリから起動し、C300に対してベンチマークを行う。測定結果は5回の平均値。またC300上に800MB程度のtsファイルを用意し、それをhandbrake標準のm4v HighProfile設定でエンコードし平均FPSとエンコード時間を測定する。消費電力はサンワダイレクトのワットメーター付き電源タップ 700-TP1052DWでの結果を参考として記録する。

比較のためCore i5 2500 /ASRock H67M-ITX /CFD Elixir DDR3 SDRAM PC3-10600 4Gx2 /内蔵GPUのマシンを同じ方法でベンチマークした結果も記載する。

■ベンチマーク結果
1)fio
FX-8350 6481 /6432 /6448 /6416 /6448 = 6445 IOPS
i5-2500 7710 /7573 /7701 /7734 /7710 = 7685.2 IOPS

2)orion (-run simple -num_disks 1 結果の5項目)
FX-8350 6133 /11464 /20042 /24311 /27251 = 27251 IOPS
i5-2500 6308 /11693 /16239 /19297 /20896 = 20896 IOPS

3)orion (-run simple -num_disks 4 結果の後5項目)
FX-8350 33179 /33280 /33338 /33376 /33402 = 33402 IOPS
i5-2500 27197 /27438 /27663 /27853 /27956 = 27956 IOPS

4)Handbrake
FX-8350 11分13秒 25.27FPS
i5-2500 14分17秒 20.03FPS

5)消費電力
FX-8350 150-172W(orion) 190-235W(Handbrake)
i5-2500 32-37W(orion) 113-117W(Handbrake)

■まとめ
とりあえず手持ちのCore i5 2500のマシンと比較してみたが、fioの結果がもうひとつ奮わない謎…。データベースの性能を表すorionでは同じSSDのC300に対してクロックが高いアドバンテージがちゃんと出たという感じか。実際の負荷ではどちらも最大で45%程度しか使っていなかったので、マルチコアの性能差までには至っていない感じ。Handbrakeでは存分にCPUを使っていたのでこちらの方がマルチコア差が出ているはずで、3分以上短い時間で終了していることからもエンコードの性能はかなり高いことが実感できる。クロックのベースが高いし物理コアが多いのでデータベースには有利なのではないかと思ったが、それなりの結果になじったのでまぁ良かったのかな。もっとI/O性能の高いSSDを利用すると差がわかりやすく出るような気もする。ただ、各種ベンチマーク記事で見られた通りFX側はGPUがそれなりに電力を食うRADEON 6750が搭載されているとは言え、常用域ではちょっと性能比で割に合わない消費電力量かなと思ってしまう感じ。やはりFX-8350はマルチコアを活かしてガンガン使う環境で利用するかOCして楽しむためのCPUという印象。消費電力は一般用途ではかなり大きな選択基準になると思うので、Intelの有利を覆せるようAMDにはぜひがんばって欲しいと思う。

, , , ,
とりあえず付けておく無駄ではなかったなまぁまぁ読めたちょっと役に立ったかなかなり良かったかも (まだ評価されていません)
Loading...

■AMDブロガー勉強会に参加した
 11月21日に日本AMDオフィスで行われたブロガー勉強会に参加してきたので、勉強会の感想などを書いておきます。FX-8350などのベンチマークなどはこの後の別記事で。ここでは勉強会そのものについて初参加の視点で簡潔にまとめておこうと思います。
FX logo

 このところずっとIntel CPUを使い付けてきた自分が今回AMDの勉強会に応募した動機は極単純で、Core iシリーズが市場で優勢と思われる中メディアのベンチマーク記事を見ても消費電力面などであまり評価が芳しくないと感じられるAMDの最新のプロセッサVisheraでどんな戦略を持っているのか興味を持ったから。勉強会って書いているけどきっと緩いファンイベントみたいな感じかもしれないから期待はできないかもしれないな…などと、AMDブロガー勉強会について不勉強極まるスタンスでの応募でした。これは後で後悔することになりますw

 一応応募はしてみたけれど、このblogは主にソフトウェア面の記事が多く自作ネタもあることはあるけど比率としては著しく低いし、どちらかと言えば低消費電力高CPの自宅サーバを構築する感じの内容なので、ちょっと今回のAMDのターゲットとは違うだろうから、まぁ抽選で落ちるだろうなと考えていました。そして案の定11月19日に落選通知のメールが。やっぱりかーとがっくりしていたところ、20日になってキャンセルが出たための繰り上げ当選のお知らせが!喜び勇んでiPhoneから参加の意思表明をさせていただきました。繰り上げに選んでいただいて感謝です。そこから改めてFX系の発表記事やアーキテキチャ・ベンチマーク関連の記事を読みまくり(PCwatchやASCIIがとっても参考になりました これとかことか)一夜漬けのテスト勉強の様相で当日を迎えました。

 会場は東京駅のほど近く、新しい綺麗なビルで会場もとってもいい感じでした。勉強会開始ギリギリでの到着だったので、既に大勢の方が入られていて賑わった状況でした。テーブルにはお弁当と飲み物、そしてお土産のマザボとCPUの入った大きな袋が置いてありました。前の方にも空き席はありましたが初心者なので会場の後ろ側に席を取り勉強会の最中はおとなしくしていましたw(というか質問のレベルが高くて発言できるような余地がなかったw)

 勉強会の写真は撮影していないのでざっくりと内容だけ説明すると、始めに日本AMDの稲川さんからのご挨拶があり、今回が4回目のブロガー勉強会であること、AMDの現在のシェア、今回の勉強会などを通じてVishera登場直後の様に盛り上げをしていきたいことなどのお話をされました。AMDのシェアはTrinityの前で9〜10%前後だったところ、TrinityやVishera登場直後は一時的に販売で35%もの数字が上がったこともあるそうで、ボーナス商戦を前にそうした盛り上げを再度期待したいということなのだと理解しました。通常であれば広告を打ち値引きをするのがわかりやすい販売戦略なのでしょうが、日本AMDがブロガーのパワーを信じてこうした企画を実施するのは、広告やメディアの記事などでは伝わらないハードウェアスペック以外の重要な情報=AMDファンの気持ちや実体験を伝えることが重要であると位置づけていることの現れなのだと思いました。

 その後Visheraの概要説明・アピールポイント・比較などの説明があり、更にエンジニアの方によるアーキテクチャの改良点の詳細な解説、ASUSの方による製品の説明へと続きます。Visheraの概要説明では公式ではなかなか出ないIntelとの比較がブロガー勉強会だからと出してもらえたり(ベンチ比較とかもありました)、アーキテクチャの解説においてはPCwatchの後藤弘茂さんの記事を読んでいるかのような詳細な説明と質疑応答(会場参加者には常連さんも多いようで説明されているエンジニアの方とレベルの高い内容を当り前のようにやりとりされていました。勉強会の名に恥じないすごい内容だなと本当に感心しました。メモもとったのですがちゃんと理解できていないので、これを記事に書く勇気はありませんw)がされていました。ASUSの製品説明は営業サイドの方のようでお話もうまく、技術者ではないと前置きされながらも製品技術についてもしっかり把握されていたので、ASUSのファンをガッツリと増やしていましたw 私自身はもとよりASUSのファンでマザボはまずASUSから選択肢を探す方ですが、改めてASUSの製品はいいなぁと感じるくらい魅力的なお話をされる方でした。個人的にはASUSの日本での知名度も上がってきているので、グローバルな製品保証体制のため代理店モデルから直販モデルへとそろそろ移行して欲しいなと思っています。がんばってほしいですw 最後にゲーム関連でイベントのためにPCを良く持ち運ぶという事例での面白いお話をされた方がいらしたのですが、イベント終了までに出されたお弁当を食べてしまわなければと焦っていたので、ちゃんとメモしていませんでした。ごめんなさい。

 ということで枕が長い割に、イベント内容は薄いという記事になってしまいましたがw、勉強会を通じて面白かったキーワードを最後に並べておきたいと思います。勉強会自体は非常にレベルが高く技術者の方とも直接お話できる希有な機会だったので、個人的には昔PowerPCを追いかけていた頃のようにちゃんと勉強して臨めばもっと得られるものは多かっただろうと思うと、もったいないことをしてしまったと感じます。イベント後談笑する企画側の方々を見て、こうした機会を設けてくれる日本AMDはいい会社なんだなと思いました。AMD製品ではCPUよりもGPUの方がファン度が高い(RADEON主義者なのでw)ので、ぜひまたそうした機会があれば応募したいと思いました。

■面白かったキーワード
・FXだけにハイリスクハイリターン
・パイルドライバーはプロレス技だけじゃなく杭打ち機
・社内ではK10と言わずグレイハウンド
・ASUSのOC向けマザーなのに初心者向けAUTO設定機能(対応メモリ挿すと設定自動で変わるとか)
・ブロガー向け勉強会を先にやると叩かれない(えw
・ASUSはTCOを推進しています
・12/8に秋葉原
・OC世界一を目指す!(翌日記録が報道されました!)

, ,
とりあえず付けておく無駄ではなかったなまぁまぁ読めたちょっと役に立ったかなかなり良かったかも (まだ評価されていません)
Loading...