Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Facebook

Facebook Seeks Devs To Make Linux Network Stack As Good As FreeBSD's 195

An anonymous reader writes Facebook posted a career application which, in their own words is 'seeking a Linux Kernel Software Engineer to join our Kernel team, with a primary focus on the networking subsystem. Our goal over the next few years is for the Linux kernel network stack to rival or exceed that of FreeBSD.' Two interesting bullet points listing "responsibilities": Improve IPv6 support in the kernel, and eliminate perf and stability issues. FB is one of the worlds largest IPv6 deployments; Investigate and participate in emerging protocols (MPTCP, QUIC, etc) discussions,implementation, experimentation, tooling, etc.

Comment Re:Still relevant nowadays? (Score 1) 58

Ive been working on a platform that is Linux running on a 1 GHz, 32 bit ARM, where we want to run an already existing Qt Quick 2 application. We have run mockup applications with X using the virtual framebuffer and the mesa software renderer, and found performance to be really bad. On the order of 1 FPS or so. Any suggestions on ways to make the software renderer more usable? My understanding is that LLVM would help here, but only works on x86 and x64.

Comment Re:BeOS kicked butt, give Haiku a break! (Score 5, Interesting) 70

On hardware from circa 2001, BeOS had an audio latency of about 3 msec from input to output. I don't know the x86 / x64 number, but in 2014 running on the best ARM hardware available, by default, the Linux scheduler runs every 10 msec, so audio latency of 40-80 msec is pretty common. In many applications, that is quite a significant difference. There are good reasons why Linux has this latency, but it is a question of optimizing for different use cases. BeOS had a laser focused use case of Desktop performance. Linux is used on servers, desktops, embedded, super computers, and all kinds of wierd places.

Comment Except that it is a felony (Score 1, Interesting) 528

"The lower receiver is the the 'body' of a gun, and its most regulated component. So 3D-printing that piece at home and attaching other parts ordered by mail might allow a lethal weapon to be obtained without any legal barriers or identification." This is true, but to print a receiver without a federal firearms manufacturing license is a felony. I can mill one out of aluminum without a 3d printer, it would last a lot longer, but that doesn't make it legal. In general, most "bad" things that people can do with a firearm, are already illegal.

Comment Re:Just remember (Score 2) 403

"You get what you pay for." This is absolutely correct, and is where much outsourcing goes wrong. I work for a company that does contract engineering or "outsourcing as a team". We are based in Indianapolis, speak English, answer phone calls, do our best to accurately estimate work, and are very up front about our areas of expertise. In almost all cases, I think we do an excellent job of representing ourselves, and what we are capable of. We have been in business for 15 years, are employee owned, and have almost no employee turnover. We currently have about 70 employees. We specialize in consumer electronics, medical, and industrial products, and do schematic design, mechanical design, ecad, mcad, prototyping, firmware development and testing. Many of our devices are Linux based, or on smaller parts run a custom OS developed in house. We are very strict in enforcing NDA agreements that we have in place with our customers. Being in this industry for so long, we receive lots of projects that have come out of failed business relationships with competitors. This highlights my main point, and that is that you must do business with someone you trust. If you are worried about "opening up core libraries", and hiding your IP from the software engineers you are paying, then you have the wrong partner. On the same token, we see a lot of trends in failed projects that come to us for repair after a failed relationship with a competitor. One of the biggest is that customers do not value or do not wish to pay for documentation. Without paying for a requirements document, and an architecture document, with review sign offs, there is nothing written down that says both sides agree on what is being produced. Many customers come to use thinking they have already done their architecture, and that they have all the details figured out. We find that in almost all cases, this is not correct. A 10 page document is not an architecture, and a 1 piece marketing blurb is not requirements. Another common failure is lack of communication. At a very minimum, an hour a week to meet and discuss progress is important. If either side has a problem with this, the relationship is in big trouble. I could go on and on, but it starts to sound like an advertising spiel. Virtually all of our projects end in success, and we work hard to hold up our side of the bargain. the counterpoint to that is that we are not "cheap". We are very talented, many of us have masters degrees in technical areas, and we generally do a lot more designs in a given time than most of our clients, so we grow experience faster with different vendors / libraries / platforms / parts / tools, what have you. We need to make a living, be able to pay our expenses, and be able to attract good talent, so we charge accordingly. Our project success rate, and the number of clients that return to us again and again justifies this. In almost all cases, I think that we end up saving our clients money, due to reducing their overhead of hiring and managing engineers, and our ability to get their projects done faster.

Slashdot Top Deals

Saliva causes cancer, but only if swallowed in small amounts over a long period of time. -- George Carlin

Working...