Anonymous Hacker writes "I'm in a bit of a bind. My young teenage son is starting to get curious about computers, and in particular, programming. Now, I'm a long time kernel hacker (Linux, BSD and UNIX). I have no trouble handling some of the more obscure things in the kernel. But teaching is not something that I'm good at, by any means. Heck, I can't even write useful documentation for non-techies. So my question is: what's the best way to encourage his curiosity and enable him to learn? Now, I know there are folks out there with far better experience in this area than myself. I'd really appreciate any wisdom you can offer. I'd also be especially interested in what younger people think, in particular those who are currently in college or high school. I've shown my son some of the basics of the shell, the filesystem, and even how to do a 'Hello World' program in C. Yet, I have to wonder if this is the really the right approach. This was great when I was first learning things. And it still is for kernel hacking, and other things. But I'm concerned whether this will bore him, now that there's so much more available and much of this world is oriented towards point-n-click. What's the best way to for a young teen to get started in exploring this wonderful world of computers and learning how to program? In a *NIX environment, preferably." Whether or not you have suggestions for generating interest or teaching methods, there was probably something that first piqued your curiosity. It seems like a lot of people get into programming by just wondering how something works or what they can make it do. So, what caught your eye?

chareverie writes "Fortify Software released a study where they concluded that open source software poses a large security risk to corporations who have implemented it. They reason this by stating that the fault lies within the open source communities and their failure to adhere to minimum security practices. Fortify Software studied 11 open source software packages, where the application server Tomcat was determined to be the best. The other 10 were found to have poor results, with those being Derby, Geronimo, Hibernate, Hipergate, JBoss, Jonas, OFBiz, OpenCMS, Resin and Struts. Jacob West, manager of Fortify's research group, reminds that purpose of the study was 'not to condemn open source software, but rather to point out that the security practices need to improve because open source adoption by enterprises and governments is growing.'"

Michael J. Ross writes "Many Web developers wish to create e-commerce sites that also support collaborative editing of content, community forums, and other features that can increase traffic to the sites. But most shopping cart products do not include those capabilities, or, if such third-party add-ons exist, they may be quite limited in functionality. Similarly, most if not all content management systems (CMSs) lack native e-commerce capabilities. Yet that barrier is being overcome, because a handful of e-commerce modules have been created for the most popular CMSs. Perhaps the most promising pairing, at this time, is Drupal and the e-Commerce module — a combination covered in the book Selling Online with Drupal e-Commerce by Michael Peacock." Keep reading for the rest of Michael's review.

jcatcw writes "Quick, incremental updates, along with heavy user involvement, are key characteristics of the emerging software development methods championed by a new generation of Web 2.0 start-ups. A survey conducted for Computerworld showed that an overwhelming majority of the respondents said that traditional corporate development teams could benefit from Web 2.0 techniques, specifically the incremental feature releases, quick user feedback loops and quality assurance programs that include users. Fifty seven percent of the respondents said problem-solving and analytical skills will be key requirements for next generation developers. The bottom-line: corporate development teams need to get to know their users."

PainMeds writes "iPhone Atlas is reporting that the first jailbreak for the iPhone 3G has been released, and includes the popular Cydia community installer for distributing free games and applications. Since Apple's SDK was released, web sites have criticized Apple for the restrictions placed on both what developers could write and what APIs they were allowed to use. Others have noted the SDK's incompatibility with the GPL. The Cydia installer has provided a distribution channel for both open source software and software that would otherwise be impossible to build using the restricted SDK. A few applications are already out, including MobileTerminal and NES.app, a Nintendo game console emulator. In just over a week, open development is finally here for the iPhone 3G!"

dm writes "I run a small design shop and have been doing more and more web development, including fairly involved back-end programming of what's now essentially become our own CMS. Up to now I've been doing all the programming myself. Now we are working with a second programmer for the first time. I already use version control (SVN) and an issue-tracking system, and I guess we are both decent at what we do — although self-taught, but we both lack experience programming in a team context. Is there a useful guide for this? Most of the tutorials I have seen for Subversion are surprisingly organized from a single coder's perspective. Where else should I look?"

