# Intel HD4000 Support



## zspider (Nov 8, 2012)

Hello, 

Just wondering, does FreeBSD 9.1 support the Ivy Bridge HD4000? I'm having issues with it. It tells me "No Screens Found". Is the HD4000 just not supported or did I miss something? I put the appropriate lines into /etc/make.conf, compiled Xorg, installed the most recent Intel driver from ports, and even recompiled the kernel, but no dice.

Any help would be greatly appreciated.


----------



## Beastie (Nov 8, 2012)

It's supposed to work. But how are you testing it? 9.1 hasn't been released yet. Only the STABLE branch should support it right now.


----------



## SirDice (Nov 8, 2012)

Beastie said:
			
		

> But how are you testing it? 9.1 hasn't been released yet.


No, but there are release candidates.

http://www.freebsd.org/where.html#helptest


----------



## zspider (Nov 8, 2012)

I'm trying to get it working with 9.1 RC3. If it's not to be ready until RELEASE, then I can certainly wait.


----------



## SirDice (Nov 8, 2012)

You are encouraged to try the release candidate. Not entirely sure HD4000 is supported yet but there sure is work being done in this area.

http://wiki.freebsd.org/Intel_GPU (Talks mostly about -CURRENT but, if I'm not mistaken, large parts of it have already been merged with 9.1)


----------



## G_Nerc (Nov 8, 2012)

Good day!
I have HD4000 and it well works on FreeBSD-CURRENT amd64


----------



## zspider (Nov 8, 2012)

G_Nerc said:
			
		

> Good day!
> I have HD4000 and it well works on FreeBSD-CURRENT amd64



I assume that's 10 CURRENT? Good to know it works somewhere down the pipe. Kinda hoping it will work with 9.1 RELEASE too.


----------



## dohmniq (Nov 9, 2012)

There is this advice from the freebsd-x11 mailing list:



> To get a more resent xorg distribution than the default in ports, please
> add WITH_NEW_XORG to /etc/make.conf. That should give you support for
> more recent intel graphics cards.  You can also get the experimental
> xorg repo using svn, see http://wiki.freebsd.org/Xorg for details.  The
> ...



(Taken from http://lists.freebsd.org/pipermail/freebsd-x11/2012-October/012517.html)

As totally unsupported help, I can offer you the attached tar file which configures ports that work for me (also HD 4000).

Unpack tar into /usr/ports.

Don't forget to add this to your /etc/make.conf:


```
WITH_NEW_XORG="YES"
WITH_KMS="YES"
```

Rebuild order is (I think):


graphics/libdrm
graphics/libGL
graphics/libGLU
graphics/dri
x11-drivers/xf86-video-intel

Doesn't seem like I needed to rebuild x11-servers/xorg-server after all?
(Still on version 1.10.6)

Included in my /etc/X11/xorg.conf I have:


```
Section "ServerFlags"
        Option          "DRI2"          "True"
        Option          "AIGLX"         "True"
EndSection
```

and in the "Device" section there is also:


```
Option      "AccelMethod" "sna"
```

Dom


----------



## zspider (Nov 9, 2012)

dohmniq said:
			
		

> There is this advice from the freebsd-x11 mailing list:
> 
> 
> 
> ...



Thanks, although it did not work. It still refuses to run X, with the messages:



```
X.Org X Server 1.10.6
Release Date: 2012-02-10
X Protocol Version 11, Revision 0
Build Operating System: FreeBSD 9.1-RC3 amd64 
Current Operating System: FreeBSD ShankRiver 9.1-RC3 FreeBSD 9.1-RC3 #0: Wed Nov  7 18:35:10 EST 2012     root@ShankRiver:/usr/obj/usr/src/sys/SHANKRIVER amd64
Build Date: 08 November 2012  01:34:56AM
 
Current version of pixman: 0.24.2
        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
        (++) from command line, (!!) notice, (II) informational,
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Fri Nov  9 16:21:46 2012
(==) Using default built-in configuration (21 lines)
(EE) Failed to load module "fbdev" (module does not exist, 0)
(EE) No devices detected.

Fatal server error:
no screens found

Please consult the The X.Org Foundation support 
         at http://wiki.x.org
 for help. 
Please also check the log file at "/var/log/Xorg.0.log" for additional information.

xinit: giving up
xinit: unable to connect to X server: Connection refused
xinit: server error
```


----------



## dohmniq (Nov 10, 2012)

This line in your output:



> ```
> (==) Using default built-in configuration (21 lines)
> ```



Suggests that your /etc/X11/xorg.conf file isn't being read. Whereas my /var/log/Xorg.0.log says:


```
[    36.933] (==) Using config file: "/etc/X11/xorg.conf"
```

My /etc/X11/xorg.conf reads:
(Quite a lot was auto-generated by PCBSD)


```
Section "ServerLayout"
        Identifier     "X.org Configured"
        Screen      0  "Screen0" 0 0
        InputDevice    "Mouse0" "CorePointer"
        InputDevice    "Keyboard0" "CoreKeyboard"
        Option          "AutoAddDevices" "false"
        Option          "AutoEnableDevices" "false"
EndSection

Section "Files"
        ModulePath   "/usr/local/lib/xorg/modules"
        FontPath     "/usr/local/lib/X11/fonts/misc/"
        FontPath     "/usr/local/lib/X11/fonts/TTF/"
        FontPath     "/usr/local/lib/X11/fonts/OTF/"
        FontPath     "/usr/local/lib/X11/fonts/Type1/"
        FontPath     "/usr/local/lib/X11/fonts/100dpi/"
        FontPath     "/usr/local/lib/X11/fonts/75dpi/"
EndSection

Section "Module"
        Load  "dbe"
        Load  "dri"
        Load  "dri2"
        Load  "extmod"
        Load  "record"
        Load  "glx"
EndSection

Section "InputDevice"
        Identifier  "Keyboard0"
        Driver      "kbd"
EndSection

Section "InputDevice"
        Identifier  "Mouse0"
        Driver      "mouse"
        Option      "Protocol" "auto"
        Option      "Device" "/dev/sysmouse"
        Option      "ZAxisMapping" "4 5 6 7"
EndSection

Section "Monitor"
        Identifier   "Monitor0"
EndSection

Section "ServerFlags"
        Option          "DRI2"          "True"
        Option          "AIGLX"         "True"
EndSection

Section "Device"
        ### Available Driver options are:-
        ### Values: <i>: integer, <f>: float, <bool>: "True"/"False",
        ### <string>: "String", <freq>: "<f> Hz/kHz/MHz",
        ### <percent>: "<f>%"
        ### [arg]: arg optional
        #Option     "DRI"                       # [<bool>]
        #Option     "ColorKey"                  # <i>
        #Option     "VideoKey"                  # <i>
        Option     "FallbackDebug"      "True"  # [<bool>]
        #Option     "Tiling"                    # [<bool>]
        #Option     "LinearFramebuffer"         # [<bool>]
        #Option     "Shadow"                    # [<bool>]
        #Option     "SwapbuffersWait"           # [<bool>]
        #Option     "TripleBuffer"              # [<bool>]
        #Option     "XvPreferOverlay"           # [<bool>]
        #Option     "DebugFlushBatches" "True"  # [<bool>]
        #Option     "DebugFlushCaches"  "True"  # [<bool>]
        #Option     "DebugWait" "True"          # [<bool>]
        #Option     "HotPlug"                   # [<bool>]
        #Option     "RelaxedFencing"            # [<bool>]
        Option      "AccelMethod" "sna"
        Identifier  "Card0"
        Driver      "intel"
        BusID       "PCI:0:2:0"              # YOU WILL HAVE TO CHECK THIS!
EndSection

Section "Screen"
        Identifier "Screen0"
        Device     "Card0"
        Monitor    "Monitor0"
        SubSection "Display"
                Depth     32
        EndSubSection
EndSection
```

Note the comment "YOU WILL HAVE TO CHECK THIS!" as your Intel HD 4000 may be at a different PCI address to mine.

To check, run `# pciconf -lv` and you should see an entry like this:


```
vgapci1@pci0:0:2:0:     class=0x030000 card=0x05721028 chip=0x01668086 rev=0x09 hdr=0x00
    vendor     = 'Intel Corporation'
    class      = display
    subclass   = VGA
```

From which you can set the BusID. I think mine is actually wrong by virtue of being the old Xorg BusID addressing style but it still works. 

I've attached a sample Xorg.0.log (bzip2 compressed) for you to compare against.


----------



## zspider (Nov 10, 2012)

dohmniq said:
			
		

> This line in your output:
> 
> 
> 
> ...





```
This is what my pciconf -lv says about my intel video.

vgapci1@pci0:0:2:0:     class=0x030000 card=0x14571043 chip=0x01668086 rev=0x09 
hdr=0x00
    vendor     = 'Intel Corporation'
    class      = display
    subclass   = VGA

All of the information is the same except the card field.:\
```

I get different results if I put the xorg.conf in the proper folder. It will specify vesa and give me x86 opcode errors when I try to start X. If I change the driver to Intel, it tells me "No devices detected".

 The files you provided previously(Mesa, etc), are for 32 bit or 64 bit?


----------



## dohmniq (Nov 11, 2012)

The tar contains Makefiles, patches, etc. which are all text files but no binaries so 32bit/64bit-ness doesn't really apply.

As we have nearly the same hardware at the same bus ID, could you try my xorg.conf and then attach your Xorg.0.log (bzip2 compressed) to a reply?


----------



## zspider (Nov 12, 2012)

Well I was about to collect the Xorg log, after seeing it not work again. I just decided to try putting it back exactly as it was in yours (without the extra 0) and amazingly this time it actually loaded an Xwindows desktop. 

Thank you very much for your help. I can finally run FreeBSD on my Intel graphics.:e


----------



## wblock@ (Nov 12, 2012)

BusID is not needed at all unless there is more than one video card.


----------



## zspider (Nov 12, 2012)

wblock@ said:
			
		

> BusID is not needed at all unless there is more than one video card.



This is a dual GPU laptop(Nvidia Optimus). I didn't mention that before, because I didn't think it was important.


----------



## wblock@ (Nov 13, 2012)

In that case, the usual advice is to disable one of the video cards in the BIOS.  But it would also be nice if you could just set up xorg.conf for the one that works and ignore the other one.


----------



## zspider (Nov 13, 2012)

wblock@ said:
			
		

> In that case, the usual advice is to disable one of the video cards in the BIOS.  But it would also be nice if you could just set up xorg.conf for the one that works and ignore the other one.



I've heard there are some laptops that do allow you to disable Optimus and just use the Intel graphics, this laptop does not give me an option to turn off Optimus. The autoconfig for X failed to identify my devices properly, but with some help it all worked out.. 

Maybe the FreeBSD foundation will get FreeBSD capable of dealing with Optimus someday. Then we could all use our Nvidia cards again. Until then I'm content to use the Intel.


----------



## drhowarddrfine (Nov 13, 2012)

zspider said:
			
		

> Maybe the FreeBSD foundation will get FreeBSD capable of dealing with Optimus someday.


That's the tail wagging the dog. I don't see people saying "Maybe Microsoft will get Windows capable of dealing with XXX someday". If the vendor doesn't supply the driver then there's a ton of work FreeBSD needs to accomplish that same task.


----------



## zspider (Nov 13, 2012)

Notice how I said someday, I don't expect it to happen anytime soon, if ever. It was also not a complaint, so there's no need to get up in peoples face about it.


----------



## Beastie (Nov 13, 2012)

That's quite interesting! I had seen in another thread that you have an Optimus-enabled laptop and I wasn't expecting it to work at all. I've seen many Linux users not being able to make either GPUs work (they just got black screens). Only machines with a hardware or BIOS on-off switch occasionally worked.


----------



## drhowarddrfine (Nov 13, 2012)

zspider said:
			
		

> Notice how I said someday, I don't expect it to happen anytime soon, if ever. It was also not a complaint, so there's no need to get up in peoples face about it.



My point is that many people expect the operating system to somehow have control over proprietary device driver software when they rarely do.


----------



## zspider (Nov 13, 2012)

drhowarddrfine said:
			
		

> My point is that many people expect the operating system to somehow have control over proprietary device driver software when they rarely do.



I know, short of Nvidia wanting to do it, and the necessary infrastructure on the FreeBSD side, it can never happen. The Intel graphics is respectable, it's been running nicely since I got it working. Forgive me for misunderstanding what you said earlier.


----------



## scottro (Jan 13, 2013)

I probably should have posted my post on the other thread, http://forums.freebsd.org/showthread.php?t=36468

in this one. At any rate, following the instructions here (but using svn, rather than the uploaded file, which I didn't notice till afterwards, it's all working for me.  I gave my steps, which are pretty covered here, in the thread I link above.


----------



## Taka (Feb 28, 2013)

Hi, Mr. dohmniq,

Thank you for your post. I've tried to upgrade Mesa and xf86-video-intel by using your tar file, since I want to use the sna acceleration. Unfortunately, I got an error at compile of xf86-video-intel. The error message is following. Do you have some ideas? 


```
/usr/local/include/intel_bufmgr.h:108 error: expected declaration specifiers or '...' before 'drm_clip_rect_t'
```
I'm using a fresh FreeBSD 9-Stable. I followed the order you wrote. Thank you in advance.

Regards, Taka


----------



## throAU (Mar 1, 2013)

drhowarddrfine said:
			
		

> That's the tail wagging the dog. I don't see people saying "Maybe Microsoft will get Windows capable of dealing with XXX someday". If the vendor doesn't supply the driver then there's a ton of work FreeBSD needs to accomplish that same task.



However, to put this in context, Microsoft does provide a stable driver ABI for the third party to code their driver(s) against, which probably makes it a lot easier for said third party to write and maintain a driver.


----------



## dohmniq (Mar 2, 2013)

Hello Taka,

I am currently running 9.1-RC2 but I'm not sure that's much different.

On my laptop, intel_bufmgr.h is in /usr/local/include/libdrm/ so maybe something went wrong with the build of libdrm? Did you build & install libdrm before trying to make xf86-video-intel?

I've managed to build xf86-video-intel 2.21.2 and it works fine here.

Currently installed:

libdrm-2.4.31_1
libGL-8.0.5
libGLU-8.0.5
dri-8.0.5
dri2proto-2.6
xf86driproto-2.1.1
xf86-video-intel-2.21.2

I hope to reinstall soon so I can double-check the build instructions and get back to you.

Dom


----------



## Taka (Mar 2, 2013)

Hello dohmniq,

This is Taka. Thank you for your reply. Yes. I did `make & make reinstall` for libdrm first. libdrm -> libGL -> libGLU -> dri -> video-intel

`make` atxf86-video-intel stops as follows.


```
In file included from intel.h:67,
                 from intel_batchbuffer.c:38:
/usr/local/include/intel_bufmgr.h:108: error: expected declaration specifiers or '...' before 'drm_clip_rect_t'
```

`pkg info -l libdrm` shows 
	
	



```
/usr/local/include/libdrm/intel_bufmgr.h
```
 and actually I have it there. However, strangely, /usr/local/include/intel_bufmgr.h is used.

I'll examine more.

Best, Taka


----------



## Taka (Mar 2, 2013)

Hi dohmniq,

I could make xf86-video-intel successfully now! I removed the file /usr/local/include/intel_bufmgr.h. I don't know which program installed the file. Maybe, it was wrong that I installed libdrm over the old libdrm by using [cmd=]make reinstall[/cmd].

I will test the sna acceleration from now. Thanks!

Best, Taka


----------



## chatzki (Oct 22, 2013)

It's been a third day I'm trying to build xorg-server. graphics/libGL fails with the following error:


```
gmake[4]: Entering directory `/usr/ports/graphics/libGL/work/Mesa-9.1.6/src/glsl/builtin_compiler'
  CXX      glsl_lexer.lo
  CXX      glsl_parser.lo
  CXX      ast_expr.lo
  CXX      ast_function.lo
In file included from ../../../src/glsl/glsl_types.h:31,
                 from ../../../src/glsl/ir.h:33,
                 from ../../../src/glsl/glsl_symbol_table.h:34,
                 from ../../../src/glsl/glsl_parser_extras.h:35,
                 from ../../../src/glsl/ast.h:30,
                 from ../../../src/glsl/ast_expr.cpp:24:
../../../src/mesa/main/mtypes.h:3420: error: 'GLDEBUGPROCARB' does not name a type
In file included from ../../../src/glsl/glsl_types.h:31,
                 from ../../../src/glsl/ir.h:33,
                 from ../../../src/glsl/glsl_symbol_table.h:34,
                 from ../../../src/glsl/ast_function.cpp:24:
../../../src/mesa/main/mtypes.h:3420: error: 'GLDEBUGPROCARB' does not name a type
In file included from ../../../src/glsl/glsl_types.h:31,
                 from ../../../src/glsl/ir.h:33,
                 from ../../../src/glsl/glsl_symbol_table.h:34,
                 from ../../../src/glsl/glsl_parser_extras.h:35,
                 from ../../../src/glsl/ast.h:30,
                 from glsl_parser.yy:29:
../../../src/mesa/main/mtypes.h:3420: error: 'GLDEBUGPROCARB' does not name a type
In file included from ../../../src/glsl/glsl_types.h:31,
                 from ../../../src/glsl/ir.h:33,
                 from ../../../src/glsl/glsl_symbol_table.h:34,
                 from ../../../src/glsl/glsl_parser_extras.h:35,
                 from ../../../src/glsl/ast.h:30,
                 from glsl_lexer.ll:27:
../../../src/mesa/main/mtypes.h:3420: error: 'GLDEBUGPROCARB' does not name a type
gmake[4]: *** [ast_expr.lo] Error 1
gmake[4]: *** Waiting for unfinished jobs....
In file included from ../../../src/mesa/main/imports.h:41,
                 from ../../../src/mesa/main/core.h:46,
                 from ../../../src/glsl/ast_function.cpp:28:
../../../src/mesa/main/errors.h:84: error: variable or field '_mesa_DebugMessageCallbackARB' declared void
../../../src/mesa/main/errors.h:84: error: 'GLDEBUGPROCARB' was not declared in this scope
../../../src/mesa/main/errors.h:85: error: expected primary-expression before 'const'
In file included from ../../../src/mesa/main/imports.h:41,
                 from ../../../src/mesa/main/context.h:52,
                 from glsl_parser.yy:32:
../../../src/mesa/main/errors.h:84: error: variable or field '_mesa_DebugMessageCallbackARB' declared void
../../../src/mesa/main/errors.h:84: error: 'GLDEBUGPROCARB' was not declared in this scope
../../../src/mesa/main/errors.h:85: error: expected primary-expression before 'const'
gmake[4]: *** [ast_function.lo] Error 1
gmake[4]: *** [glsl_parser.lo] Error 1
gmake[4]: *** [glsl_lexer.lo] Error 1
gmake[4]: Leaving directory `/usr/ports/graphics/libGL/work/Mesa-9.1.6/src/glsl/builtin_compiler'
gmake[3]: *** [all-recursive] Error 1
gmake[3]: Leaving directory `/usr/ports/graphics/libGL/work/Mesa-9.1.6/src/glsl'
gmake[2]: *** [all] Error 2
gmake[2]: Leaving directory `/usr/ports/graphics/libGL/work/Mesa-9.1.6/src/glsl'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/usr/ports/graphics/libGL/work/Mesa-9.1.6/src'
gmake: *** [all-recursive] Error 1
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** [do-build] Error code 1
Stop in /usr/ports/graphics/libGL.
===>>> make failed for graphics/libGL
===>>> Aborting update
===>>> Killing background jobs
Terminated
===>>> You can restart from the point of failure with this command line:
       portmaster <flags> graphics/libGL
===>>> Exiting
```
 
Please, help! gcc-4.6.3, FreeBSD 9.2-RELEASE amd64.


----------



## chatzki (Oct 22, 2013)

This was solved by forcefully deinstalling graphics/libGL and graphics/dri.


----------



## zspider (Oct 22, 2013)

chatzki said:
			
		

> This was solved by forcefully deinstalling graphics/libGL and graphics/dri.



Which you would _have_ known if you had checked /usr/ports/UPDATING section 20130929.


----------



## chatzki (Oct 23, 2013)

First, shame on me. From now on I solemnly swear blah-blah-blah. Second, where have you been at least three day ago, my wise advisor?


----------



## zspider (Nov 1, 2013)

drhowarddrfine said:
			
		

> That's the tail wagging the dog. I don't see people saying "Maybe Microsoft will get Windows capable of dealing with XXX someday". If the vendor doesn't supply the driver then there's a ton of work FreeBSD needs to accomplish that same task.



Looking back, I think I understand where you're going with this now. I agree, FreeBSD is fine as it is now. Such luxuries are not a priority for an operating system like this and that's just fine.  Sorry for not understanding, I see the light now.


----------



## chifuqi (Feb 3, 2014)

I followed by what  @dohmniq said,and it worked well. But I can't get console from GNOME.


----------



## chifuqi (Feb 3, 2014)

*Re:*



			
				dohmniq said:
			
		

> There is this advice from the freebsd-x11 mailing list:
> 
> 
> 
> ...



I followed by what you said, and it worked well *o*n my computer, but *I* can't get console from GNOME. *M*y /etc/X11/xorg.conf looks like this 

```
Section "ServerLayout"
	Identifier     "X.org Configured"
	Screen      0  "Screen0" 0 0
	InputDevice    "Mouse0" "CorePointer"
	InputDevice    "Keyboard0" "CoreKeyboard"

##############################################
	Option 		"AutoAddDevices"    "true" 
#	Option		"AutoEnableDevice" "false"
##############################################

EndSection

Section "Files"
	ModulePath   "/usr/local/lib/xorg/modules"
	FontPath     "/usr/local/lib/X11/fonts/misc/"
	FontPath     "/usr/local/lib/X11/fonts/TTF/"
	FontPath     "/usr/local/lib/X11/fonts/OTF"
	FontPath     "/usr/local/lib/X11/fonts/Type1/"
	FontPath     "/usr/local/lib/X11/fonts/100dpi/"
	FontPath     "/usr/local/lib/X11/fonts/75dpi/"
	FontPath     "/usr/local/lib/X11/fonts/wqy"
EndSection

Section "Module"
	Load  "dbe"
	Load  "dri"
	Load  "dri2"
	Load  "extmod"
	Load  "record"
	Load  "glx"
EndSection

Section "InputDevice"
	Identifier  "Keyboard0"
	Driver      "kbd"
EndSection

Section "InputDevice"
	Identifier  "Mouse0"
	Driver      "mouse"
	Option	    "Protocol" "auto"
	Option	    "Device" "/dev/sysmouse"
	Option	    "ZAxisMapping" "4 5 6 7"
EndSection

Section "Monitor"
	Identifier   "Monitor0"
	VendorName   "Monitor Vendor"
	ModelName    "Monitor Model"
#	HorizSync    28-33
#	VertRefresh  43-72
	ModeLine     "1366x768" 69.3 1366 1398 1430 1470 768 771 776 786
	Option	     "DPMS"
EndSection

Section "Device"
        ### Available Driver options are:-
        ### Values: <i>: integer, <f>: float, <bool>: "True"/"False",
        ### <string>: "String", <freq>: "<f> Hz/kHz/MHz"
        ### [arg]: arg optional
        #Option     "ShadowFB"           	# [<bool>]
        #Option     "DefaultRefresh"     	# [<bool>]
        #Option     "ModeSetClearScreen" 	# [<bool>]

##################################################
#	Option	    "FallbackDebug"	"True"
	Option	    "AccelMethod"     "sna"
##################################################


	Identifier  "Card0"
#	Driver      "vesa"
	Driver	    "intel"
	VendorName  "Intel Corporation"
	BoardName   "3rd Gen Core processor Graphics Controller"
	BusID       "PCI:0:2:0"
EndSection

Section "Screen"
	Identifier "Screen0"
	Device     "Card0"
	Monitor    "Monitor0"
	SubSection "Display"
#		Viewport   0 0
#		Depth     24
		Depth	  16
	EndSubSection
EndSection
 
Section "ServerFlags"
	Option	"DRI2"	"True"
	Option	"AIGLX"	"True"
EndSection
```

Thank you!


----------



## wblock@ (Feb 3, 2014)

As a general rule, posts more than a year old should be considered outdated.

Please read the wiki for the correct procedure: https://wiki.freebsd.org/Graphics#Installing_KMS_Ports.


----------



## tzoi516 (Feb 3, 2014)

wblock@ said:
			
		

> As a general rule, posts more than a year old should be considered outdated.



Even though I think that's a great "general rule", I think it's hard to know when it applies since people still link to old posts.


----------

