HA! HA! HA! No, sadly, the code was all written by the same person. The crypto is wrong. Everything from information leaks to incorrect use of keys.
I fixed as much stuff as I could stomach to change when I first started. Now I don't care. Me and the other engineer both have backgrounds in cryptography. But the problem is the UI, crypto, etc. code is all one blob. There is no architecture. You can't draw a picture.
In fact, here are the various subsystems: 01, 02, 03, 04, 05. There is no real signifigance to any of those. 01 through 04 are just random blobs of code. 05 is kind of group stuff. But there is no architecture. You can't draw it out because there isn't one!
The product believes in the security through obscurity concept (hence the subsystem names). In fact, there is one place were we use ROT-3 (not 13) encryption.
Dude, this is the worst job ever, and I think I'm a winner (I just don't want to think about what I've won).
I am an embedded engineer who got a job doing some kind of Microsoft Office encryption thing. This is the worst job I have ever had. Its driving me nuts.
I'll start with management. They have no technical skill and like to be "hands on" in the development process. They never come up with specs and endlessly change things. They request a change to the UI, I do it and the next day they are like "Why did that change?" "Because you told me to change it!" "Change it back!"
The product talks to a server but management can't understand why we need the server for any operation. We can do some things without connectivity, but some things require the server. There has been no end to this argument. They drive me and the other engineer nuts.
It only goes downhill from there. Now lets talk about the code. Okay, it was written by a non-programmer who (thankfully) is in another part of the country. His code is the worst stuff I have ever seen on so many levels. To start with, the identifiers are meaningless drivel, mostly with numbers to indicate successive portions of a long complex operation (e.g. EncryptDocfile, EncryptDocfile2, EncryptDocfile3,....)
Then there is the logic. Its a twisty mess of patch upon patch and boolean flag upon boolean flag. In general, if I spend some time at it we can reduce 100's of lines of code to 5-6 proper lines. And lets not forget about defensive programming... This code takes defensive programming to a new level. You've heard of event-driven programming, right? Well, this is exception-driven programming.
See, in Microsoft C++ you can wrap exception handlers around blocks of code. Bad pointers and the like can be caught. This is useful when writing certain specific classes of code. This code uses exception handlers to fix bugs. So it has 7 years of stuff like "I don't know why this routine throws an exception, so we handle it and try something else."
But if you try and fix the pointer crashes you throw off the event flow which is partially dependant on the pointer corruption!!
Other highlights: You gotta love how the code allocates 3-4 1024 byte buffers on the stack of a routine but then goes out of its way to malloc a 56-byte structure (hard coded size, of course) that is used only for THE LIFE OF THAT FUNCTION as a local variable.
I'm really toning it down. The code is a lot worse than I can ever describe. At the end of the day I feel like I need to take a "shit shower" just to get the stench of the code off me.
Then we have the marketing & sales department which aparently have no clue about what our product is. Because the other engineer and I love going to a meeting where a customer wants to know about feature X. Too bad this is the first we've heard of X.
Every day we have a fresh plate of dicks to eat here with no end to the supply in sight!
Actually, although the law varies from state-to-state; quite a few states define it as a life threatening situation. So even if you shoot somebody in the back, if you they had a weapon you could say you feared they would use it on you as they walked away. This is especially plausable if they weren't running but were walking.
If you carry a CCW, you should know the law for your particular state very well.
Oddly enough, I'm 24,000 ft. from my CO. But I'm on a SLIC, and I spent the better part of a year annoying the telco to put a remote DSLAM shelf in the SLIC. Now everybody on my block has DSL.
Before that, I used to have IDSL; which is basically ISDN without the switching (or "D" channel, I only could get 128Kbps).
Another option might be for you to get a T1 line or frame relay and then offer wireless internet access to your neighbors to help subsidize the cost.
Amusingly enough I can't get any network television where I am. I dunno, every time I watch TV at my girlfriends I realize how much I don't miss it.
Its hard to go without my southpark fix. I do buy them on DVD as they come out. Since the DVD's don't come out nearly as quickly as they do on comedy central I do cheat and download the ep's.
But I don't call it stealing. I am happy to buy them all on DVD. I'm just impatient.
As a male in that age range I've completely given up on TV. In my area I can't get any kind of reception and cable is too expensive for the few channels I would watch (TLC, Discovery, Comedy Central, etc).
Its more cost effective for me to not buy cable; which is about the cost of two uncapped DSL lines both with static IP's in my area. Instead, I buy the occasional DVD when I'm in the mood for a movie.
Another reason is that during the winter when you can actually go outside and not die of heat exhaustion I can sit on my patio with my laptop and wireless and use the net. If I want to watch TV then I'm stuck inside watching it inside.
I think the media companies are going to have to deal with this trend. As much as they would like to turn the Inter-web into a one-way communications medium like TV, its just not going to happen. Thats one of the big draws. I don't have to view your crappy commercials or just be a passive consumer of information.
If nothing else, the blogging fad is a big validator of the fact that people like to speak out in communications as much as absorb (well, most of us).
Why? I don't want to use a Linux desktop. Actually, I prefer to use an OS X desktop. Sometimes we can't. For example, my wireless hardware on my x86 laptop isn't supported by Linux (or the BSD's).
But I don't want to use an office suite that insults my intelligence. And if I could strip off a big chunk of the clown suit in Windows, believe me, I would. The NT kernel with a MacOS 6 look and feel is as fancy as I would care for.;-)
And lets not forget the very important rule that keeping code portable helps keep it bug free. The chances are much higher that a bug will come out the more operating systems/compilers/platforms that chug through your code.
Yup. I migrated my internal server to Apache 2 simply to support Subversion. My external webserver is still 1.3 since a lot of people use it and need funky custom modules going.
I like using Apache as my Subversion server, it works out really well for me. That alone is a reason to move.
Ahhh. How I upgrade you ask? I use rsync to mirror-image my servers root disk to a spare box and then using the Live CD upgrade it there.
I actually rebuilt the failed root disk there with only 15 minutes of downtime (most of that getting the new hard disk and SCSI controller in the squishy case.
But overall, I'm very impressed with the performance those boxes get (I suspect quite a bit of it is due to XFS though).
I've had great luck with
FastColo. The service is good and the bandwidth is great. They also have a good generator setup (my server has never lost power).
My Gentoo machines are servers; so compiling
everything to the exact specs of the machine
gives a performance boost (especially on
non-x86 platforms).
I can turn off any trace of Xwindows. I'm
sure some people like it, but I don't.
I hate X.
I don't want so much as the client libraries
on my box.
The live CD makes recovery and certain
other operations easier since it pretty much
matches the environment of the running
server.
The Gentoo community provides a good amount
of peer review into package selection.
So maybe if you just want a desktop and don't feel like compiling everything for over a week you can use a different distribution. But I've found Gentoo works well for servers.
In particular for busy servers that are co-located behind > 100MBps of bandwidth for database-backed sites: Every clock cycle helps!
Not true at all. Keep in mind that I am talking about hardware failures or power outages here, not ftpd or httpd crashes.
A journalled filesystem does not journal the data (well, some do, read on). A journalled filesystem journals metadata changes (permission bits, file renames, etc). It is entirely possible that the data in those files gets corrupted. In particular, we use the excellent
XFS file system from SGI. Because XFS uses such aggressive caching data can be corrupted during a failure.
Now, some journalled filesystems (e.g. an option in ext3) journal file data as well. This doesn't help but can actually cause *worse* problems as seemingly correct but stale data can be left behind.
The very fact that arch makes no use of the fsync system call on the server side (since it has no dedicated server) means that data loss is much more likely than with Subversion which ensures that data is written first to log files and then replayed into the respository DB.
As for repository size? Is that really an issue that even matters? Unless arch users write gigabytes of source code I don't see the problem here. How much does a couple of SCSI disks and a RAID controller really cost that guarding source code isn't worth it?
What do the arch guys use for a server that this is such an issue? Can you even buy less than 9GB SCSI disks anymore? Is spending $2000 for a decent server really out of line?
Re:completely underwhelmed by Subversion...
on
Subversion 1.0 Released
·
· Score: 3, Informative
Thats an excellent point, there were other things that drove us away from BK, all technical nits. In the end, SVN won out due to things we could make it do.
But as far as the different tree model: we simply do not want this. We don't have any fault tolerance issues. We have some distributed developers but since our code is intimately tied to physical hardware its a moot point for us.
If we don't have network connectivity to our target hardware lab we got bigger problems. But we also don't want people maintaining their own trees and branches.
There are some other things that we liked about SVN. The fact that its supported by a logged DB engine. That was another critical blow for arch to us. If a server went down during the middle of a commit we could have corrupted files. Internally we use XFS which journals metadata but not user data. Its actually silly for a file system to do this since the FS has no clue about where transaction boundaries are.
So if we had say a HW failure with arch we could have a complete tree with some corrupted files. SVN physically logs the data to disk and then fsync()s the logs and then writes them in the database.
But BK is a nice product and I like Larry McVoy, our choice of SVN stemed from many little things.
Yes, we are using it at my company. We switched from CVS around 4 months ago; importing all of our CVS history. We haven't had any problems and we did some major tree re-org after the migration.
We never had a single hung repository that requried svnadmin recover except when the power went out and our generator didn't kick on and the UPS batteries drained. FWIW we do use Apache 2 and DAV for our repository access.
Our primary tree (source code) is around 20MB including all deltified versions (basically our 'strings' table). We also have separate repositories for our corporate website and for internal documents, etc. All totalling we have about 50MB of versioned data -- all of it precious and have never lost a single byte.
Oh, one last thing. We've been using SVN for our non-source tree for a longer time period so we've really been using SVN for almost 7 months now with lots of changes from multiple developers on multiple platforms.
If you like the CVS model of development (non-change-sets) then you'll like SVN. If you want distributed development then try an add-on to SVN called SVK.
Slashdot Mirror
I fixed as much stuff as I could stomach to change when I first started. Now I don't care. Me and the other engineer both have backgrounds in cryptography. But the problem is the UI, crypto, etc. code is all one blob. There is no architecture. You can't draw a picture.
In fact, here are the various subsystems: 01, 02, 03, 04, 05. There is no real signifigance to any of those. 01 through 04 are just random blobs of code. 05 is kind of group stuff. But there is no architecture. You can't draw it out because there isn't one!
The product believes in the security through obscurity concept (hence the subsystem names). In fact, there is one place were we use ROT-3 (not 13) encryption.
Dude, this is the worst job ever, and I think I'm a winner (I just don't want to think about what I've won).
I'll start with management. They have no technical skill and like to be "hands on" in the development process. They never come up with specs and endlessly change things. They request a change to the UI, I do it and the next day they are like "Why did that change?" "Because you told me to change it!" "Change it back!"
The product talks to a server but management can't understand why we need the server for any operation. We can do some things without connectivity, but some things require the server. There has been no end to this argument. They drive me and the other engineer nuts.
It only goes downhill from there. Now lets talk about the code. Okay, it was written by a non-programmer who (thankfully) is in another part of the country. His code is the worst stuff I have ever seen on so many levels. To start with, the identifiers are meaningless drivel, mostly with numbers to indicate successive portions of a long complex operation (e.g. EncryptDocfile, EncryptDocfile2, EncryptDocfile3, ....)
Then there is the logic. Its a twisty mess of patch upon patch and boolean flag upon boolean flag. In general, if I spend some time at it we can reduce 100's of lines of code to 5-6 proper lines. And lets not forget about defensive programming... This code takes defensive programming to a new level. You've heard of event-driven programming, right? Well, this is exception-driven programming.
See, in Microsoft C++ you can wrap exception handlers around blocks of code. Bad pointers and the like can be caught. This is useful when writing certain specific classes of code. This code uses exception handlers to fix bugs. So it has 7 years of stuff like "I don't know why this routine throws an exception, so we handle it and try something else."
But if you try and fix the pointer crashes you throw off the event flow which is partially dependant on the pointer corruption!!
Other highlights: You gotta love how the code allocates 3-4 1024 byte buffers on the stack of a routine but then goes out of its way to malloc a 56-byte structure (hard coded size, of course) that is used only for THE LIFE OF THAT FUNCTION as a local variable.
I'm really toning it down. The code is a lot worse than I can ever describe. At the end of the day I feel like I need to take a "shit shower" just to get the stench of the code off me.
Then we have the marketing & sales department which aparently have no clue about what our product is. Because the other engineer and I love going to a meeting where a customer wants to know about feature X. Too bad this is the first we've heard of X.
Every day we have a fresh plate of dicks to eat here with no end to the supply in sight!
If you carry a CCW, you should know the law for your particular state very well.
Before that, I used to have IDSL; which is basically ISDN without the switching (or "D" channel, I only could get 128Kbps).
Another option might be for you to get a T1 line or frame relay and then offer wireless internet access to your neighbors to help subsidize the cost.
Amusingly enough I can't get any network television where I am. I dunno, every time I watch TV at my girlfriends I realize how much I don't miss it.
But I don't call it stealing. I am happy to buy them all on DVD. I'm just impatient.
Yeah, I want cheesey poofs.
Its more cost effective for me to not buy cable; which is about the cost of two uncapped DSL lines both with static IP's in my area. Instead, I buy the occasional DVD when I'm in the mood for a movie.
Another reason is that during the winter when you can actually go outside and not die of heat exhaustion I can sit on my patio with my laptop and wireless and use the net. If I want to watch TV then I'm stuck inside watching it inside.
I think the media companies are going to have to deal with this trend. As much as they would like to turn the Inter-web into a one-way communications medium like TV, its just not going to happen. Thats one of the big draws. I don't have to view your crappy commercials or just be a passive consumer of information.
If nothing else, the blogging fad is a big validator of the fact that people like to speak out in communications as much as absorb (well, most of us).
Maybe AT&T should try and manage to keep a voice call up without dropping it, lets cover the basics first.
But I don't want to use an office suite that insults my intelligence. And if I could strip off a big chunk of the clown suit in Windows, believe me, I would. The NT kernel with a MacOS 6 look and feel is as fancy as I would care for. ;-)
And lets not forget the very important rule that keeping code portable helps keep it bug free. The chances are much higher that a bug will come out the more operating systems/compilers/platforms that chug through your code.
I'm worried about when ReactOS pops up on their radar. Its a pretty promising project.
I like using Apache as my Subversion server, it works out really well for me. That alone is a reason to move.
This doesn't seem limiting. That was my approach while growing up but I get along quite normally now as I've gotten older.
Even though I have a girlfriend sometimes I find myself doing unwanted cable pulling. Hehe.
The next 30 minutes there is going to be alot of "cable pulling" if you know what I mean.
I actually rebuilt the failed root disk there with only 15 minutes of downtime (most of that getting the new hard disk and SCSI controller in the squishy case.
But overall, I'm very impressed with the performance those boxes get (I suspect quite a bit of it is due to XFS though).
I've had great luck with FastColo. The service is good and the bandwidth is great. They also have a good generator setup (my server has never lost power).
So maybe if you just want a desktop and don't feel like compiling everything for over a week you can use a different distribution. But I've found Gentoo works well for servers.
In particular for busy servers that are co-located behind > 100MBps of bandwidth for database-backed sites: Every clock cycle helps!
Just kidding...
No, my boss has a single pubic hair for his brain.
With my luck they will all get the memo.
My hair-brain bosses cause me great stress. Guns and Knives are an important technological development for dealing with the idiot problem at work.
Ahhh how I miss the good old days when corrupt business men purchased a different kind of hummer with corporate money.
A journalled filesystem does not journal the data (well, some do, read on). A journalled filesystem journals metadata changes (permission bits, file renames, etc). It is entirely possible that the data in those files gets corrupted. In particular, we use the excellent XFS file system from SGI. Because XFS uses such aggressive caching data can be corrupted during a failure.
Now, some journalled filesystems (e.g. an option in ext3) journal file data as well. This doesn't help but can actually cause *worse* problems as seemingly correct but stale data can be left behind.
The very fact that arch makes no use of the fsync system call on the server side (since it has no dedicated server) means that data loss is much more likely than with Subversion which ensures that data is written first to log files and then replayed into the respository DB.
As for repository size? Is that really an issue that even matters? Unless arch users write gigabytes of source code I don't see the problem here. How much does a couple of SCSI disks and a RAID controller really cost that guarding source code isn't worth it?
What do the arch guys use for a server that this is such an issue? Can you even buy less than 9GB SCSI disks anymore? Is spending $2000 for a decent server really out of line?
But as far as the different tree model: we simply do not want this. We don't have any fault tolerance issues. We have some distributed developers but since our code is intimately tied to physical hardware its a moot point for us.
If we don't have network connectivity to our target hardware lab we got bigger problems. But we also don't want people maintaining their own trees and branches.
There are some other things that we liked about SVN. The fact that its supported by a logged DB engine. That was another critical blow for arch to us. If a server went down during the middle of a commit we could have corrupted files. Internally we use XFS which journals metadata but not user data. Its actually silly for a file system to do this since the FS has no clue about where transaction boundaries are.
So if we had say a HW failure with arch we could have a complete tree with some corrupted files. SVN physically logs the data to disk and then fsync()s the logs and then writes them in the database.
But BK is a nice product and I like Larry McVoy, our choice of SVN stemed from many little things.
This could be done and would be really great. Ohh, lets see what foo.c looked like yesterday:
cat foo.c@@yesterday
We never had a single hung repository that requried svnadmin recover except when the power went out and our generator didn't kick on and the UPS batteries drained. FWIW we do use Apache 2 and DAV for our repository access.
Our primary tree (source code) is around 20MB including all deltified versions (basically our 'strings' table). We also have separate repositories for our corporate website and for internal documents, etc. All totalling we have about 50MB of versioned data -- all of it precious and have never lost a single byte.
Oh, one last thing. We've been using SVN for our non-source tree for a longer time period so we've really been using SVN for almost 7 months now with lots of changes from multiple developers on multiple platforms.
If you like the CVS model of development (non-change-sets) then you'll like SVN. If you want distributed development then try an add-on to SVN called SVK.