An anonymous reader writes "Jacob Appelbaum, one of the security researchers who worked on the cold boot attacks to recover encryption keys from memory even after reboot, has announced the release of the complete source code for the utilities at The Last HOPE in New York City. The hope (obligatory pun) is that the release of these tools will help to improve awareness of this attack vector and enable the development of countermeasures and mitigation techniques in both software and hardware. The full research paper (PDF) is also available."

An anonymous reader writes "If you've been hired by a serious software development house, chances are one of your early familiarization tasks was to read company guidelines on coding standards and practices. You've probably been given some basic guidelines, such as gotos being off limits except in specific circumstances, or that code should be indented with tabs rather than spaces, or vice versa. Perhaps you've had some more exotic or less intuitive practices as well; maybe continue or multiple return statements were off-limits. What standards have you found worked well in practice, increasing code readability and maintainability? Which only looked good on paper?"

pacopico writes "Stanford professor Kunle Olukotun designed the first mainstream multi-core chip, crafting what would become Sun Microsystems's Niagra product. Now, he's heading up Stanford's Pervasive Parallelism Lab where researchers are looking at 100s of core systems that might power robots, 3-D virtual worlds and insanely big server applications. The Register just interviewed Olukotun about this work and the future of multi-core chips. Weird and interesting stuff."

An anonymous reader sends us to a writeup about when and how to recycle code, excerpting: "As developers, once we start separating our code into abstract ontological typologies, we make use of the human mind's phenomenal ability to work with types. Our code becomes less about jump tables and registers and more about users, email messages and images. What once was a problem of allocating resources and operations within the computer becomes an abstract, logical problem within a collection of objects....Over time, by constantly working to reuse our own code, we choose practices that work well for ourselves and discard practices that don't work as well or slow down our workflow. For developers flying solo or those working on small projects, this evolutionary process is a sufficient way of going about things. But there's trouble when we add other players into the mix--other developers, a user interface person, a database person, a sysadmin, a project mana-jerk: as a developer, they don't have access to our 'experience' of the code and we don't have access to theirs. "

An anonymous reader writes "The age-old full disclosure debate has been raging again, this time in no other place than at the foundations of the open-source flagship GNU/Linux operating system: within the Linux kernel itself. It beggars belief, but even Linux creator, Linus Torvalds, has advocated against the sort of openness on which Linux has thrived, arguing that security fixes to the kernel should be obscured in changelogs, saying 'If it's not a very public security issue already, I don't want a simple "git log + grep" to help find it.' Unfortunately, it's not kernel exploit writers who need to grep the changelog in order to find kernel vulnerabilities. On the contrary, it's downstream distributors who rely on changelog information in order to decide when to patch the kernels of their distributions, in order to keep their users safe."

Anonymous Dolphin writes "MySQL has released plans for a final RC for the MySQL 5.1 server. Monty Widenius, the CTO and founder of MySQL, has put up a request for more feedback from the community. You can get the latest RC here. Please help with the testing of 5.1 and report your bugs here."

cliffski raises some questions about the need for game developers to have some amount of data from the users who play their games. He says, "PC Games connecting to a central server to send information (outside of MMOs) have gotten a (deserved) bad reputation in recent years. The huge outcry about Mass Effect and Spore are evidence enough of that. But in gamers' hurry to prevent intrusive DRM systems and dubious privacy-breaking data harvesting, are we throwing out the good with the bad?" Clearly, some aspects of games could be improved by having a better knowledge of average PC specs or knowing which parts of the games are more entertaining to the users. Input from customers helps to improve almost any product, as indicated by the usage of countless surveys and focus groups. But where do we draw the line between being inquisitive and being intrusive? What can game developers do to prove that the collection techniques or the data themselves wouldn't be abused?

