latex이 아닌 OS X 환경에서 문서작업시 footnote symbol 입력을 고민할때가 종종 있음
3종류의 footnote symbol : *, †, ‡
특히 dagger 는 "Option + t"
double dagger 는 "Option + Shift + 7"
WRITTEN BY
- RootFriend
개인적으로... 나쁜 기억력에 도움되라고 만들게되었습니다.
latex이 아닌 OS X 환경에서 문서작업시 footnote symbol 입력을 고민할때가 종종 있음
3종류의 footnote symbol : *, †, ‡
특히 dagger 는 "Option + t"
double dagger 는 "Option + Shift + 7"
$ diskutil list
(assuming /dev/disk2 is the USB device)
$ diskutil unmount XXX(mounted USB directory)
$ sudo dd if=./kali-linux-yyy.iso of=/dev/disk2 bs=512k
가끔씩, mission control이 먹통이되서, shortcut 이 안먹힐때가 있음.
Finder crashed ==> killall -KILL Finder
Dock crashed ==> killall -KILL Dock
OSX 10.6.7 loading expose & spaces ... (7) | 2011.05.20 |
---|---|
Mac OSX 에서 terminal 로 파인더 띄우기 (0) | 2011.04.10 |
출처 : https://discussions.apple.com/thread/4026330?tstart=0
defaults write com.apple.mail DisableInlineAttachmentViewing -bool yes
Open: Applications>Utilities>Terminal and type (without the inverted commas):
"defaults write com.apple.mail DisableInlineAttachmentViewing -bool yes"
That will make every attachment you send act like an attachment instead of a pretty unusable decoration.
If you decide this isn’t what you’re looking for, to restore inline attachment viewing type (again, without the inverted commas):
"defaults write com.apple.mail DisableInlineAttachmentViewing -bool false"
Restart Mail and you’re back to normal.
출처 : http://benlimmer.com/2013/11/06/os-x-mavericks-arp-issue/
Maverick (10.9.x) 부터 인터넷연결이 잘안된다.
router 와 OS 사이의 문제같다.
At ReadyTalk, we recently uncovered an interesting issue related to how OS X Maverickshandles caching ARP responses.
On our corporate network, we have a floating Virtual IP Address to load balance the traffic on our subnets. In previous versions of OS X, if the OS couldn’t reach out and find the specified host, it would immediately send an ARP Request to find the machine and complete the request.
However, in Mavericks, we saw an issue where we would get a pattern of packet loss when pinging or SSHing to or from a Mavericks machine. It looked something like this:
ping blimmer
PING blimmer (192.168.x.x): 56 data bytes
64 bytes from 192.168.x.x: icmp_seq=0 ttl=62 time=87.337 ms
64 bytes from 192.168.x.x: icmp_seq=1 ttl=62 time=86.973 ms
64 bytes from 192.168.x.x: icmp_seq=2 ttl=62 time=86.651 ms
64 bytes from 192.168.x.x: icmp_seq=3 ttl=62 time=86.147 ms
64 bytes from 192.168.x.x: icmp_seq=4 ttl=62 time=86.103 ms
64 bytes from 192.168.x.x: icmp_seq=5 ttl=62 time=86.553 ms
64 bytes from 192.168.x.x: icmp_seq=15 ttl=62 time=89.345 ms
64 bytes from 192.168.x.x: icmp_seq=16 ttl=62 time=88.399 ms
64 bytes from 192.168.x.x: icmp_seq=17 ttl=62 time=88.005 ms
64 bytes from 192.168.x.x: icmp_seq=18 ttl=62 time=88.078 ms
64 bytes from 192.168.x.x: icmp_seq=19 ttl=62 time=86.651 ms
64 bytes from 192.168.x.x: icmp_seq=20 ttl=62 time=196.765 ms
64 bytes from 192.168.x.x: icmp_seq=21 ttl=62 time=87.073 ms
64 bytes from 192.168.x.x: icmp_seq=22 ttl=62 time=87.097 ms
64 bytes from 192.168.x.x: icmp_seq=23 ttl=62 time=87.913 ms
Request timeout for icmp_seq 16
Request timeout for icmp_seq 17
Request timeout for icmp_seq 18
Request timeout for icmp_seq 19
Request timeout for icmp_seq 20
64 bytes from 192.168.x.x: icmp_seq=21 ttl=62 time=87.073 ms
64 bytes from 192.168.x.x: icmp_seq=22 ttl=62 time=87.097 ms
64 bytes from 192.168.x.x: icmp_seq=23 ttl=62 time=87.913 ms
Notice the the packet loss. This was incredibly unfortunate when we would SSH to our machines and have to wait while the packets were retransmitted (causing at least a five second delay in transmission).
After some digging, we disocovered that other folks were having this issue, especially within corporate networks. We stumbled upon this Apple Support Forum post and discovered the fix.
Essentially, you need to tell OS X that it should reach out as soon as it couldn’t discover the host anymore. Poster Lunaweb graciously provided a workaround by setting a kernal parameter, specifically net.link.ether.inet.arp_unicast_lim=0
The folks over at MacMiniVault provided a script that fixes the issue by writing out an/etc/sysctl.conf
file, which sets the kernal parameter on startup. Since we are confident that Apple will provide a fix in a coming update, we wanted a way to set this variable that did not survive a reboot.
So, I wrote a shell script that does just that. It sets the kernal parameter, but it does not survive a reboot.
For what it’s worth, Cisco has provided a fix for AnyConnect for Mac which also resolves the issue.
Hopefully the script written by myself (or MacMiniVault) helps other early adopters resolve obnoxious latency issues caused by Mavericks!
If you use:
sudo scutil --set HostName name-you-want
it will work a bit better. From the scutil(8) man page:
--get pref Retrieves the specified preference. The current value will be reported on standard output. Supported preferences include: ComputerName The user-friendly name for the system. LocalHostName The local (Bonjour) host name. HostName The name associated with hostname(1) and gethostname(3). --set pref [newval] Updates the specified preference with the new value. If the new value is not specified on the command line then it will be read from standard input. Supported preferences include: ComputerName LocalHostName HostName The --set option requires super-user access.
You can define that you want to keep the connection alive in the ssh configuration. You have to edit (create if it does not exist):
~/.ssh/config
Add these two lines to it:
ServerAliveInterval 300
ServerAliveCountMax 36
The value ServerAliveInterval
defines the interval in seconds between two noop operations that keeps to connection alive. It is 5 minutes in this case.
The value ServerAliveCountMax
defines the number of times the noop is sent. In this case the connection will be kept open for 3 hours.
No, you're not the only one, there are several threads here and in the 10.7 forum.
What usually works for HP is to delete the /Library/Printers/hp folder and reinstall the drivers from the link above.