Valve Continues Recruiting Top Linux Talent
An anonymous reader writes "Valve Software, in their Linux Steam / Source Engine effort, plus the rumored Steam Box, is continuing to hire top Linux developers. So far they have poached the lead developers of the DarkPlaces open-source engine used by Nexuiz/Xonotic, the founder of Battle for Wesnoth, and just yesterday they hired Sam latinga, creator of Simple DirectMedia Layer. According to Michael Larabel, they are still trying to hire more Linux kernel developers, driver experts, and other 'extremely talented Linux developers.'"
Hope they port all those -games- to linux. A Linux Steam client isn't enough.
To offset political mods, replace Flamebait with Insightful.
Microsoft, Sony, and Nintendo may be in for an interesting landscape in 2013.
It's reasonable to assume Valve isn't doing this for the Linux desktop (though they may be doing things in such a way that Linux desktop is covered 'for free'), but likely related to the other rumors of a Steam branded game console.
If Steam gives a console-equivalent experience in a manner similar to their PC platform, it's likely to be as capable as Sony and MS platforms but a lot more approachable. The 'big studios' are likely to be very enthusiastic about it. So the 'AAA' games will likely hit a Valve platform and probably with a bit more aggressive pricing (at first) compared to Sony and MS.
On the low end, Ouya may stir things up significantly.
XML is like violence. If it doesn't solve the problem, use more.
Given that it seems all Nintendo, Microsoft and Sony will be going with AMD for their next-gen graphics hardware, nVidia will likely be the one to supply graphics hardware for the Steam box (as their Linux drivers are by far the most mature).
They are buying knowledge specifically experience not just skills. They are employing people who know far more about linux development than their current staff do.
Employing windows or whatever devs will delay them from having productive staff and will increase the chance they take the wrong approach to the problem. Only the genius windows devs will avoid thinking the windows way is the standard or best way to do something in linux.
I'm interested to see if this means that these newly hired valve devs will be put to improving the now lackluster Linux graphics drivers. In addition, with pressure or cooperation from valve, nvidia or and may also be more likely to improve on their open source / Linux drivers as well. Either way, this is probably gonna be a win win for the Linux / Linux gaming community.
But... this landscape is actually a fractal. If you zoom in a bit you can see whole new landscapes open in front of you. Someone who mostly programs in C# on windows system may not be entirely comfortable with writing a socket server on a UNIX machine. The various UNIX graphics libraries might be confusing and annoying to that person as well. As you start to learn the differences for things like socket handling on BSD style systems (And HPUX ugh,) you start to realize that platform experience does matter. Maybe not so much for your average application development, but if you're trying to squeeze something out of the hardware, it kind of does. A while back I wanted to write a segv stack dumper for C on an AIX system. The interrupt handler installation was pretty standard, but the stack dump code was VERY AIX specific.
Likewise on the language side of things, sure you can pick up the basics of Perl or C or any other (reasonable) language pretty quickly, but mastery of any specific language is something that could easily take an entire career. There's always something more to master. Maybe you want to force loop unwinding with funky switch tricks, maybe you want use C++ templates to set up matrix math at compile time. Maybe at some point you realize how unmaintainable doing that sort of thing actually is and decide not to do it anymore. The more you delve into any one area, the more you will find to learn. Things that looked good at one level might be completely different at the next.
The vast majority of programming projects out there really don't need this level of mastery, of course. Which brings you back to the top of the fractal. If you're the kind of person who can recognize the patterns, you can get by reasonably well on any platform in any language. But for any specific task, someone with more experience on that platform or with that language will almost always write more efficient code.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Poaching is the act of taking another persons livestock. The use of the word in this context means the author considers people the equivalent of livestock to the corporate ranchers.
I love Jesus, except for his foreign policy.
I did my Google Summer of Code project under Sam. He's a great guy, and he basically wrote SDL from nothing. Hell, as far as I'm aware, he's possibly the only living person who understands its autotools-based build system ;-).
He won't just be able to port games. If the rumors are true and Valve is building their own full-scale gaming platform (a Valve console, say), then putting Sam Lantinga with the Source engine for starters will be a great start to their platform's API.
I think it's still the most likely suggestion that's been raised so far. Another possibility is arcade machines, I know that industry is kind of whimpering in the corner right now but it's still feasible. Or given the hardware work they've done maybe they're imagining Linux-powered AR gaming? Who knows.
Source engine games will be easy ports, at least.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
It's times like this I'm sad when we've got a completely non-DRM store like GOG which is completely overshadowed by something like Steam, where the access to your games are entirely in the hands of Valve and if something fucks up, you can't play. We've now got a generation who believe this is OK, rather than someone older like me who's seen enough issues with such a system to be extremely weary of it.
I guess the only good part is that the number of people who've been fucked by Steam restrictions are probably far and few between, but given the little time most of us have to play games, I don't see why we can't just be fickle and go to non-DRM stores when purchasing games to feed what is ultimately a waste-of-time hobby.
Most people on Slashdot are fucking idiots.
Lantinga was at one of the first linux game companies, Loki Software, way way way back in the day, the company was trying to port windows games to linux and make a profit. Didn't work out so hot, but Lantinga made SDL out of it, and then he got the job at Blizzard .
Cmon folks lets get his name right.
While SDL overall is a great library, Sam is undoubtedly talented, and I thank him for releasing a great library, in many ways, I would not want him in charge of many things. I used to be a heavy SDL user so I am extremely grateful, but I have to say after moving on to SFML, Ogre, and other open source libs (as well as professionally working with everything from UDK to custom in-house engines and low-level libs), I want to stab SDL in the face. I can't really blame him too much since C is C, but sometimes that lib makes me cry.
Sam seems like a guy with some good ideas or who might be great for grunt work, but SDL is a horrid library in terms of design. Retrospect is nice of course...wish he would redo the lib from scratch. SDL has caused a lot of people some serious pain over the years, but conversely brought us leaps and bounds over what was freely available before. SDL is anything but a showcase of great design, although one could argue that it "just works." Such is the case with a lot of of software open or closed source in general. I just hope he has learned from his mistakes. Your comment about the build system is very revealing - if only one person understands it, this is not to be commended.
I can tell you one of the major barriers to entry I've faced in both the games and business software industry with open source is the horrid and neglected APIs, and in the case of C and C++ especially, the ridiculous build systems (bjam and boost, SDL and autotools, and so on). Hopefully he can learn from Valve and likewise they can learn from him. Wish him the best, but please don't let him design any more APIs without a sane human being editing and challenging his assumptions.
Let's face it, there are three things keeping Microsoft's OS in business: the Office ecosystem, games and people who spent their whole lives learning one way of doing thing, and don't want to change. Everything else not only can be done better by someone else, but is being done better by someone else.
With every new OS release, Microsoft themselves screw the people who fear change. Office is still the cash cow, but between LibreOffice and the Googlighting Stranger, their desktop suite is only a few years ahead. I can't comment on Sharepoint and Exchange, so I'll concede they probably play a major role in many businesses, and that many of those same businesses have no interest in Windows 8 Metro. Finally, there's games. Games, and DirectX games, was the reason to buy Windows. Hell, it's the reason I run it. But, in the heavily politicized corporate environment of Microsoft, games have a problem, and that problem is spelled XBOX. So we get abominations like MS GameZone, Games For Windows Live and Games for Windows Marketplace, or whatever they're calling it now. The Xbox people can't have windows cannibalize their games. This is how Microsoft lost to Linux in the HTPC battle: an Xbox belongs in the living room, not a Windows Box. Things have gotten so bad, the other players in the industry have their own Microsoft-Free group to promote gaming.
So Valve brings on board a developer with demonstrated skills in making cross-platform gaming tools. If they were able to produce a set of tools that allowed games to be developed and easily ported between the various full flavors of Linux, Mac, PC and Android, worked on Chrome OS, and connected to the largest online game delivery platform in business, well, wouldn't that be cool?
Don't worry, they'll probably do something less ambitious and more profitable.
to beef up the video drivers which have quality issues. and the audio system which frightens me to the point i live with it problems rather than try tinkering so they can have a solid system.
that the difference between Linux and windows. linux is a stable core but crappy trim. and windows has nice trim but a riquitty core. steam is giving linux the trim it needs for games to play nicely.
---Saying gnome 3 is better than windows 8 not so much a compliment as it is damning with light praise.
I'm always all for more games in linux and better gaming platforms for linux to ease in development of games, both of which i see Steam bringing. I'm curious if they will keep with the general spirit of the linux community and contribute back. Im hoping that them hiring plenty of linux talent isnt taking them away from too many open projects that attracted steam to them in the first place. Steam could probably contribute some good improvements back to the linux community in the forms of kernel patchs, improvements to X, graphics libraries, and im sure a whole host of other things. They aren't obligated to do that but I'm really hoping they do contribute back in some ways. Regardless its good to see them increasing their effort to deliver games to linux.
http://interserver.net/
> "Either Steam sucks as a platform or Linux sucks for doing game-oriented graphics."
That's a false dichotomy. You're missing the option that your understanding of Linux and what a kernel developer does "sucks". There are actually many good reasons they would want a kernel dev or two, and none of them require Steam or Linux to suck.
If the rumors are true and they really are releasing their own console, someone's got to write the device drivers for their unique hardware. The controllers will probably be of their own design, so that's the first thing that comes to my mind.
Device drivers in Linux are kernel modules and live in kernel space. Undoubtedly they will also want these developers to be expert at building custom kernels, as they would want an image with all the standard hardware modules compiled in place, and the non-relevant memory-consuming bits (support for file systems they won't use, etc.) removed.