Give it a rest. Yes, he could have said "Once I had kids, my views...." instead of "Once you have kids, you view ". But what he's saying, in my experience, is mostly true, if not always true for everyone.

Once people have kids, their views on many things do tend to change. You tend to become more protective, and see issues more in terms of how they affect the child, rather than how they directly affect you. It happened to everyone I know. It happened to me.

I guess you're different. Or you don't have children.

As a user of pretty much every single Microsoft operating system, from before Windows, and a reasonably long-term Linux user on the desktop (since 2002), I can quite confidently state that the user friendliness of any of these systems is not the reason for their market dominance, or lack thereof.

Once you get past basic learning curves, these days both Linux and Windows are pretty much equivalent in user friendliness. I find Linux marginally more usable and a calmer experience overall, but that's just me. There's not a lot to choose between them in all honesty. I will qualify that slightly, in that I find Windows 8 quite hideous as a user experience - it's been my main work desktop for about 3 months now. Normally it doesn't take me that long to find out what's good in a new system.

Market dominance is achieved through network effects and lock-in. Displacing WIndows on the desktop is a forlorn hope without some kind of game-changer. Linux has been successful where those effects have not been in force, and a solution can compete on its own merits. To be sure, those things have happened with the backing of a large company - but rarely (if ever?) has an open source offering led a new market without commercial backing.

Did you miss the requirement that every UEFI BIOS must be able to disable Secure Boot if it has it?

Look, I dislike Microsoft's general business practices, and some of their software is worthy of derision. We should definitely keep an eye on this sort of thing. But (a) this article has nothing to do with Secure Boot and (b) you can easily run Linux or other operating systems on any computer with Windows 8. Either disable Secure Boot, install your own certificates, or use a boot loader signed by someone for whom your firmware already has the certificate.

Amusingly, I just bought a Samsung notebook with Windows 8 and Secure Boot. Doesn't seem to be affected by this bug. However, I couldn't make both Windows 8 and Ubuntu 12.10 boot with Secure Boot enabled. After a lot of mucking about, I can boot Ubuntu fine using Secure Boot, but so far I can't chainload Windows 8 for some reason from grub. So I've had to disable SecureBoot, so I can run Windows 8!

Yes, exactly. I've been using Windows 8 for about a month now. The experience is jarring, with frequent context switches and poor discoverability. I have so far resisted installing one of the start menu replacements, as I really want to give it a try. Maybe there is something to it, but so far it's just additional cognitive load with no actual benefits.

I'm quite prepared to try new things. I hated Ubuntu Unity when I first interacted with it, but I gave it a determined try. Two weeks later, I decided I really quite liked it, and now I actually prefer it to traditional desktops. It's calm, and what I'm working on is the focus, not the operating system. Windows 8 is almost the exact opposite experience.

Soooo.... you're a kernel developer too?

Well, then he needs to understand your code base a bit better, and gain some experience of coding with other people.

You could schedule an in-depth code review of the main components of the system with him. You get to explain the what and why of the existing code, and he gets to explain what he thinks could be better. This isn't something to do in an hour - schedule at least half a day for this, or even more if you think it will be worthwhile.

He may have some good ideas - but he probably doesn't have the experience to understand why some ugly bits of the code aren't worth changing, or why rewriting everything isn't usually the best policy.

You could also get him to walk you through some code he has written (maybe open source?) which exhibits what he sees as good coding.

The main thing in a coding review is to get people to explain what the defects and behaviours they see in the code are, without reference to style or that it's simply not how you would have written it. I've often found that the "why" of things is often missing in code. Sometimes the outcome of a code review is simply to add a few more comments explaining the why, rather than the what, so others benefit in future too.

Follow this simple rule: don't invent your own crypto. And that goes double for protocols. It's hard. I mean, really, really hard to get it right. If you are not an expert, then there are almost certainly known attacks which will undermine the security of your entire system. If you are an expert, there are still probably subtle attacks (but fewer of them which may not be discovered for years).

I understand most standard modern crypto and protocols quite well. I have studied and worked with it long enough to recognise that using tried and tested methods is almost always the right thing to do. I am not an expert, but I am hopefully a reasonable practitioner.

With that disclaimer out of the way, you need to identify what security you are trying to achieve first, before tacking on cryptographic primitives left right and center. You seem to want message confidentiality and message authentication. For confidentiality with message authentication, use standard constructions. Preferably use an authenticated encryption mode, which has the advantage that they can take less message space than the old style encrypt-then-HMAC constructions, and are usually faster than doing either separately. And you typically only need a single key. If you use the encrypt-then-MAC construction, don't use the same key for encryption as you do for MACing.

Does confidentiality extend to the attacker knowing whether he has seen the same encrypted plaintext before? I.e. should the same plaintext always encrypt to a different ciphertext, or are you happy for the same ciphertext to always be produced for the same plaintext? Do you care about replay attacks? What happens if an attacker replays an old message? Message counters or timestamps can help here. What about non-repudiation? Does it matter whether you can prove which side generated the message or not? For payments, this might be important.

