January 12, 2008 at 6:31 pm
Comments posted to this topic are about the item The Weekly Editorial
January 12, 2008 at 9:21 pm
they take pride in what they do, and they don't want to hear they've built a POS when they're doing their best
I've gotta disagree with you there, ol' friend. Have you looked at the crap code in, for example, the system stored procedures? Take a look at the miserable code in, say, sp_SpaceUsed... there's absolutely no pride there... 😉 There's no decent readability formatting. RBAR is very prevelent when a simple set based solution would have worked just fine. They could have easily made it work for one table or all tables but didn't. It's a POS on steroids (or is that hemmoroids?) 😛 I'd fire the ID-TEN-T that wrote that code as well as the boss that allowed it to happen. :w00t:
They need to hear that they've written a POS... if we keep telling them, just maybe they'll start to listen.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 12, 2008 at 9:37 pm
Actually I'd argue that most of that stuff is just left in because it works. It's not anyone working the stored procedures that work and aren't called often.
Though I do agree that they should be told that something is poorly implemented. I don't agree they should be abused or cursed at.
January 12, 2008 at 9:40 pm
I agree that they shouldn't be abuse or cursed at... heh... just quietly fired 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
January 13, 2008 at 11:55 am
I don't think it's wrong to ask to have users submit a reasonable amount of detail so that they can repro a bug. As far as cursing and the rest, clearly that's not fun to deal with or appropriate as an IT professional, but you'd think they'd filter some of that via someone paid to deal with it, pass the stuff worth looking at on to guys who should spend their day doing meaningful change.
It also annoys me that they can't hire a couple more people to work on simple bugs that are just annoying in every day life. SSMS still barks if you try to use newsequentialID() as a default after TWO service packs. I'd bet an intern can fix this in an afternoon.
Software is hard to write and enterprise database software among the hardest. I woulnd't fire anyone for what exists today, they had a budget and timeline just like most businesses, and the start of the art has advanced considerably over the past few years, so Im more tolerant of older code.
January 13, 2008 at 11:57 am
Nothing wrong with Tony or anyone doing the editorial, though Im not sure I want it to be a soapbox for too many things, SQL or no. Would be nice to see at the top who is writing it, to some degree how much I read and how I interpret is based on knowing who wrote it.
I wouldn't mind if you reworked the format of the newsletter either, hard for me to find kind words about it as is.
January 13, 2008 at 3:45 pm
Encrypting With Certificates: The reason for limited data length with asymetric keys
Dear Steve:
RSA-based asymmetric encryption in SQL Server severely limits the length of data packages that can be encrypted (e.g. 52 bytes with a 512-bit key) due to the design of the RSA system -- not the technical limits of asymetric encryption itself. Asymetric encryption offers a convenient way to exchange and use keys within a PKS environment, but computational overhead makes this a bad choice for encrypting the entire data payload. (Symmetric encryption is much faster.)
Here's a good summary from XML Security by Blake Dournaee:
[font="Courier New"]"...the RSA operation puts an artificial limit on the length of the data that can be encrypted. For example, if RSA with PKCS#1 padding is used, the upper bound on the number bytes that can be encrypted is k-11, where k is the size of the modulus in bytes. So for a 512-bit RSA key, the largest possible piece of data that can be encrypted with the RSA PKCS#1 key transport algorithmn is 53 bytes (64 - 11). Although the amount of data increases with the key size, this operation is still limiting (for a 2,048-bit key, the largest piece of data that can be encrypted is 245 bytes). The second reason for avoiding direct RSA operations on plaintext is because the operation is horrendously slow compared to analogous symmetric key encryption operations. In short, the key transport is designed to only encrypt symmetric keys and although it can be used for arbitrary plaintext, it should probably be avoided unlesss a special fringe case arises."[/font]
The RSA process within SQL Server follows this model: asymmetric encryption to exchange key values, which are then used to symmetrically encrypt / decrypt the data payload.
I'm sure you are familiar with these details; I hope the info is helpful to your readers.
Mark Hays
January 13, 2008 at 8:26 pm
Mark,
Thanks and I understand the reasons, but it's still something that I never have come across in the SQL Server documentation. I wanted to point it out to be sure that others realize that there's a limitation to using certificates built on the RSA algorithms.
January 14, 2008 at 12:57 am
There seems to be a bad link in the article. The link under "Network Solutions snatching domain names" instead links to an article about online polls.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
January 14, 2008 at 7:32 am
Sorry, Gail. Appears that eWeek messed it up as even Google shows that link.
The story is also here: http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9056778
January 14, 2008 at 8:49 am
Despite what you think about the code quality of [INSERT ANY APPLICATION NAME HERE], the guys and gals working on it are just like you and I. They're working for a living, they take pride in what they do, and they don't want to hear they've built a POS when they're doing their best.
Regardless of what application or piece of software it is, this is great advice in general. I wish more people would take your advice about letting it sit before posting or sending their comments.
January 14, 2008 at 11:21 am
Often being on the receiving end of bug reports, I'd agree about the cursing/foul language/personal attacks. It doesn't engender a desire on the programmer's part to fix the bugs nor does it speed up their efforts. The idea of a screener makes a lot of sense there.
I can understand the frustration, though, as it seems that more Connect entries are closed with "Will not fix" or "future version" or similar responses from MS, especially for bugs that seem annoying in day to day usage. I personally hate having to use the Connect site to give feedback just because it seems that anything I post is ignored or closed. I seem to remember someone posting on bugs in SSIS with MS responding that this is done by design and there are "workarounds" posted in the MSDN forums (which involve writing Script components - not something for the beginning SSIS user). That's the sort of response that a lot of us just don't get - we post a real problem, repro instructions, and then are told that it's by design and here's a link to a hard to use workaround. Ticket closed, end of discussion, thank you for playing.
For my part, I've given up submitting Connect entries unless I find something that flat out breaks something or corrupts data. It's just not worth the hassle of filling out the forms and waiting for the seemingly inevitable response saying that nothing will change, if we get a response at all.
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply