custardcream

There may be a few people who pull bits of it in but I suspect that bad memories and some of the real nasty portability problems (perf counters, COM, services, registry, config, iis tie in etc) will be a lot of friction and a barrier to entry.

(I say this as someone who writes c# for a living)

(or visual studio community if you qualify)

1. Solved problem. Contribute to something else.

2. Its another tentacle hanging off systemd. Some of us pay for our software (RHEL) so we'd in turn like to have some say in what we have to manage rather than prescriptive software development. We don't really get to choose to not use it because of the incestuous nature of the Linux ecosystem at the moment (I.e. Freedesktop/gnome/systemd).

3. Systemd is a buggy piece of crap. As are several of the "stable" bits of systemd I have encountered in RHEL7. I have quite a bit of experience with systemd and i really don't want it consuming any more things badly. Its been a complete pain in the arse to be honest. An init system has never been a problem until now. Its totally unreliable and incredibly difficult to debug.

4. Some of us get shit done, not use the ecosystem as a playground for egos and quote frankly incompetent twattery. This stuff can go on in the sidelines and mature independently, not knotted into the next "stable" drop because everything has suddenly been tangled with it.

Its a complete fuck up at all levels and I haven't even started on the technical marvels of introducing something with the complexity of COM into a process model that requires reliability.

This is not how to do software.

Bring on SVG for this sort of stuff.

Plus DoD is several branches so that's a bit of a push.

Actually fuck that. Which is why I'm sitting here on a FreeBSD machine.

The registry is fucking marvellous in comparison.

It's a pretty easy fix. I'd buy a new joystick and replace it yourself though rather than repair the unit. It's possible but I've never taken that assembly to bits. The Tritons are built to be repaired so it's pretty easy to replace the joystick assembly. If it's like the Triton Studio (what I have) or Pro which I suspect it is then it's a case of undoing the large base screws, taking the base off and the joystick assembly can be removed easily with a few screws around the edges. There will probably be a long cable that attaches it straight to the motherboard and that's it. Careful with the cable when putting it back as they can get trapped and sheared if you don't route them properly.

You can get the parts from ebay usually but you might have to wait a bit for one to appear. Either that or Korg can send you parts out from their service center. They're pretty good, reasonably priced and have bits going back to the 1980s in stock!

Overview here on how to disassemble (should be the same): http://www.bustedgear.com/repair_Korg_triton-pro_disassembly...

This is called "emacs fingers" in the office...

More seriously I do most of my work on paper with a pencil.

Stripped it down and sold the keybed and chassis parts on ebay and made enough to buy a Korg Triton so I was happy.

Been trying to build a canned mail server for a few years so this is probably a nice solution if I can get my head around it.

1. Docker appears to only allow a single entry point per container. What do I do if I want to run a container consisting of say postfix and dovecot together? If this is possible can someone please point me at it.

2. Go doesn't allow you to bundle resources with the executables (as say Java/C#) so you have to rely on 3rd party libraries to do this that aren't very good. I can't easily ship my templates with my web server for example as part of the "go build" process. Again if I'm wrong, please point me at a solution.

30kloc of COM/IDL as well that is. The actual routing engine was about 12kloc and the rest was the object model and deserializers. The routing engine was built on a two week binge of Red Bull, TAOCP and some papers printed out.

It really wasn't rocket science even though we charged them like it was.

From scratch by a non red bull enhanced team using c# instead it would probably about 3 months' work for two people to reproduce.

It was (bar the web front end) a relatively modest sub-30kloc chunk of C++.

Now the scale is different but in 10 years, the problem isn't necessarily much more complicated, just larger.

In fact I think a derivative of it now runs some of Yodel's operations.

Conversely, got a taxi from Angel to Leyton and the idiot went via Poplar and the A13 and the journey cost me £55 for a £30 journey.

I did a few years in taxis but owning a car that is CC exempt is cheaper including parking in NCP holes. Part of the reason its cheaper is after some experience driving around the city, you realise that at least half the taxi drivers are taking the piss.

"the knowledge" is imminently replaceable by technology and is merely a party trick IMHO.

My total computing outlay this year is £70 so far. That's £52 for the Samsung SSD (840 Evo) which was new, some rubber feet and a couple of keytops for an X201 I intercepted on the way to the recyclers and £8 for a wireless mouse.

So for that, I got an industrial grade laptop with an i5 CPU, 4Gb of RAM and a 120Gb SSD...

That's less than a Pi with a suitable monitor/TV to attach to it.

(I haven't included the MSDN account copy of Windows 8.1 Pro because I didn't pay for that ;-)

The company I currently work for have to full racks in two data centres each, most of which is near idle and it's a full time job for 2 people. Could do away with all the machines and all the associated administrative staff, just use a devops team and shave 40% of capex and opex as well by moving to something else.

But then again, they might not be getting nice lunches with HP and the DC vendor.

At best this is monitoring and playing whack-a-mole on their part which they've done a pretty good job of by the looks.

As someone who has dealt with NServiceBus, AppFabric, Windows Workflow, BizTalk and various IBM and Tibco piles of randomness etc, I have one word: nope.

The three phases of ESB are:

1. Optimism and ease of use. Much like your blog tutorial in rails, it lures you in and makes it look easy.

2. Then there's the deployment phase, where you realise it actually hurts. This happens the second deployment when contracts are updated etc and you enter contract versioning hell. There are contracts however loose your API says it is.

3. Paralysis. No one wants to change the messaging layer because the cost of doing so is unadulterated pain and friction, so everyone works around it.

This is all "in my experience" but that is perhaps unfortunately vast (several companies) and negative.

An alternative: I don't think there is one for large systems but don't get your hopes up until you've been using something for a couple of years.