Introduction to Docker

Scheduled: Feb 1, 2014, 14:00:00 to 14:30:00

Location: H.1309 (Van Rijn)

Linux tracing with LTTng

Scheduled: Feb 1, 2014, 13:00:00 to 13:30:00

Location: Janson

wolfSSL 2013 Technical and Community Update

Scheduled: Feb 1, 2014, 17:30:00 to 17:59:00

Location: UB2.252A (Lameere)

Foreman Project

Scheduled: Feb 1, 2014, 16:30:00 to 16:55:00

Location: UD2.120 (Chavanne)

SaltStack: 

Scheduled: Feb 1, 2014, 15:00:00 to 15:30:00

Location: H.1309 (Van Rijn)

Razor – Provision like a Boss

Scheduled: Feb 1, 2014, 15:30:00 to 15:55:00

Location: H.1309 (Van Rijn)

Sharding and Scale-out using MySQL Fabric

Scheduled: Feb 1, 2014, 16:00:00 to 16:15:00

Location:  UA2.114 (Baudoux)

NixOS: declarative configuration

Scheduled: Feb 1, 2014, 18:00:00 to 18:25:00

Location:  H.1309 (Van Rijn)

MaxScale, the Pluggable Router

Scheduled: Feb 1, 2014, 18:35:00 to 19:05:00

Location: UA2.114 (Baudoux)

Sunday

Adventures with CloudStack and OpenDaylight

Scheduled: Feb 2, 2014, 13:00:00 to 13:45:00

Location: UD2.120 (Chavanne)

Combining the power of Valgrind and GDB

Scheduled: Feb 2, 2014, 15:30:00 to 16:00:00

Location:  K.4.201

See Your Project Pulse in Real-Time with Fedmsg

Scheduled: Feb 2, 2014, 14:00:00 to 14:45:00

Location: H.1302 (Depage)

PicoTCP

Scheduled: Feb 2, 2014, 13:30:00 to 13:55:00

Location: AW1.121

Helgrind: a constraint-based data race detector

Scheduled: Feb 2, 2014, 13:00:00 to 13:50:00

Location: K.4.201

GDB, so where are we now?

Scheduled: Feb 2, 2014, 15:00:00 to 15:25:00

Location: K.4.201

Ganeti: the New&Arcane

Scheduled: Feb 2, 2014, 11:00:00 to 11:40:00

Location: UD2.120 (Chavanne)

XMPP in the world of IoT

Scheduled: Feb 2, 2014, 12:00:00 to 12:30:00

Location: AW1.121

BoF: Valgrind and GDB integration

Scheduled: Feb 2, 2014, 16:00:00 to 16:30:00

Location: K.4.201

NSA operation ORCHESTRA: Annual Status Report

Scheduled: Feb 2, 2014, 17:00:00 to 17:45:00

Location: Keynote

MirageOS: compiling functional library operating systems

Scheduled: Feb 2, 2014, 13:00:00 to 13:50:00

Location: Janson

Reviewers often seek to find one improvement area because otherwise they feel like they didn’t give any feedback to the person being reviewed. This always backfires because people hear criticism more acutely then they hear praise.

My goal as a manager is to give feedback throughout the year. I use the review as an opportunity to ask the person about how they are doing against the goals and feedback I have been giving. If I hear them talk about the items I have brought up with them then I know that I am communicating well.

If I don’t? Then I need to try harder.

I use the review as a means for providing myself feedback on how I am communicating.

What else have I observed about the review process over the years?

The one thing everyone wants to know during a review?  “Am I going to be terminated?” Even top performers have this in the back of their minds. The reason for this is that the top performers are often perfectionists so they see the warts in their work.

The second thing employees want to know?  “What am I getting for a raise?”

If you can’t give an answer on number 2 then don’t bother doing the review since it makes people think about “am I being fired” during the lead up time to the review. 

According to the documentation I should be able to type:

copy usb://filename image1

I get an error with “schema not supported”. My switch is loaded with 8.1.36.

What is up?

Thanks!

Hi Netgear!

The GSM7248v2 has never had well working firmware (just google and you will find many issues, in particular the DHCP just flat out doesn’t seem to work). You now have a M4100-50G which appears to be identical hardware but with a newer firmware. When will you release that firmware for your existing GSM7248 customers?

Thanks,

-Brian