Hugh Pickens writes "About 60 people from 20 nations will descend on the MIT campus July 14th for the second annual International Development Design Summit to begin an intensive month-long process of creating technological solutions for the needs of people in the world's developing nations. The goal of the program is to develop simple, inexpensive devices that in some cases can be produced locally and make a real difference for people and communities. The event is the brainchild of MIT Senior Lecturer Amy Smith, a returned Peace Corps volunteer and a past winner of the MacArthur 'genius' grant. Previous products of Smith's design class include a bike-powered corn sheller, a metal press that can make clean-burning fuel out of agricultural waste, and an electricity-free incubator. The workshop promotes a shift in focus among companies, universities, investors and scientists toward attacking problems that hamper development in the world's poorest places. 'Nearly 90 percent of research and development dollars are spent on creating technologies that serve the wealthiest 10 percent of the world's population,' Ms. Smith said. 'The point of the design revolution is to switch that.'"

Todd writes "I've been looking around at 'help wanted' advertisements for programming jobs, and almost all of them demand that you not only have professional experience, but also that you show samples of your work. This got me wondering; with the work product, trade secret, and non-disclosure laws/agreements, how exactly can you show work that you've done in a professional capacity to a prospective employer without violating the privacy of the company for which the code was written? For instance, I can't say I've written many BASH scripts (at least, not large ones) for myself personally, but the assortment of such scripts written for my current job is wide and varied indeed. I can't very well just deliver these scripts, or even small portions thereof, to third parties to help demonstrate my scripting prowess. With that in mind, what am I supposed to show them?"

snydeq writes "Fatal Exception's Neil McAllister raises questions regarding Web development skills in an era of constant innovation. Sure, low barriers to entry give underdog technologies ample opportunity to thrive without the backing of name-brand vendors. But doesn't this fragmentation of the Web development market put undue pressure on developers to specialize? Choosing one tool to be your bread and butter from a field this broad is one thing, McAllister writes. Recruiting talent for a Web project when your technology requirements eliminate most of the applicants is another. The result is a crisis, McAllister concludes, one in which maintaining a marketable skill set gets more and more difficult as the so-called state of the art changes on an almost daily basis."

Matthew Fluet writes "The 11th Annual ICFP Programming Contest begins July 11 (12:00 Noon PDT) and runs through July 14 (12:00 Noon PDT). As in the previous ten editions, this is your chance to show that your favorite programming language (or your team) is better than all others! In addition to prize money, the winner's programming language is declared the 'programming language of choice for discriminating hackers.' Contestants may use any programming language (or combination of languages) to show their skill. How will your favorite language fare?"

chromatic writes "Imagine managing a million lines of code to send over seven hundred pounds of equipment millions of miles through space to land safely on Mars and perform dozens of experiments. You have C, 128 MB of RAM, and very few opportunities to retry if you get it wrong. O'Reilly News interviewed Peter Gluck, project software engineer for NASA's Mars Phoenix Lander, about the process of writing software and managing these constraints — and why you're unlikely to see the source code to the project any time soon."

Ste sends along the cheery little story of Otto Moerbeek, one of the OpenBSD developers, who recently found and fixed a 33-year-old buffer overflow bug in Yacc. "But if the stack is at maximum size, this will overflow if an entry on the stack is larger than the 16 bytes leeway my malloc allows. In the case of of C++ it is 24 bytes, so a SEGV occurred. Funny thing is that I traced this back to Sixth Edition UNIX, released in 1975."

A number of readers have noted Google's open sourcing of their internal data interchange format, called Protocol Buffers (here's the code and the doc). Google elevator statement for Protocol Buffers is "a language-neutral, platform-neutral, extensible way of serializing structured data for use in communications protocols, data storage, and more." It's the way data is formatted to move around inside of Google. Betanews spotlights some of Protocol Buffers' contrasts with XML and IDL, with which it is most comparable. Google's blogger claims, "And, yes, it is very fast — at least an order of magnitude faster than XML."