Posts by DanW

I suspect most people here are used to dealing with the majority of projects I've dealt with in my career - 2 weeks to 2 years in scale....

but not many dealt with a sub 1 hour build/test/release cycle :-)

Build (compile etc) took about 13 mins, 40 mins for test, then release

I never managed 24 releases in a day that I recall - 23, yes :-) Failures are expected in test, so 48 mins per test cycle (there were additional components such as digital signing needed for a full build that weren't needed for test to start) meant 30 were possible.

My recent teams dealt with Antivirus definitions as well as AV engine functionality - we dealt with Agile by definition, SCRUM was used as applicable (mainly the daily meeting component :-)) waterfall was how we described AV Engine features that took over 30 days to complete!

Oh - and AV researchers wrote engine features as well as vice versa, and the test systems came into the same group, so perhaps can be called DevOps too ;-)

History: Dr Solomon's, McAfee, Microsoft (Defender)

Take a look at the specs...

For those of you who haven't yet looked, you should take a look at the w3c site for HTML5

I wouldn't recommend actually *reading* it unless you're a masochist or being paid to do so - it's very dense, and absolutely massive!

However... When you think about a spec as large as this one, where different parts of the spec are owned by different people (as it has to be in order to have any sort of realistic timetable) it's not surprising that there are lots of incompatibilities at the moment - it's still not expected to be signed off for another 3 years!

So - if you look at page x of the current spec, you can implement your code so that object A always appears in front of object B - and of course you claim you are HTML 5 compliant!

Unfortunately on page y of the spec it says that object *B* should be the one at the front - so if you're a different vendor you can then claim that *your* browser is compliant!

It's gonna take some time :-)

Virtualisation is the problem... as well as the solution

I would guess that Matt is trying to point out that many end users are *already* using virtualisation on x86 hardware... And this is the problem for Cisco.

If you have a physical box running 10 VMs, all of which are talking to one another - how does Cisco manage to monitor that traffic?

All of this traffic remains inside the one physical server - it never goes out to the "real" network - and admins still need to be able to monitor this traffic - hence they are likely to install a VM from this vendor (or another) given that forcing the VMs to send network traffic "off box" is significantly slower.

This then means that the admins have to have *two* sets of management tools/consoles etc - one for their Cisco, and one for this.

Some smaller shops may then choose to drop Cisco, and just go for a virtualised network stack

If this *is* the case then Cisco either has to a) Create their own VM that works with their existing tools and risk cannibalising some other sales or b) Modify their management tools so it will handle this vendor's stack as well as their own

or c) come up with another business model that I can't think of right now :-)