Re:completely underwhelmed by Subversion...
on
Subversion 1.0 Released
·
· Score: 5, Interesting
First off I use Subversion on a large, non-open source project. It works great; my server is a crappy PowerMac and it still handles commits from the staff with no problems as well as checkouts to the various build machines here.
Before we migrated to Subversion we were using CVS. In choosing a replacement for CVSs' limitations we first evaluated arch.
In our opinion arch is junk. It works only on UNIX like systems (we have lots of systems that are not UNIX-like here, and we do use Win32 for some stuff).
Converting CVS with history looked to be impossible and we found arch very annoying to use.
The distributed tree model is also another problem. I'm sure that for Linux kernel development, arch makes sense. For a commercial product we do not want multiple trees. We want one consistent tree so when we go to a customer site we don't have to wonder why a circuit is malfunctioning because we didn't sync up with Jack's tree or whatever. We rejected BitKeeper on the same grounds; we weren't so much against paying but wanted something with the right feature set.
ClearCase wasn't cross-platform enough and was really more expensive than we could afford and MetaCVS seemed sluggish.
As a matter of personal opinion (mod me down if you want); we felt that (in the lab) arch felt like a toy and Subversion felt like a polished product.
Because they wanted me back under contract. I had my TDMA phone for four years and although I had no long distance I had totally unlimited nights and weekends as well as unlimited analog (I used to dial up using my cell phone).
The sales people at the AT&T store were very pushy and if I had a TDMA phone with the right firmware I would have told them to go fuck themselves.
And the biggest pisser? They don't even terminate GSM data calls to a modem bank. Dicks. Total AT&T dicks.
Could they possibly give me worse service now that AT&T is owned by Cingular?
I used to have AT&T when it was TDMA and it worked wherever I took my phone: camping, hunting, the office. Then my old TDMA phone gave up the ghost and they basically told me I had to get a GSM phone.
Their GSM service is pathetic. The phone doesn't work at my house, doesn't work in the office, drops calls all around the city and I get zero signal strength when in the woods (where my TDMA phone would go!).
I was going to cancel my AT&T service the moment the contract was up but I wonder if Cingular will improve things. Its just insane how bad this phone works.
I gotta find a new carrier. T-Mobile looks good. I don't so much mind GSM as much as I mind AT&T's lack of towers and capacity.
Ugh. I work on a hungarian piece of shit code every day. The original author had no discipline and the names are now meaningless since the types have changed. Oh, and he was inconsistent to begin with.
It has to be compiled on a compiler with SEH (Structured Exception Handling). For the most part (the kernel) is portable C. In theory the SEH stuff can probably be implemented as macros.
Because I'm into kernel architecture. I wouldn't mind a peek... but man am I scared to do it just for the legal reasons (I've seen portions of the code for NT at an employer); but the whole thing would be interesting.
Alas, NTFS is the one area I would like to see and it doesn't look like its there.
NT runs on lots of platforms. The very first was actually the i860 on an internal computer built at Microsoft called Dazzle by Rob Short. After they realized that the i860 was a crummy chip (it was) they switched to MIPS.
So the MIPS architecture was the second architecture that NT supported. Then i386, then Alpha, then PPC, and then amd64/ia64. Portability was fairly high on the list of priorities for NT.
Honestly I would love to have a peek at the code just to satisfy curiosity. But I have a feeling anybody who has it is gonna be severely punished. Sigh.
Or you could just buy the NTFS internals book by Helen Custer. I'm not quite sure what part of NTFS (well, pre-NTFS v5 since there isn't a good book on v5) is so secretive?
And, FWIW, NTFS is pretty clever. The MFT (file which describes all the files) is recursively described by its self. It seems very elegant to me.
I can say that my dad has no phone line of any kind and has DirecTV (not DirecTivo). He's had it for years and never had a single interruption in service (Except for the bad Florida storms). Of course, I hear TiVo can't function without the guide; oh well.
Here's what I do: Don't watch TV. Its simple, healthy and you'll find far more free time in addition to saving money. And that TiVo can make a decent MIPS or PowerPC box depending on the version.
E-mail should not carry files. Simple as that. If e-mail programs made getting an attachment out cumbersome and require a command line; this wouldn't have happened.
People just need to understand that e-mail is not a file transfer mechanism. If they want they can put a URL in the e-mail pointing to their file but then you have some kind of accountability at least (and web browsers should not download executable files without a fuss too).
There is almost no reason why anybody would need to send anybody else executable code. And for the one rare instance where I have had to send an executable to a windows user (a demo of my software) I found it dfficult as it is the user had to be instructed how to save and then execute it.
Dude, don't give up. Don't use Microsoft e-mail programs either; but you shouldn't shut down your software just because of this crap.
Put your stuff back up. I get tons of spam to the e-mail addresses posted on my
corporate website but I'm not about to give up, you shouldn't either. Also, be selective about where you put e-mail addresses on web pages or use special e-mail addresses such as sales@ for that kind of stuff.
Just look at it this way; they can only flood us with penis e-mails for so long before nobody is willing to buy their crap anymore.
I have a similar setup only I'm a C/C++ developer. I have a 15" Powerbook that does most of my development work, builds, and general office tasks.
A few servers in my server room store the source code, run backups, and do nightlies. I also keep a Windows laptop with me as well. Why? Portability tests. I use OpenWatcom and Microsoft Visual C++ to make sure my code is 100% portable.
I really do prefer using the Mac for most development tasks. I do have to use the PC for running Tornado and building target images sometimes too; but I try to test the code on my PB before hand.
Having a real UNIX box on the go with the ability to run M$ Office apps along with my dev tools was worth the money that my toy cost me ten times over.
Meaning its practically a clean-room approach. So some other third-party (IBM is so big its best to think of it that way) company contributed fixes to AIX.
So basically, SCO can go pound sand. They don't have a leg to stand on. Although, maybe I can forward Darl some of my spam that will enlarge his penis and he can stand on that.
Nope JFS (in AIX) has existed long before OS/2 2.0 was a glimmer in IBM's eye.
OS/2 originally had two filesystems FAT (or some variation thereof) and HPFS (High-Performance File System). In fact, for a while Windows NT also supported HPFS.
HPFS was an improvment on FAT but lacked journalling. It divided the disk into 8MB "bands", each band had a usage bitmap. HPFS used something called "F-Nodes" which are like UFS's inodes. Rather than using a journal they are doubly-linked.
The original intent was that due to the double linking CHKDSK could put the filesystem back together after a crash. It was never that great. HPFS was designed by Gordon Letwin, a Microsoft engineer, not an IBM one, BTW.
JFS came later (I stopped using OS/2 around 2.1GA); but as I understand it, its an adaptation of what is in AIX.
I wonder if SCO is aware of this little factoid...
Well, its interesting to note that, AFAIK, JFS was first ported to later versions of OS/2 and then to Linux. So the Linux use is one removed from the AIX use. I wonder if that little tidbit will come out in court.
I think these days, between ext3, reiser, and XFS (my favorite, which SCO may try to claim next) Linux would be okay without JFS. But we don't want to set precedent.
I wonder if that effects the legalities of OS/2 at all.
Honestly, I don't see why e-mail has files in it. Sorry, but I grew up in the days of e-mail being a message transfer service, not a file transfer service.
If the people who write e-mail clients would simply not allow file attachments and certainly not allow them to be executed we'd be fine -- reguardless of OS.
Reall, what we need though is a compartmentalization feature. Where an execution environment can control another and so on -- each time stripping (but never adding) priviledges.
So an e-mail client can give up lots of rights and then, if it is so desired that something in the e-mail be executed it can be executed under a more restrictive environment. Programmers can't seem to get this right though.
Think of something like the Java sandbox but even more anal. Thats the only thing that should ever do anything with a file from an e-mail.
Or you can do what I do: read e-mail with PINE and keep up to date with patches and turn off HTML support and anything automatic. There is simply no way for a virus to infect my system; even if you know my OS and specifically try to target me.
Yeah, true, I don't know much about Word. I don't know about Quark XPress or Adobe InDesign. Most of my documents in Publisher are really small: 1 to 5 pages at most (product brochures and data sheets).
My larger documents are done with
DocBook which is a whole other nightmare for documents bigger than 600 or so pages.
Thanks for the info. Thankfully I finally finished all of my documents and now can hope that I can sell my product. If not, its not gonna matter much to me. Sigh.
Actually, there are a few tasks that benefit from 64-bit code: Encryption, Databases, and file-systems. Most modern filesystems allow files >4GB and with digital video the norm now files much larger than 4GB are common.
So the processor spends less clock ticks doing 64-bit arithmatic for file offsets. Cryptography can benefit too. In particular the DH key agreement protocol and RSA public-private key cipher both require the use of "big numbers" (as in 1024 bits and up). And doing these operations 64-bits at a time rather than 32-bits can result in a performance impact. SSL session negotiation may be improved significantly, so that could be a boon to SSL webservers (not that IIS makes a great webserver).
Databases also need 64-bit numbers. Even low-end databases frequently have ID numbers that are 64-bits. For large databases the ability to compute page offsets (which are typically 64-bits) more efficiently can help.
And perhaps a subtle improvement may be in the handling of bitmaps. For example doing a bitwise operation 64-bits at a time will process more pixels than a 32-bit operation in the same amount of time.
But all of those things are really just noise for the special case of amd64. The x86 has always been a register-starved architecture. Going to 64-bit mode gives you 8 more general purpose registers. That alone may very well counter any of the performance loss due to 64-bit integers.
Lots of people on Slashdot have said 64-bit code is slower but haven't pointed out why. Probably the most important thing is cache coherency. 64-bit data structures are (surprise) larger than their 32-bit counterparts. That means that the effective rate of the cache is reduced. As an added bummer, address translation on 64-bit values is slower when there are more levels of translation.
I'm not really saying banned. But I think that having different offerings is a good thing. What I'm kind of saying is that, IMHO, Microsoft was dumb for discontinuing support for Alpha for NT. Why? Because that kept NT portable.
It was that very reason that when NT was being written Cutler insisted on a MIPS port (previously they had an i860 port). So it should be a good thing for Microsoft to continue working on an IA-64 port.
But I don't see why architectures should be abandoned just for the convenience of shrinkwrap application developers.
Slashdot Mirror
Before we migrated to Subversion we were using CVS. In choosing a replacement for CVSs' limitations we first evaluated arch.
In our opinion arch is junk. It works only on UNIX like systems (we have lots of systems that are not UNIX-like here, and we do use Win32 for some stuff).
Converting CVS with history looked to be impossible and we found arch very annoying to use.
The distributed tree model is also another problem. I'm sure that for Linux kernel development, arch makes sense. For a commercial product we do not want multiple trees. We want one consistent tree so when we go to a customer site we don't have to wonder why a circuit is malfunctioning because we didn't sync up with Jack's tree or whatever. We rejected BitKeeper on the same grounds; we weren't so much against paying but wanted something with the right feature set.
ClearCase wasn't cross-platform enough and was really more expensive than we could afford and MetaCVS seemed sluggish.
As a matter of personal opinion (mod me down if you want); we felt that (in the lab) arch felt like a toy and Subversion felt like a polished product.
The sales people at the AT&T store were very pushy and if I had a TDMA phone with the right firmware I would have told them to go fuck themselves.
And the biggest pisser? They don't even terminate GSM data calls to a modem bank. Dicks. Total AT&T dicks.
I used to have AT&T when it was TDMA and it worked wherever I took my phone: camping, hunting, the office. Then my old TDMA phone gave up the ghost and they basically told me I had to get a GSM phone.
Their GSM service is pathetic. The phone doesn't work at my house, doesn't work in the office, drops calls all around the city and I get zero signal strength when in the woods (where my TDMA phone would go!).
I was going to cancel my AT&T service the moment the contract was up but I wonder if Cingular will improve things. Its just insane how bad this phone works.
I gotta find a new carrier. T-Mobile looks good. I don't so much mind GSM as much as I mind AT&T's lack of towers and capacity.
I just had to vent.
It has to be compiled on a compiler with SEH (Structured Exception Handling). For the most part (the kernel) is portable C. In theory the SEH stuff can probably be implemented as macros.
Alas, NTFS is the one area I would like to see and it doesn't look like its there.
I'll make sure you get another copy of that memo.
So the MIPS architecture was the second architecture that NT supported. Then i386, then Alpha, then PPC, and then amd64/ia64. Portability was fairly high on the list of priorities for NT.
Honestly I would love to have a peek at the code just to satisfy curiosity. But I have a feeling anybody who has it is gonna be severely punished. Sigh.
MS Israel did the OS/2 SS as well, right?
And I would love to know whos architecture the object manager was? That has to be my favorite section of the code.
And, FWIW, NTFS is pretty clever. The MFT (file which describes all the files) is recursively described by its self. It seems very elegant to me.
Here's what I do: Don't watch TV. Its simple, healthy and you'll find far more free time in addition to saving money. And that TiVo can make a decent MIPS or PowerPC box depending on the version.
People just need to understand that e-mail is not a file transfer mechanism. If they want they can put a URL in the e-mail pointing to their file but then you have some kind of accountability at least (and web browsers should not download executable files without a fuss too).
There is almost no reason why anybody would need to send anybody else executable code. And for the one rare instance where I have had to send an executable to a windows user (a demo of my software) I found it dfficult as it is the user had to be instructed how to save and then execute it.
Put your stuff back up. I get tons of spam to the e-mail addresses posted on my corporate website but I'm not about to give up, you shouldn't either. Also, be selective about where you put e-mail addresses on web pages or use special e-mail addresses such as sales@ for that kind of stuff.
Just look at it this way; they can only flood us with penis e-mails for so long before nobody is willing to buy their crap anymore.
A few servers in my server room store the source code, run backups, and do nightlies. I also keep a Windows laptop with me as well. Why? Portability tests. I use OpenWatcom and Microsoft Visual C++ to make sure my code is 100% portable.
I really do prefer using the Mac for most development tasks. I do have to use the PC for running Tornado and building target images sometimes too; but I try to test the code on my PB before hand.
Having a real UNIX box on the go with the ability to run M$ Office apps along with my dev tools was worth the money that my toy cost me ten times over.
So basically, SCO can go pound sand. They don't have a leg to stand on. Although, maybe I can forward Darl some of my spam that will enlarge his penis and he can stand on that.
Hehehe.
And even if you do have a small weener, would you really buy an "herbal supplament" for the problem?
I guess people really will buy anything if you get your message across to enough people of the correct (i.e. low) intelligence.
OS/2 originally had two filesystems FAT (or some variation thereof) and HPFS (High-Performance File System). In fact, for a while Windows NT also supported HPFS.
HPFS was an improvment on FAT but lacked journalling. It divided the disk into 8MB "bands", each band had a usage bitmap. HPFS used something called "F-Nodes" which are like UFS's inodes. Rather than using a journal they are doubly-linked.
The original intent was that due to the double linking CHKDSK could put the filesystem back together after a crash. It was never that great. HPFS was designed by Gordon Letwin, a Microsoft engineer, not an IBM one, BTW.
JFS came later (I stopped using OS/2 around 2.1GA); but as I understand it, its an adaptation of what is in AIX.
I wonder if SCO is aware of this little factoid...
I think these days, between ext3, reiser, and XFS (my favorite, which SCO may try to claim next) Linux would be okay without JFS. But we don't want to set precedent.
I wonder if that effects the legalities of OS/2 at all.
My girlfriend and I both hate our jobs. I got her one and I got myself one. She got "Discovery" and I got "Burnout"
If the people who write e-mail clients would simply not allow file attachments and certainly not allow them to be executed we'd be fine -- reguardless of OS.
Reall, what we need though is a compartmentalization feature. Where an execution environment can control another and so on -- each time stripping (but never adding) priviledges.
So an e-mail client can give up lots of rights and then, if it is so desired that something in the e-mail be executed it can be executed under a more restrictive environment. Programmers can't seem to get this right though.
Think of something like the Java sandbox but even more anal. Thats the only thing that should ever do anything with a file from an e-mail.
Or you can do what I do: read e-mail with PINE and keep up to date with patches and turn off HTML support and anything automatic. There is simply no way for a virus to infect my system; even if you know my OS and specifically try to target me.
My larger documents are done with DocBook which is a whole other nightmare for documents bigger than 600 or so pages.
Thanks for the info. Thankfully I finally finished all of my documents and now can hope that I can sell my product. If not, its not gonna matter much to me. Sigh.
So the processor spends less clock ticks doing 64-bit arithmatic for file offsets. Cryptography can benefit too. In particular the DH key agreement protocol and RSA public-private key cipher both require the use of "big numbers" (as in 1024 bits and up). And doing these operations 64-bits at a time rather than 32-bits can result in a performance impact. SSL session negotiation may be improved significantly, so that could be a boon to SSL webservers (not that IIS makes a great webserver).
Databases also need 64-bit numbers. Even low-end databases frequently have ID numbers that are 64-bits. For large databases the ability to compute page offsets (which are typically 64-bits) more efficiently can help.
And perhaps a subtle improvement may be in the handling of bitmaps. For example doing a bitwise operation 64-bits at a time will process more pixels than a 32-bit operation in the same amount of time.
But all of those things are really just noise for the special case of amd64. The x86 has always been a register-starved architecture. Going to 64-bit mode gives you 8 more general purpose registers. That alone may very well counter any of the performance loss due to 64-bit integers.
Lots of people on Slashdot have said 64-bit code is slower but haven't pointed out why. Probably the most important thing is cache coherency. 64-bit data structures are (surprise) larger than their 32-bit counterparts. That means that the effective rate of the cache is reduced. As an added bummer, address translation on 64-bit values is slower when there are more levels of translation.
Way to go Slashdumb. Idolize a bunch of Islamic terrorists. Cyber-terrorists none the less, but terrorists.
I still have to use my Windows box for making product brochures.
Other than that its nice having Office on both platforms (not that I'm any kind of a Word fan)...
It was that very reason that when NT was being written Cutler insisted on a MIPS port (previously they had an i860 port). So it should be a good thing for Microsoft to continue working on an IA-64 port.
But I don't see why architectures should be abandoned just for the convenience of shrinkwrap application developers.
Portability keeps programmers honest!