<?xml version="1.0" encoding="utf-8" ?>
<rss version="2.0" xmlns:osnews="http://www.osnews.com/rss2#">
	<channel>
		<title>OSNews: </title>
		<link>http://www.osnews.com/story/26600/Linux_3_7_released</link>
		<description>Exploring the Future of Computing</description>
		<language>en-us</language>
		<copyright>Copyright 2001-2013, David Adams</copyright>
		<webMaster>adam+nospam@osnews.com</webMaster>
		<lastBuildDate>Wed, 22 May 2013 13:37:00 GMT</lastBuildDate>
		<image>
			<url>http://www.osnews.com/images/osnews.gif</url>
			<title>OSNews.com</title>
			<link>http://www.osnews.com</link>
		</image>
		<item>
			<title>TCP Fast Open</title>
			<link>http://www.osnews.com/thread?544718</link>
			<guid isPermaLink="true">http://www.osnews.com/thread?544718</guid>
			<description>Don't get your hopes up about TCP Fast Open just yet.<br />
Early testing shows it has issues in some situations (<a href="https://lists.bufferbloat.net/pipermail/cerowrt-devel/2012-December/000733.html" rel="nofollow">https://lists.bufferbloat.net/pipermail/cerowrt-devel/2012-December/...</a>)<br />
<br />
Although this is an Internet-wide feature (if it makes it) but implementations only exist in Linux - (3.6 client and 3.7 server)</description>
			<pubDate>Tue, 11 Dec 2012 19:50:00 GMT</pubDate>
			<author>donotreply@osnews.com (pysiak)</author>
			<category>Comments</category>
		</item>

		<item>
			<title>RE: TCP Fast Open</title>
			<link>http://www.osnews.com/thread?544721</link>
			<guid isPermaLink="true">http://www.osnews.com/thread?544721</guid>
			<description>That is unfortunate, but it only affects those systems where the same IP-address changes behaviour for new TCP-connections.<br />
<br />
&quot;luckily&quot; it won't be in use on the Internet for a while, because server programs need to enable it with a special option. See the article:<br />
<br />
<a href="https://lwn.net/Articles/508865/" rel="nofollow">https://lwn.net/Articles/508865/</a><br />
<br />
So there might be still time to fix it.</description>
			<pubDate>Tue, 11 Dec 2012 21:25:00 GMT</pubDate>
			<author>donotreply@osnews.com (Lennie)</author>
			<category>Comments</category>
		</item>

		<item>
			<title>Comment by marcp</title>
			<link>http://www.osnews.com/thread?544735</link>
			<guid isPermaLink="true">http://www.osnews.com/thread?544735</guid>
			<description>I hope it fixed the bug that holds me on older kernel ...</description>
			<pubDate>Wed, 12 Dec 2012 00:56:00 GMT</pubDate>
			<author>donotreply@osnews.com (marcp)</author>
			<category>Comments</category>
		</item>

		<item>
			<title>Comment by kaiwai</title>
			<link>http://www.osnews.com/thread?544753</link>
			<guid isPermaLink="true">http://www.osnews.com/thread?544753</guid>
			<description>The inclusion of support for ARM64 is particularly interesting given the opportunity for ARM64 not only be a great alternative to Intel on the desktop, laptop and maybe workstation but also would be a great CPU for dense server configurations where heat and power consumption needs to be kept to a minimum. Regarding standardisation of ARM - I hope that maybe with the work done by Microsoft to standardise the ARM platform it will result in more uniformity and thus meaning a lot less code to get things done.</description>
			<pubDate>Wed, 12 Dec 2012 03:47:00 GMT</pubDate>
			<author>donotreply@osnews.com (kaiwai)</author>
			<category>Comments</category>
		</item>

		<item>
			<title>RE: Comment by marcp</title>
			<link>http://www.osnews.com/thread?544755</link>
			<guid isPermaLink="true">http://www.osnews.com/thread?544755</guid>
			<description>which bug?</description>
			<pubDate>Wed, 12 Dec 2012 03:51:00 GMT</pubDate>
			<author>donotreply@osnews.com (diegoviola)</author>
			<category>Comments</category>
		</item>

		<item>
			<title>RE: Comment by kaiwai</title>
			<link>http://www.osnews.com/thread?544813</link>
			<guid isPermaLink="true">http://www.osnews.com/thread?544813</guid>
			<description>The good thing is, it also supports running existing 32-bit ARM applications.</description>
			<pubDate>Wed, 12 Dec 2012 13:04:00 GMT</pubDate>
			<author>donotreply@osnews.com (Lennie)</author>
			<category>Comments</category>
		</item>

		<item>
			<title>RE: Comment by kaiwai</title>
			<link>http://www.osnews.com/thread?544821</link>
			<guid isPermaLink="true">http://www.osnews.com/thread?544821</guid>
			<description>kaiwai,<br />
<br />
&quot;The inclusion of support for ARM64 is particularly interesting given the opportunity for ARM64 not only be a great alternative to Intel on the desktop, laptop and maybe workstation but also would be a great CPU for dense server configurations where heat and power consumption needs to be kept to a minimum.&quot;<br />
<br />
Absolutely! x86 competition will be very much welcomed.<br />
<br />
<br />
&quot;Regarding standardisation of ARM - I hope that maybe with the work done by Microsoft to standardise the ARM platform it will result in more uniformity and thus meaning a lot less code to get things done.&quot;<br />
<br />
I only hope the majority of new standardised ARM computers entering the market won't be corrupted with mandatory secure boot keys locked down to microsoft. I know you'll hate me for pointing this out, but it still needs to be said. Microsoft is insisting that ARM computers that will run windows are prohibited from running anything else.<br />
<br />
Yay for standardisation. Boo for dictated secure boot.Edited 2012-12-12 15:05 UTC</description>
			<pubDate>Wed, 12 Dec 2012 15:03:00 GMT</pubDate>
			<author>donotreply@osnews.com (Alfman)</author>
			<category>Comments</category>
		</item>

		<item>
			<title>RE[2]: Comment by marcp</title>
			<link>http://www.osnews.com/thread?544845</link>
			<guid isPermaLink="true">http://www.osnews.com/thread?544845</guid>
			<description>Nastey one that freezes my whole system [silent kernel panic under working Xorg]. It happens when I use some sort of multimedia on the other workspace and when I switch between workspaces. It happens on an Intel card. I've submitted the bug and I really hope they'll be able to fix it, although for now this bug report is not being resolved.<br />
I don't want to give links, because I don't wish to disclose any information about personal details.</description>
			<pubDate>Wed, 12 Dec 2012 16:50:00 GMT</pubDate>
			<author>donotreply@osnews.com (marcp)</author>
			<category>Comments</category>
		</item>

		<item>
			<title>RE[2]: Comment by kaiwai</title>
			<link>http://www.osnews.com/thread?544937</link>
			<guid isPermaLink="true">http://www.osnews.com/thread?544937</guid>
			<description><div class="cquote">Absolutely! x86 competition will be very much welcomed. </div><br />
<br />
At one point Intel used to sell ARM processors so maybe in the future we'll see Intel use the same underlying architecture but bolt the ARM ISA on top of it thus giving them the architectural edge whilst maintaining compatibility with the rest of the ARM ecosystem (Qualcomm IIRC licences the ISA but has their own CPU design).<br />
<br />
<div class="cquote">I only hope the majority of new standardised ARM computers entering the market won't be corrupted with mandatory secure boot keys locked down to microsoft. I know you'll hate me for pointing this out, but it still needs to be said. Microsoft is insisting that ARM computers that will run windows are prohibited from running anything else.<br />
<br />
Yay for standardisation. Boo for dictated secure boot. </div><br />
<br />
Secure boot is an interesting situation given that the argument made regarding ARM was the fact that it was a new form factor for Microsoft but what they were doing was pretty much bringing it inline with other vendors who also make life difficult (note the cottage industry of 'rooting' Android devices - so much for 'open source' and 'freedom' if you're required to hack the crap out of a device you've just bought just so you can receive timely Android updates - but I digress). If there is something that needs to occur it is a move away from locking down devices because some wanker at a mobile phone carrier has a control freak fetish or some good intentioned know it all thinks it is their job to stop the end user from being a moron.<br />
<br />
For me whether they standardise around UEFI (minus secure boot or at least have the option to turn it off) or CoreBoot with maybe the UEFI or OpenBoot payload - it doesn't really matter as long as there is some sort of standardisation that doesn't require developers to write thousands of lines of code that should be idealy shared between different vendors and the code divergence occurring around the edges rather than at the core.</description>
			<pubDate>Thu, 13 Dec 2012 04:04:00 GMT</pubDate>
			<author>donotreply@osnews.com (kaiwai)</author>
			<category>Comments</category>
		</item>

		<item>
			<title>RE[2]: Comment by kaiwai</title>
			<link>http://www.osnews.com/thread?544939</link>
			<guid isPermaLink="true">http://www.osnews.com/thread?544939</guid>
			<description><div class="cquote">The good thing is, it also supports running existing 32-bit ARM applications. </div><br />
<br />
The biggest question is how well optimised is the user land given the douchy behaviour of the GNU libc maintainer Ulrich Drepper who is dismissive of addressing issues relating to non-x86 platforms.</description>
			<pubDate>Thu, 13 Dec 2012 04:20:00 GMT</pubDate>
			<author>donotreply@osnews.com (kaiwai)</author>
			<category>Comments</category>
		</item>

		<item>
			<title>RE[3]: Comment by kaiwai</title>
			<link>http://www.osnews.com/thread?544948</link>
			<guid isPermaLink="true">http://www.osnews.com/thread?544948</guid>
			<description>kaiwai,<br />
<br />
Well, I certainly agree with that.<br />
<br />
It's easy to point the finger exclusively at MS due to their involvement, but I'm afraid of what might happen if others follow. As you've noted, other mobile device vendors (including apples&amp;androids) already lock down their OS with different levels of success. I have every reason to believe that those who locked-down non-UEFI devices will switch to secure boot just as MS does to restrict end-user modifications on future UEFI devices.<br />
<br />
If that actually happens, we'll end up with a plethora of standard ARM UEFI devices (yay), most of which will prohibit any owner override (boo).</description>
			<pubDate>Thu, 13 Dec 2012 05:18:00 GMT</pubDate>
			<author>donotreply@osnews.com (Alfman)</author>
			<category>Comments</category>
		</item>
	</channel>
</rss>