• Added gearman_task_is_finished()
• Improved SSL support.
• Exceptions are now supported.
• gearmand excepts its root CA via the environmental variable GEARMAND_PORT. 
• libgearman will now except GEARMAND_CA_CERTIFICATE, GEARMAN_CLIENT_PEM, and GEARMAN_CLIENT_KEY

http://launchpad.net/gearmand

From the feedback I am getting the SSL appears to be working.  If you are interested in learning about how the SSL works, you can find out more about it on the docs website.

I am curious to see how many people get tripped up over the fact that an SSL setup requires that you not use self signed certificates (I may support these later, but I wanted to get it right in the beginning).

Unless something major comes up the next version will be a release candidate and the version after will be the formal release

I do not believe anyone should be surprised by the results. MySQL became less interesting once it was acquired, and the number of Postgres deployments is greater than what all of the NoSQL market combined adds up to. When looking at emerging technologies, press time given to a single software product has no relation to what its actual market share is (which isn’t as obvious as one might think to everyone).

When I get asked what my current opinion about NoSQL vs SQL is, I say that I continue to see NoSQL as a spotlight highlighting the failures in the design of the current relational database software vendors(*). Which should not damn the concept of the relational database, but somehow it happens anyways.

The two biggest issues that stand out to me are that current leading relational databases never solved scale out very well, and online operations are too expensive.

Would a document model really matter if schemas could be altered online? You would still have the weak vs strongly typed arguments that can exist in schema/table design, but if the operation to add additional characteristics to a table (object) was online or automatic I believe a lot of the arguments you see for schema less design would go away.

The other giant failure was that the vendors didn’t approach scale out as a strong requirement for future designs. Going back a few years you can see where the vendors would talk about shared nothing designs, but only in the scope of support handful of nodes in a cluster. A hundred or so at best, which is small potatoes for where some of the NoSQL vendors who focus on scale out shoot for.

Its funny to think about how much has been written on this topic that has focused on the SQL language, when no new language has emerged from the NoSQL market that has any size-able adoption. At this point most of the NoSQL vendors now talk about how they have, or are, adding a SQL interface to their products.

The innovation hasn’t been in the language, but in the design of database engines themselves.

The other bit of humor in this, is that if you take apart how most of the major vendors have implemented their storage engines, you would find that in the inner design few are strongly typed, and few track relationships in the core of their design. Most of the major vendors could do more operational changes online if they were willing to put reasonable scoping on what can be altered. The Innodb row format is inflexible, but the addition of some version information and a catalog documenting the versions would fix that.

To sum this up, the need to preserve backwards compatibility is what has kept the relational database vendors from solving the needs that caused the NoSQL solutions to come to market. I don’t see any of them tackling this anytime soon; the margins on their current products doesn’t dictate the need for them to do this.

A final thought about the state of the current nosql databases.

One of the “hard things” that almost(?) none of the current NoSQL vendors has tackled is the JOIN, i.e. the fundamental feature which is required to do anything beyond simple key/pair or basic search. Join optimizers are hard to write(*).  Network aware join optimizers are particularly difficult to write mainly because direct attached storage, AKA a hard drive, is a lot more reliable on a second to second basis than the network.

*) I also get asked which one I would pick if I had to pick one. Currently I suggest Cassandra, though more often then not a table with a key and a blob would work as well.

*) One of the nice things about MySQL’s design was that someone designing a new engine could focus on the datastore and punt on the rest (well, sort of,… the pluggable storage engine interface never matured to the point of really playing nicely with other people’s designs).

|| ==881== Syscall param sendmsg(mmsg[0].msg_hdr) points to uninitialised byte(s)

|| ==881==    at 0x386BAF3D6B: sendmmsg (sendmmsg.c:36)

|| ==881==    by 0x386DE0B4D6: __libc_res_nsend (res_send.c:1132)

|| ==881==    by 0x386DE08BDF: __libc_res_nquery (res_query.c:226)

|| ==881==    by 0x386DE097B9: __libc_res_nsearch (res_query.c:582)

|| ==881==    by 0x5E8CAC7: _nss_dns_gethostbyname4_r (dns-host.c:309)

|| ==881==    by 0x386BAD9AF1: gaih_inet (getaddrinfo.c:845)

|| ==881==    by 0x386BADD750: getaddrinfo (getaddrinfo.c:2359)

If you really want to be right, and not cost a lot of other people time when you know you are right and valgrind is wrong. You could leave a snarky comment in the code where you create a fix to silence the valgrind error.

Or you could decide to not fix the warning, and cost a lot of other developers their time as they trip over you academically correct code which spews errors when run through valgrind.