This only scratches the surface. Get proper advice to analyse the true security requirements of your protocol, and use standardised constructions in the implementation. Use BLAKE by all means if it fits the security you need to achieve and performance is a primary requirement. But figure out what security you need first.

Maybe I'm not understanding something here. You don't say that saw the strategic need for this project and developed the idea from the ground up. So I'm assuming you were asked to produce some tech specs for an idea which wasn't originally yours. I don't doubt that developing the specs involved a high degree of skill and ingenuity from you.

Now your boss deems your work to be sufficiently successful to allocate serious resources to it. I'm getting that you feel a very strong sense of technical ownership about this project, but I don't understand why you thought you would lead the entire thing. Is your boss behaving differently to the way the rest of this large, hierarchical company functions?

Having said all of that, congratulations on producing something that clearly has a lot of potential! I echo what other posters have said about not going around management. Talk to your boss in a constructive manner and find out where he sees you fitting in this expanded project. You may or may not like what he says, but at least you'll know where you stand, with your currently great technical reputation intact, and possibly an enhanced reputation for softer skills.

Thus speaks someone who has clearly never used Latex.

In Latex, you focus on writing the text, with minimal tags for things like chapter and sections headings. You typically do very no to very little explicit formatting. The latex system does the typesetting for you, producing professional output in whatever styles you have defined.

In fact, this was an aspect of it I actually found occasionally frustrating. It would move diagrams and figures to different pages to produce output it thought would be best. Sometimes I really wanted a diagram on the same page as the text which talked about it - but you often don't get that kind of control in Latex. It does the work for you, and generally produces very good results.

Well, I've spent the majority of my career doing greenfield projects, so I haven't really seen the kind of coding shop you're talking about. I would have (possibly naively) thought that letting really incompetent programmers work on critical systems is more of a management failure rather than the result of better tools.

My personal style uses a lot of refactoring, particularly the names of things in the early stages. I'm not averse to using good tools outside the IDE too, although I generally prefer to integrate them if possible. As far as I'm concerned, if an automatic tool can do something faster and more reliably than I can, then by all means let the tool do it. It frees me up to focus on the more interesting problems. But each to his own...

I do like what you said about frameworks and libraries, particularly "Frameworks are there to use you!" - that made me smile :)

I have to say, I'm not one of those who think that making programming easier is making programming worse.

I've been programming for over 30 years (first experience being with hex keypads, teletype terminals and batch processing systems back in the 70s!). I love refactoring support, debugging, in-line help, static analysis, code navigation and folding, documentation generation, etc. They make me much, much, more productive. Anyone who thinks using a text editor, command line or punch-cards is superior is welcome to them, but in my opinion they're crazy!

There may be people for whom all this handholding allows them to write poor software, when they couldn't have done it at all without that level of support. It may also be the case that it allows unmotivated developers to plateau in their abilities too early - although if they're that unmotivated I'm not sure how good they would ever have been.

I'm kind of with you on frameworks though, particularly in Java land. I tend to find that frameworks get me 70% of the way with about 30% of the effort. Win! The next 20% takes me 60% of the effort, just breaking even as I struggle to make it do what I need. Wrestling with incomplete documentation, lesser used functionality and mysterious error messages for which a single plaintive post can be found in the blogosphere somewhere, to which there are no replies ;)

I often wish I'd just ignored the entire framework and built the damn thing myself. But maybe I'm not building typical systems, or something. I guess if you're doing bread-and-butter work where lots of other people are doing essentially the same thing, they may work out better.

There seems to be some truth to this, in my own experience. I find the solutions my younger colleagues invent are just too complicated and gnarly. They haven't yet found how to see the underlying simplicity in the problem and solution - and more importantly, they don't even understand that they should be doing that.

Mentoring is very satisfying, particularly when someone has a "got-it" moment, and their code improves forever thereafter. But I find that is rare. Many people I've worked with - even really, really bright people - just aren't interested in seeing a bigger picture. In fact, I'd go further. Most people will never do this - they will just solve the problem immediately in front of them, without any regard for how the whole thing hangs together, or the semantics of their construction, or the future ease of maintenance of their code.

I guess what I'm saying is that I'm not sure it's really about inexperience, or hardness of career. It's the difference between being a journeyman or a master, and very few it seems have a genuine desire of mastery in what they do.

You are talking about sousveillance, rather than surveillance:

http://en.wikipedia.org/wiki/Sousveillance

I haven't read the book, but I studied cryptography under Professor Keith Martin at RHUL. He was never anything but encouraging of my attempts to design cryptographic protocols. On one occasion I was trying to invent a new symmetric key exchange protocol, reducing the trust required in the trusted third party. He gave me some good pointers, but did observe that the protocol required in the assignment was, by definition, supposed to be a *trusted* third party protocol. Nevertheless, he allowed me to work some of the ideas out a bit more. It was a lot of fun (but a terrible protocol!).

Anyway, I must get a copy of this book. It it's anything at all like his teaching it will be money well spent.

I meant to reply to the parent, obviously :)