Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 18 Jan 2008
Offline Last Active Today, 08:29 AM

Topics I've Started

GD.net triggers Avast (convinced this is serious)

20 October 2015 - 08:12 AM

Avast just reported gamedev as malicious website attempting to display the profile. Almost certainly doesn't mean anything, but thought I'd mention:
Grr... apparently neither pasting an image nor attaching the file works either...
There, that works
(the "more details" button shows the exact same info in a bigger window, so I haven't included that one)

Alice Corp. v. CLS Bank

29 June 2015 - 08:55 AM

I just stumbled across Alice Corp. v. CLS Bank. If I read this correctly, the US Supreme court has ruled that ideas without implementation are not eligible for patents (and that they have for a long time warned to assume this).


Does that mean that we can expect obvious trolling patents such as e.g. Treehouse's patent on "transmitting data to the user over a network and letting the user make choices" will finally be considered invalid?


That sounds too good to be true. US patent law getting reasonable?

I almost fell for this...

13 March 2014 - 08:45 AM

Woah! Dude! Seriously!


NVIDIA Dropping Pre-Fermi GPUs From Their Mainline Linux Driver

NVIDIA will be removing all support for graphics processors prior to the GeForce 400 "Fermi" series from their mainline Linux graphics driver.

There's a new posting on the NVIDIA Knowledgebase about "EOL driver support for legacy products." Beginning with the "Release 343" series (as of last week the 334.21 Linux driver is the latest available version) there is no GPU support prior to the GeForce 400 series and that's now been confirmed via this official NVIDIA.com entry.



That sounds like very serious news for Linux GPU support with immediate and present consequences. On the other hand, if you read the official statement, it reads a bit different:

  • will continue to support these products until April 1, 2016
  • future driver enhancements and optimizations [..] will not support these products

Read as: No new gimmicks, and no new features on pre-2009 cards which the hardware doesn't support anyway. Will continue to support these for (at least) 2 more years cards, after which these cards will be between 7 and 10 years old.


Man, it's always nice if  one reads the complete paragraph before publishing a big FUD headline... at least they also tell the correct details further down in the article.

Using IPv6 flow info

18 December 2013 - 08:44 AM

The socket structures for IPv6 sockets have a couple of "mostly useless" fields such as the scope id (which you only need to disambiguate link-local addresses) and flow info.


When trying to figure out whether I can actually scratch that seemingly useless info (not logging more than absolutely necessary in the DB, and 128bit addresses are already big enough), it turned out that flow info may not be all that useless at all.


Apparently, you have the option of setting it to a zero value, in which case it is ignored and packets are routed to the destination socket based on destination address and port. Or, you can set it to a chosen non-zero value, in which case the IP stack considers the packet being part of some group of packets that somehow belong together (a "flow").


It seems that hardly anyone uses flow info (there is very little info available, many people seem to consider it deprecated or useless or don't understand what it does) or assume that getaddrinfo will fill in something meaningful that they don't really have to bother about. It does, too, ... it fills in zero.


There exists, however, at least one person with name Black who suggests using flow info as a transport-layer nonce to prevent spoofing attacks. Also, according to the RFC, routers are strongly encouraged not to route packets that belong to the same flow via different routes.


The former does not truly convince me, but the latter actually sounds very interesting. If you can hint routers not to route your packets via alternating routes, you should be able to effectively minimize the number of duplicates you get at the receiving end. That alone might be enough of a reason to always set the flow control field to some random value when initiating a connection. If you only have IPv4 on one of the ends, it'll come out as zero anyway and be ignored, but if both ends are IPv6, this should really help some.

Is that assumption right?


As for being used as a transport-layer nonce, I would guess that if someone can figure that you have a connection of sorts on some port/address combination (which is necessary to spoof packets in the first place), then he can obviously read your traffic. Otherwise, how would he know? So the nonce would be trivially known and spoofable. Or am I making a wrong assumption there?

Stunned after reading a data sheet

07 November 2013 - 11:03 AM

I just read through the data sheet of a 4TB Seagate hard drive which says "Nonrecoverable Read Errors per Bit: 1 sector per 1014. Guess that's none better or worse than any other harddisk's error rate, only maybe you've never looked or the manufacturer doesn't publish it.

Anyway, this got me thinking, 1014 bits is only about 11.5 terabytes. It's a 4TB disk. Therefore, assuming you fill this disk using its complete capacity, there is an 1/3 chance that you have an unrecoverable defect sector. After only one complete write cycle? Note that the emphasis is on "nonrecoverable", I am certainly aware that one or the other bit may always flip by accident, that's just how things work -- but the drive's FEC will routinely correct that.
If you do 3 complete write cycles, you are statistically more or less guaranteed to have at least one nonrecoverable defect sector. Not seriously?

I must have some fallacy in my reasoning? Surely harddisks must despite all be a little more reliable than to allow 3 write cycles?