I've read conflicting reports on MS releasing a server OS for ARM. No short term plans for it (as of a year ago) to other claims it is inevitable/upcoming. AMD is going to be creating 64bit ARM chips (32bit vs 64bit was supposedly an issue with offering windows server for ARM.. though I'm not sure I buy that).

For most server stuff Linux is great (or BSD), but I have one application (as in purpose/use) where little ARM based servers running a windows OS would be perfect. Affordable, power efficient, small, but with enough processing power to do the task at hand. We're finally seeing some micro/pico itx arm boards, but the prices suck for performance and they don't have enough sata ports and no PCI slots etc. At this point I think I'm still better off with a little atom based board for most server duties.

Nothing is stopping you from using WiX, WiX Edit or another tool (outside of VS express) for making an installer (proper MSI file).

I can't live with the limitations of VS Express, but creating installers plays no part in that.

I completely agree. There is a lot of opportunity in fixing code. I did get to work on some modules, but nothing like what was needed. I also got to work with some co-ops (uni students) I was in charge of adding testing support (good, but not valuable enough to management to put a full time employee on it) and to work on a replacement for one of the modules (which has yet to be integrated, a year later, even though it bests the original implementation by a long shot). Ultimately we learned a lot from each other and had some fun.

Lot's of great engineers in that company still, plenty of opportunity to fix things (I still wake up with solutions to various issues in that system), but it all boils down to management. Basically any code can be fixed. Stuff that's usable/stable can be DLLized (decoupled some how with a proper API) and the horrid stuff gets rewritten. I have yet to work on something that's a complete throw away. The issue is you need the support of management in order to have the resources required to do the work (unless you want to spend long unpaid nights working on code for the good of what is ultimately someone else's company).

I ended up leaving mainly out of frustration (that and a good opportunity). I started my own company and hired one of the students I had worked with previously. I couldn't be happier.

Of course the company that treats its software products is still profitable, so there's no motivation or reason to change anything. Add a few features quick and "cheap" which sells a few more units and continues cruising on.

Very few companies are concerned with software maintainability. Yes, it saves money long run, but the types of people that tend to end up running companies that make software are short sited business types that are concerned about turning as big a profit as they can the next quart to year (exec bonuses are at stake!). In reality doing things "right" will mean less cost the entire life of the product. Yes, initial profits will be delayed, but over the life profits will be higher due to lower maintenance costs (and maintenance is the majority of a software's life cycle).

Your example is a little different as it sounds as though it was on the right track initially, but someone up top push some quick new features. Which works for the first while, but then coupling starts making any additions down the road hell. Of course they pay the price to do those additions (poorly) because rework costs even more than a feature that takes 50-100% longer than it should to implement. And it gets worse and worse, and eventually the product is dropped because it costs too much to do anything to or you've burned too much customer good will with your buggy POS. But hey, it was a good run and they made profit and got bonuses and have this shiny new product to drive into the ground.

Yep. Should have. Wasn't though. You know, budgets and such.

This.

Heck, just ask to look at the codebase. It's not like you'll be able to pick up any trade secrets in 30 minutes. Better yet have someone that currently works there go through some of the general ideas and show you the problem areas. A good employer should be willing to do this.

Another option is to talk to existing employees. At my previous place of employment we'd have a Q&A with at least a few devs that work on the project the prospective candidate will be working on. They know how good or bad the software is. What about bug/defect tracking? How far buried are they in bugs, or are they actually adding useful new features rather than treading water in a sea of shit code?

I've done the treading water in someone else's codebase. It's no fun. In that instance it was fixable but management wasn't willing to put sufficient resources (people/time) into solving the issues. At the same time management was frustrated that "soo much time is spent on maintenance". Well yeah, it's shit broken code with no unit tests written, no test harness of any sort, object oriented code written by two engineers that had never written anything object oriented, were new to the language it was coded in and had never worked on a software project of its magnitude. Oh, and the one remaining employee that wrote the original code is not willing to fix anything himself or even discuss the issues (he's CTO, so he's above that). A company's key product that generates the majority of their $10mil revenue, but they are only willing to put a couple devs on it (while the CEO puts as much staff as he can into his revenue sucking pet project). That kind of stuff is good to know going into a project.

Yeah, drive by wire would have saved my arm. That being said I'd prefer a hybrid system. It's nice to have proper road feel (go over a bump and you feel it in the steering wheel), but if some outside force moves the wheel dramatically then it decouples (sensing where the torque input is). Implementing such a system in an electric assisted steering assembly actually wouldn't be that difficult (often the wheel inputs to the electric assist which outputs to the rack, so it's just a matter of quickly decoupling the steering from the electric assist).

