Searched hist:230099 (Results 1 - 25 of 66) sorted by relevance

123

/freebsd-10.0-release/etc/rc.d/
H A D	netwait	diff 230099 Sat Jan 14 00:33:17 MST 2012 dougb Prepare for the removal of set_rcvar() by changing the rcvar= assignments to the literal values it would have returned. The concept of set_rcvar() was nice in theory, but the forks it creates are a drag on the startup process, which is especially noticeable on slower systems, such as embedded ones. During the discussion on freebsd-rc@ a preference was expressed for using ${name}_enable instead of the literal values. However the code portability concept doesn't really apply since there are so many other places where the literal name has to be searched for and replaced. Also, using the literal value is also a tiny bit faster than dereferencing the variables, and every little bit helps.
H A D	nfscbd	diff 230099 Sat Jan 14 00:33:17 MST 2012 dougb Prepare for the removal of set_rcvar() by changing the rcvar= assignments to the literal values it would have returned. The concept of set_rcvar() was nice in theory, but the forks it creates are a drag on the startup process, which is especially noticeable on slower systems, such as embedded ones. During the discussion on freebsd-rc@ a preference was expressed for using ${name}_enable instead of the literal values. However the code portability concept doesn't really apply since there are so many other places where the literal name has to be searched for and replaced. Also, using the literal value is also a tiny bit faster than dereferencing the variables, and every little bit helps.
H A D	nfsuserd	diff 230099 Sat Jan 14 00:33:17 MST 2012 dougb Prepare for the removal of set_rcvar() by changing the rcvar= assignments to the literal values it would have returned. The concept of set_rcvar() was nice in theory, but the forks it creates are a drag on the startup process, which is especially noticeable on slower systems, such as embedded ones. During the discussion on freebsd-rc@ a preference was expressed for using ${name}_enable instead of the literal values. However the code portability concept doesn't really apply since there are so many other places where the literal name has to be searched for and replaced. Also, using the literal value is also a tiny bit faster than dereferencing the variables, and every little bit helps.
H A D	rfcomm_pppd_server	diff 230099 Sat Jan 14 00:33:17 MST 2012 dougb Prepare for the removal of set_rcvar() by changing the rcvar= assignments to the literal values it would have returned. The concept of set_rcvar() was nice in theory, but the forks it creates are a drag on the startup process, which is especially noticeable on slower systems, such as embedded ones. During the discussion on freebsd-rc@ a preference was expressed for using ${name}_enable instead of the literal values. However the code portability concept doesn't really apply since there are so many other places where the literal name has to be searched for and replaced. Also, using the literal value is also a tiny bit faster than dereferencing the variables, and every little bit helps.
H A D	rtsold	diff 230099 Sat Jan 14 00:33:17 MST 2012 dougb Prepare for the removal of set_rcvar() by changing the rcvar= assignments to the literal values it would have returned. The concept of set_rcvar() was nice in theory, but the forks it creates are a drag on the startup process, which is especially noticeable on slower systems, such as embedded ones. During the discussion on freebsd-rc@ a preference was expressed for using ${name}_enable instead of the literal values. However the code portability concept doesn't really apply since there are so many other places where the literal name has to be searched for and replaced. Also, using the literal value is also a tiny bit faster than dereferencing the variables, and every little bit helps.
H A D	ubthidhci	diff 230099 Sat Jan 14 00:33:17 MST 2012 dougb Prepare for the removal of set_rcvar() by changing the rcvar= assignments to the literal values it would have returned. The concept of set_rcvar() was nice in theory, but the forks it creates are a drag on the startup process, which is especially noticeable on slower systems, such as embedded ones. During the discussion on freebsd-rc@ a preference was expressed for using ${name}_enable instead of the literal values. However the code portability concept doesn't really apply since there are so many other places where the literal name has to be searched for and replaced. Also, using the literal value is also a tiny bit faster than dereferencing the variables, and every little bit helps.
H A D	bsnmpd	diff 230099 Sat Jan 14 00:33:17 MST 2012 dougb Prepare for the removal of set_rcvar() by changing the rcvar= assignments to the literal values it would have returned. The concept of set_rcvar() was nice in theory, but the forks it creates are a drag on the startup process, which is especially noticeable on slower systems, such as embedded ones. During the discussion on freebsd-rc@ a preference was expressed for using ${name}_enable instead of the literal values. However the code portability concept doesn't really apply since there are so many other places where the literal name has to be searched for and replaced. Also, using the literal value is also a tiny bit faster than dereferencing the variables, and every little bit helps.
H A D	bthidd	diff 230099 Sat Jan 14 00:33:17 MST 2012 dougb Prepare for the removal of set_rcvar() by changing the rcvar= assignments to the literal values it would have returned. The concept of set_rcvar() was nice in theory, but the forks it creates are a drag on the startup process, which is especially noticeable on slower systems, such as embedded ones. During the discussion on freebsd-rc@ a preference was expressed for using ${name}_enable instead of the literal values. However the code portability concept doesn't really apply since there are so many other places where the literal name has to be searched for and replaced. Also, using the literal value is also a tiny bit faster than dereferencing the variables, and every little bit helps.
H A D	ftp-proxy	diff 230099 Sat Jan 14 00:33:17 MST 2012 dougb Prepare for the removal of set_rcvar() by changing the rcvar= assignments to the literal values it would have returned. The concept of set_rcvar() was nice in theory, but the forks it creates are a drag on the startup process, which is especially noticeable on slower systems, such as embedded ones. During the discussion on freebsd-rc@ a preference was expressed for using ${name}_enable instead of the literal values. However the code portability concept doesn't really apply since there are so many other places where the literal name has to be searched for and replaced. Also, using the literal value is also a tiny bit faster than dereferencing the variables, and every little bit helps.
H A D	gptboot	diff 230099 Sat Jan 14 00:33:17 MST 2012 dougb Prepare for the removal of set_rcvar() by changing the rcvar= assignments to the literal values it would have returned. The concept of set_rcvar() was nice in theory, but the forks it creates are a drag on the startup process, which is especially noticeable on slower systems, such as embedded ones. During the discussion on freebsd-rc@ a preference was expressed for using ${name}_enable instead of the literal values. However the code portability concept doesn't really apply since there are so many other places where the literal name has to be searched for and replaced. Also, using the literal value is also a tiny bit faster than dereferencing the variables, and every little bit helps.
H A D	hostapd	diff 230099 Sat Jan 14 00:33:17 MST 2012 dougb Prepare for the removal of set_rcvar() by changing the rcvar= assignments to the literal values it would have returned. The concept of set_rcvar() was nice in theory, but the forks it creates are a drag on the startup process, which is especially noticeable on slower systems, such as embedded ones. During the discussion on freebsd-rc@ a preference was expressed for using ${name}_enable instead of the literal values. However the code portability concept doesn't really apply since there are so many other places where the literal name has to be searched for and replaced. Also, using the literal value is also a tiny bit faster than dereferencing the variables, and every little bit helps.
H A D	ipxrouted	diff 230099 Sat Jan 14 00:33:17 MST 2012 dougb Prepare for the removal of set_rcvar() by changing the rcvar= assignments to the literal values it would have returned. The concept of set_rcvar() was nice in theory, but the forks it creates are a drag on the startup process, which is especially noticeable on slower systems, such as embedded ones. During the discussion on freebsd-rc@ a preference was expressed for using ${name}_enable instead of the literal values. However the code portability concept doesn't really apply since there are so many other places where the literal name has to be searched for and replaced. Also, using the literal value is also a tiny bit faster than dereferencing the variables, and every little bit helps.
H A D	natd	diff 230099 Sat Jan 14 00:33:17 MST 2012 dougb Prepare for the removal of set_rcvar() by changing the rcvar= assignments to the literal values it would have returned. The concept of set_rcvar() was nice in theory, but the forks it creates are a drag on the startup process, which is especially noticeable on slower systems, such as embedded ones. During the discussion on freebsd-rc@ a preference was expressed for using ${name}_enable instead of the literal values. However the code portability concept doesn't really apply since there are so many other places where the literal name has to be searched for and replaced. Also, using the literal value is also a tiny bit faster than dereferencing the variables, and every little bit helps.
H A D	pppoed	diff 230099 Sat Jan 14 00:33:17 MST 2012 dougb Prepare for the removal of set_rcvar() by changing the rcvar= assignments to the literal values it would have returned. The concept of set_rcvar() was nice in theory, but the forks it creates are a drag on the startup process, which is especially noticeable on slower systems, such as embedded ones. During the discussion on freebsd-rc@ a preference was expressed for using ${name}_enable instead of the literal values. However the code portability concept doesn't really apply since there are so many other places where the literal name has to be searched for and replaced. Also, using the literal value is also a tiny bit faster than dereferencing the variables, and every little bit helps.
H A D	apm	diff 230099 Sat Jan 14 00:33:17 MST 2012 dougb Prepare for the removal of set_rcvar() by changing the rcvar= assignments to the literal values it would have returned. The concept of set_rcvar() was nice in theory, but the forks it creates are a drag on the startup process, which is especially noticeable on slower systems, such as embedded ones. During the discussion on freebsd-rc@ a preference was expressed for using ${name}_enable instead of the literal values. However the code portability concept doesn't really apply since there are so many other places where the literal name has to be searched for and replaced. Also, using the literal value is also a tiny bit faster than dereferencing the variables, and every little bit helps.
H A D	ddb	diff 230099 Sat Jan 14 00:33:17 MST 2012 dougb Prepare for the removal of set_rcvar() by changing the rcvar= assignments to the literal values it would have returned. The concept of set_rcvar() was nice in theory, but the forks it creates are a drag on the startup process, which is especially noticeable on slower systems, such as embedded ones. During the discussion on freebsd-rc@ a preference was expressed for using ${name}_enable instead of the literal values. However the code portability concept doesn't really apply since there are so many other places where the literal name has to be searched for and replaced. Also, using the literal value is also a tiny bit faster than dereferencing the variables, and every little bit helps.
H A D	dmesg	diff 230099 Sat Jan 14 00:33:17 MST 2012 dougb Prepare for the removal of set_rcvar() by changing the rcvar= assignments to the literal values it would have returned. The concept of set_rcvar() was nice in theory, but the forks it creates are a drag on the startup process, which is especially noticeable on slower systems, such as embedded ones. During the discussion on freebsd-rc@ a preference was expressed for using ${name}_enable instead of the literal values. However the code portability concept doesn't really apply since there are so many other places where the literal name has to be searched for and replaced. Also, using the literal value is also a tiny bit faster than dereferencing the variables, and every little bit helps.
H A D	ftpd	diff 230099 Sat Jan 14 00:33:17 MST 2012 dougb Prepare for the removal of set_rcvar() by changing the rcvar= assignments to the literal values it would have returned. The concept of set_rcvar() was nice in theory, but the forks it creates are a drag on the startup process, which is especially noticeable on slower systems, such as embedded ones. During the discussion on freebsd-rc@ a preference was expressed for using ${name}_enable instead of the literal values. However the code portability concept doesn't really apply since there are so many other places where the literal name has to be searched for and replaced. Also, using the literal value is also a tiny bit faster than dereferencing the variables, and every little bit helps.
H A D	hastd	diff 230099 Sat Jan 14 00:33:17 MST 2012 dougb Prepare for the removal of set_rcvar() by changing the rcvar= assignments to the literal values it would have returned. The concept of set_rcvar() was nice in theory, but the forks it creates are a drag on the startup process, which is especially noticeable on slower systems, such as embedded ones. During the discussion on freebsd-rc@ a preference was expressed for using ${name}_enable instead of the literal values. However the code portability concept doesn't really apply since there are so many other places where the literal name has to be searched for and replaced. Also, using the literal value is also a tiny bit faster than dereferencing the variables, and every little bit helps.
H A D	inetd	diff 230099 Sat Jan 14 00:33:17 MST 2012 dougb Prepare for the removal of set_rcvar() by changing the rcvar= assignments to the literal values it would have returned. The concept of set_rcvar() was nice in theory, but the forks it creates are a drag on the startup process, which is especially noticeable on slower systems, such as embedded ones. During the discussion on freebsd-rc@ a preference was expressed for using ${name}_enable instead of the literal values. However the code portability concept doesn't really apply since there are so many other places where the literal name has to be searched for and replaced. Also, using the literal value is also a tiny bit faster than dereferencing the variables, and every little bit helps.
H A D	mroute6d	diff 230099 Sat Jan 14 00:33:17 MST 2012 dougb Prepare for the removal of set_rcvar() by changing the rcvar= assignments to the literal values it would have returned. The concept of set_rcvar() was nice in theory, but the forks it creates are a drag on the startup process, which is especially noticeable on slower systems, such as embedded ones. During the discussion on freebsd-rc@ a preference was expressed for using ${name}_enable instead of the literal values. However the code portability concept doesn't really apply since there are so many other places where the literal name has to be searched for and replaced. Also, using the literal value is also a tiny bit faster than dereferencing the variables, and every little bit helps.
H A D	nscd	diff 230099 Sat Jan 14 00:33:17 MST 2012 dougb Prepare for the removal of set_rcvar() by changing the rcvar= assignments to the literal values it would have returned. The concept of set_rcvar() was nice in theory, but the forks it creates are a drag on the startup process, which is especially noticeable on slower systems, such as embedded ones. During the discussion on freebsd-rc@ a preference was expressed for using ${name}_enable instead of the literal values. However the code portability concept doesn't really apply since there are so many other places where the literal name has to be searched for and replaced. Also, using the literal value is also a tiny bit faster than dereferencing the variables, and every little bit helps.
H A D	powerd	diff 230099 Sat Jan 14 00:33:17 MST 2012 dougb Prepare for the removal of set_rcvar() by changing the rcvar= assignments to the literal values it would have returned. The concept of set_rcvar() was nice in theory, but the forks it creates are a drag on the startup process, which is especially noticeable on slower systems, such as embedded ones. During the discussion on freebsd-rc@ a preference was expressed for using ${name}_enable instead of the literal values. However the code portability concept doesn't really apply since there are so many other places where the literal name has to be searched for and replaced. Also, using the literal value is also a tiny bit faster than dereferencing the variables, and every little bit helps.
H A D	rwho	diff 230099 Sat Jan 14 00:33:17 MST 2012 dougb Prepare for the removal of set_rcvar() by changing the rcvar= assignments to the literal values it would have returned. The concept of set_rcvar() was nice in theory, but the forks it creates are a drag on the startup process, which is especially noticeable on slower systems, such as embedded ones. During the discussion on freebsd-rc@ a preference was expressed for using ${name}_enable instead of the literal values. However the code portability concept doesn't really apply since there are so many other places where the literal name has to be searched for and replaced. Also, using the literal value is also a tiny bit faster than dereferencing the variables, and every little bit helps.
H A D	timed	diff 230099 Sat Jan 14 00:33:17 MST 2012 dougb Prepare for the removal of set_rcvar() by changing the rcvar= assignments to the literal values it would have returned. The concept of set_rcvar() was nice in theory, but the forks it creates are a drag on the startup process, which is especially noticeable on slower systems, such as embedded ones. During the discussion on freebsd-rc@ a preference was expressed for using ${name}_enable instead of the literal values. However the code portability concept doesn't really apply since there are so many other places where the literal name has to be searched for and replaced. Also, using the literal value is also a tiny bit faster than dereferencing the variables, and every little bit helps.

Completed in 265 milliseconds

123

Indexes created Wed May 22 12:01:17 MDT 2024