30 ounces of silver... pah. I bought a shotgun and lots of ammo. In the situation you describe, I won't be buying anything off you ;-)

The one thing that *nobody* says on their deathbed is "I wish I'd spent more time at work".

Well, my take on it is that agile is not actually Agile.

ie, all the rubbish people do to pretend they're working in an agile way is just an excuse to do far less work and far more process. Just the opposite of what Agile is all about.

Alistair Cockburn said it in his Shu Ha Ri page - agile is about Put 4-6 people in a room with workstations and whiteboards and access to the users. Have them deliver running, tested software to the users every one or two months, and otherwise leave them alone

It is not about daily meetings, more meetings, more review meetings, postits in place of documentation, more meetings to discuss what postts to put in the meeting you're going to have the next day to confirm the postits you decided would be in the next planning process...

I think I should start a new agile methodology - the bugtracker agile system.

You have a bug tracker (where bug also means task, requirement, change or just plain bug) with as many bugs in it as you can think of to get the project going (should be easy - you know what you want after all). Then you tell your dev team - here's the bug list, get on with it. I'll be back in a month to see how you're getting on, you'd better have something to show me - tech docs at least if not some form of running product. If you have any questions, ask Dave the customer liaison chap (or tech architect fellow, or product owner bloke), he'll clarify any confusion in the requirements.

And that's it. Trouble is, I doubt I'd be able to sell many books or conferences with that. Pity, 'cos it works.

What has all that got to do with how one compiler (or script engine) can link or call methods in a binary produced by a different compiler?

If you just mandated a standard name mangling you'd be 80% of the way there - the remaining bits are types, and typically you're not going to get far unless you define a subset of all possible types, probably using C types with struct and class layouts defined.

Nobody is suggesting we compile a binary for one platform and be able to run it on another - no x86 PE is going to be usable on a x86 ELF for example.

Anyway: some reading for you

yep, I love StringBuilder classes too.

Managed languages are dying - since Microsoft decided to AOT compile them and migrate the entire .NET framework to native code (yes, it still looks the same, but all those functions you call in it are native now, or soon will be for the WinRT API that comes with Windows 10)

Just read the hype from Microsoft about how much faster and generally wonderful their latest native .NET is, ... you'd almost think they were lying when they told us how wonderful the old managed version was!

Mind you, the ABI they have now in WinRT is based on COM!

the problem there is that if you link your C++ binary with, say, a python application, it will not be able to use things like std::shared_ptr anyway.

In these cases, the boundary should be defined to some limited standard, in much the same way a webserver REST API is defined (ie as a firm boundary between 2 heterogenous systems)

So while a standardised ABI would be awesome, it wouldn't be able to support everything for every language. At least it'd allow us to compile C++ binaries without 'extern C', and link C++ binaries regardless of the compiler used to generate them. Just those 2 would be sufficient improvements to warrant it IMHO. Stroustrup disagrees unfortunately.

Absolutely. If there was a secure framework for network-connected IoT devices with documented measures to implement the administration or user management, then we'd get secure devices. Without it, we will have servers listening on port 80 to anyone who wants access.

It'll need a fancy logo like DLNA has, and some form of certification so manufacturers know they must use it in order to get customer acceptance, and that gets you into the world of standards bodies and all the politics that goes with it. Still, an OSS framework for IoT networking still seems a great idea, even if it means its easier to implement networking functionality for these devices, with security as an added bonus for the manufacturer.

You misunderstand the problem.

With Smart TVs recording your watching habits in order to send you adverts, there is the potential for someone else to get access to it and record everything else about you.

One day you'll get a link to a website that shows you and your babysitter 'earning an extra bonus' with a payment demand to have it removed - all of which was recorded by your smart TV but sent to a Russian hacker rather than Samsung.

Possibly - but then the best way is just to let any password open the vault.

You cannot crack a password DB if every attempt to open it succeeds. If your means of validating the password you used is to read a stored password, close the vault, reopen it and re-read the password to ensure its still the same.. then you've just added one heap of time to your cracking attack.

Of course, a password vault could return the same set of fake passwords if you failed to supply the correct key (ie when you store a new password, the system generates a fake to store alongside it and returns the correct, or fake one depending on correct unlocking)

No need to re-gen when the vault has been opened incorrectly, just return the bad passwords and let the attacker try to use them. What's even worse than having to re-open your vault to check the passwords are the same, is having to take one of those passwords and use it to attempt login to a 3rd party site to validate whether they were the correct passwords or not!!

If you really want to be a bitch to attackers, you'll expose a few valid entries to honeypots (with passwords that work) so the attacker may think he's got the correct unlock :-)

Oh god... life imitating art. I *was* joking as that's such a stupid, brain-dead behaviour.

How else do you diagnose what caused your server to reboot if.. oh I despair.

I thought it was a close call on init systems (and to be fair, systemd isn't exactly the mature, rock-solid solution a replacement init should be!)

The votes for a replacement on the Debian list should have gone with Upstart IMHO as it was the most popular option, although only 1st choice for 2 of the people who mattered.

Still, it doesn't really matter now - what does matter is that the init system is rock-solid, has buy-in from the customer base (ie the community who use Linux, including server admins) and doesn't require too much re-training to understand and administer it. I'm not sure it has any of those 3 currently.

To be fair, Linux has always been multiple components that you can chose which one suits you best - whether its vi or emacs, gnome or kde, sendmail or postfix, apache or nginx, etc

This is a good thing, where you can swap out component A for B for any reason, and keeps the project competing with each other to get better and better.

If only you could swap out Systemd so easily, things would be great.

a system like this never stores /etc or /var on persistent storage

including /var/log?? Well, I suppose that's one way to hide the fact that systemd's logs get corrupted.

Not quite - more likely 2015 will be year of FreeBSD on the server instead.

it's a rare thing for a business to admit that they were wrong

not really, they were wrong a lot and said nothing, it was only when they had a profit warning that they were forced to say what had happened and this made them admit their fault.

If sales had held up even slightly, you would only have heard how great DRM was.