It’s not really possible to distinguish between hinting and anti-aliasing here. At the end of the day, both are techniques for rendering vector data, with the first one being specialised to type or being a special case of the other. Both examples are clearly rendered making use of hinting and thus also of anti-aliasing. If at least one of them did not use hinting, this would have been different.
Here are two close-ups of your images (left: Ubuntu; right: Windows):
First of all: That some stems are not white but separated into blue and red components is due to subpixel hinting, which makes use of the fact that pixels on LCDs are separated into three subpixels. If well done, you will not see this separation when not zooming. In your examples, this mostly works; only in a few places of the Windows example, I can see artefacts.
Now, let’s have a look at the stem widths: The white text in the examples uses the same or almost the same stem widths, as can be seen rather well when looking at the vertical stems of the k, the = and the serifs of the l. Thus there should be no “bold” effect here and I cannot see one either.
However, looking at the red if in the bottom left, you can see serifs of the i as well as the bar of the f are exactly a pixel wide on Windows but wider on Ubuntu. Thus I would suspect that this word is actually supposed to be set in bold, but due to the low screen resolution and the different colour, this difference gets mostly lost.
A problem with rendering text is that you only integer stem widths look good and are hence preferred. You can easily see this when increasing your font size in your text editor: The stem width of the type does not grow every zoom level, but only every n-th – whenever the renderer switches from rounding down to rounding up. In your example, the regular text has a stem width of 1 px. A stem width of 2 px at the same size would be to much. Thus, the font renderer has to choose between the type looking sharp and the bold text being distinguishable from the regular text. If my boldface assumption was right, then Ubuntu’s renderer chose the first and Windows’ renderer chose the second.
The most striking difference between the two examples are the differing heights. In the Ubuntu example we have 3 px + 7 px + 3 px; Windows uses 2 px + 6 px + 2 px (descender + x height + ascender). Again, these are integer heights and the renderer has to decide how to translate, e.g., 2.5 px + 6.5 px + 2.5 px to integers. There is no clearly better choice here and thus it is not surprising that the different renderers made different choices.
Due to the increased glyph height, the Ubuntu example has more colour per glyph or per area. You may perceive this as a “bold” effect when comparing the two examples.