Yes I meant median

I didn't mean dropping it a gear in an emergency but rather driving in a lower gear at a slow speed so when you lift the accelerator you have the nice gradual braking. Decelerating in that way guarantees you have rolling friction rather than static friction of locking wheels. That's the aim of ABS, to have rolling friction rather than static locked wheels. Regardless of how fancy your ABS is, driving speed is what's going to make the biggest difference in braking distance.

I was recently in a car accident. An elderly man drove into us from the front passenger corner. We had nowhere to go as there was a tall meridian on the driver's side. Basically a case of: scrub off as much speed as possible by emergency braking and brace for impact.

When we were struck the steering wheel was forced to one side. Much like the auto system in the video. The difference was I didn't know that was going to happen (like the testers) so I didn't let go. The spinning wheel resulted in a broken radius and I now have a large plate and many screws in my arm holding it together. Are you expected to let go of the wheel when the alarm sounds? My guess is most people won't be able to react like that. No problem for the tester since he knows it's going to occur, in real life you most likely won't be able to react that quickly or your reaction will not be to let go.

Personally I'm a fan of systems like Mercedes has that primes the brakes for you when a possible collision is detected (so it's easier to apply full brake force). Auto braking is OK too, but there are too many factors in auto steering imho. Lane correction is one thing, this type of emergency steering is a whole other beast.

This.

Proper tires make all the difference. I have a FWD Rav4. Stock "all season" tires would cause it to go into a traction control seizure on slippery inclines (it would just shudder until you turn the traction control off). With some proper winter tires (full studable winter, not "winter rated") it was great in the snow and ice. I tried to get it out of control on purpose and between ETC and ESC it would right itself every time (this was in northern Canada with plenty of snow and ice in -20C).

Still have to watch for breaking though. If you are carrying too much speed and hit ice antilock isn't going to save you. Driving slow and engine braking will.

No. Not really.

Not all developers need to be able to read advanced pointer usage and tricks for the sake of tricks is stupid. There must be a measurable performance difference or it has to be easily readable by the group developing. If it isn't easily readable and there is no performance justification then education isn't the issue, it's developer ego, "Well I can read it."

Yeah, good for you. But I don't care about that. I care about whoever ends up having to maintain your difficult to read code. Prematurely optimize code, and even with ok comments I guarantee it's going to take longer to maintain (even for the original developer). Clear and concise is the way to go except in pure performance based applications (such as an OS kernel, embedded device etc). And even in those applications you only cross the line from clear and concise when necessary. In high level code you should always go simple until it's proven a simple solution won't work. That also goes for architecture. Simpler the better.

As a musician I see this all the time. Complexity for the sake of being complex. It's just musician ego. The best musicians have tons of technical ability, but apply it tastefully (not having to show it off at every possible opportunity).

DAMMIT. For halloween I want an edit button!

Fuck it. We're going full bars this year and cans of pop this year.

It'll actually be cheaper since we only had 12 kids last year (just the direct neighbors). My parents 10 minutes away get > 100.. heck people blocks away get that many (not that I'm complaining). When we buy the small candies the parents only let the kids take two max (even though we say, "help yourself!") so we end up gorging on the rest. I'll tape the chocolate bars to the pop, so "Just take one." Is a package deal.

I never said Linus was wrong. In fact I was agreeing it is correct in the kernel. A kernel dev would have no problem reading and understanding his example. Your average joe coder might stumble over it.

What? That doesn't make any sense in the context of replying to my comment.