If your spreadsheet needs a gpu to speed up calculations, you are probably misusing spreadsheets. I know most accountants love the spreadsheet and they make insanely complicated things using spreadsheets pushing it far beyond what these are designed to do. But if you have a spreadsheet that needs this much of cpu time to recompute, you should probably be using a full fledged data base with multiple precomputed indexing.
The problem is that unlike MS Office, the ODF format does not typically store pre-calculated values of formals; so when you load a file it has to run all the formulas, etc to generate what the user wants to see. There's nothing wrong with that, it's just a little slower. An easy optimization would be for ODF to store formula results as part of the cell contents - but that's a change to the ODF standard AND the software that uses it.
Now, as per auto-calculating the spreadsheet and storing the values - that has its own issues, namely if the version of software that stored it had a bug something doing the calculation (much like Excel does is a good chunk of their mathematical functions, e.g. floor() is not the Mathematical floor() function you're use to, but Microsoft's variant of it) then that will get carried over and something will likely blame the wrong software for the bug when that software recalculates it the right way.
Note: The issues with Excel in that respect were well documented as part of the OOXML debacle - floor() doesn't work correctly on negative number IIRC.
Has R690M chipset which the free driver doesn't work on,
Try the open source driver.
Try reading before replying.
The free ATI drivers tend to drop support for chipsets rather regularly.
I meant the open source driver, as opposed to the commercial driver.
Well that was not clear from your original reply, which seemed to hint at using the ATI driver.
Fortunately the open source driver usually supports them pretty well when ATI does drop it.
One more time, for those with poor reading comprehension skills: the card has never worked with fglrx, nor has it ever worked with ati. In fact, the last time I tried the open driver, it was actually worse than before rather than better. ATI is not providing enough information to support my display card, which is why they are lying liars who lie about their commitment to OSS.
The fglrx is one option for OpenGL - it's the ATI proprietary opengl suite. There are other options. Again, mentioning fglrx seems to indicate use of the ATI driver. I believe the open source one doesn't care - e.g. it'll use mesa/mesa3d or whatever. So there are other options. Been there, done that.
If I recall correctly, the big deal about ME is that they completely removed DOS. It actually caused problems with people trying to play DOS games which were still common at that time.
No, it was still DOS-based. Just had to use F8 to get to DOS as they tried to hide it more, again going towards it was a merge towards the NT series.
Protectionism is why sugar prices are so high in America that we use high fructose corn syrup whereas the rest of the world uses ordinary sugar
Incorrect. Sugar prices may be artificially inflated some due to import/export taxes; but the real reason HFC is used is that corn is so cheap because (i) it is highly subsidized, and (ii) we (the federal gov't) pay a lot of farmers to plan corn just to give them work. Both of these are due to Agricultural Lobbying done on behalf the farmers and their unions.
Of course, now HFC is getting to be more expansive than regular sugar thanks to corn-based ethanol production.
Exactly. The NT branch is what Windows is on now. They ceased development of the DOS branch with ME.
I'd argue that WinME was a merge between the 9x/DOS line and the NT line. Name another version of Windows on the 9x/DOS line that had NT error messages in it.
Anyway, the point is that all the drivers you may need are probably included in some of the latest Linux distro's out there.
I have a machine which runs Vista because it won't run anything else. Has R690M chipset which the free driver doesn't work on, and which fglrx never supported. The drivers I need are not included in any Linux distribution out there — they don't exist, because ATI lied about their commitment to Open Source, and their commitment to Linux as well.
Try the open source driver. The free ATI drivers tend to drop support for chipsets rather regularly. Fortunately the open source driver usually supports them pretty well when ATI does drop it. My Dell 2003 era D600 has that issue - ATI drivers worked with it for a very short time before ATI dropped support; but the open source driver works great.
I never ran ME, but understand that it was actually worse than 98.
No, I don't think it was worse, I just think it was rushed.
Me deprecated many of the VxD drivers used with Windows 98, and needed updated WDM drivers that didn't require real mode. Also, it came with generic USB drivers, and USB was just becoming widely popular, but with lots of "almost-compatible" devices on the market, requiring special drivers. The manufacturers weren't ready, and the result was highly unstable Me systems, especially when using USB or older hardware.
Agreed. ME was a very good OS. It just had requirements that most hardware vendors could not meet. My 1997 desktop worked fine with it - a nice upgrade from Win95 OSR2.1 that did resolve some things for me. I continued to run for 3-5 years until I moved the system to a pure Linux system.
But they felt they HAD to rush it - Windows 2000 was coming.
Windows 2000 really was the solution, but Microsoft did the big mistake of not marketing it towards consumers. Then XP came, which basically was a dumbed down 2000 with updated graphics, and it took the world with storm. But boy, was it buggy before SP1. Anyone sane would run 2000 instead.
Win2k was suppose to have version called "Consume Edition" or CE (I remember reading about it and being disappointed when WinNT 2k didn't have the CE version, shortly after that WinME was announced); however, I strongly believe they ended up scraping it and turning out WinME instead.
Then again, one thing I always said about WinME was that it was essentially a WinNT and Win9x merge. It was the first version (and only) of the 9x series to have NT error messages in it. They probably stabilized it just enough for release and then moved on to making WinXP - which was probably the result of the work done for WinME any way, and what Windows 2000 CE was suppose to be.
I agree that TCP congestion control helps prevent hogging bandwidth, but TCP streams only using at most 33.33% of the network varies greatly on the latency, the amount of buffers in the routers between both connections, and window size. Properly tuned TCP stacks can achieve MUCH higher network utilization than that, including most current windows OS's.
Funny thing...I've done testing with directly connected computers using Fiber Channel. I didn't just pull the number out of thin air. And yes, you can do a little to adjust that; however, it's primarily the result of TCP's default control algorithm - Additive Increase, Multiplicative Decrease - which again, you can change. There has been proposals for Multiplicative Increase, Muliplicative Decrease algorithsms too, and you can certainly set those up in your Linux Kernel (and BSDs); but support for them is not very great in the wild.
TCP is not used for Video or Audio streaming as you do not want to have a lost packet cause a fault in the stream.
TCP is probably the most widely used protocol for video streaming. E.g. Youtube streams over TCP. Using TCP means you have more delay, because you have to wait for the occasional retransmit instead of just dropping a frame, but TCP is much easier to deal with overall. Network cards and IP stacks are optimized for TCP, firewalls handle TCP universally well... Unless it really matters that you are 10 seconds behind live (and it rarely does, even cable TV is several seconds behind live), go with TCP.
Video conferencing over TCP is probably not going to happen anytime soon though.
Uhh..no. All streaming services typically use UDP. You don't care if a frame is dropped, but you do care about the performance for the end-user. You cannot get that with TCP. You may be surprised to find YouTube, et al use UDP for the actual streaming. You may also be surprised to find that networks and IP stacks are just as optimized for UDP - they can't really tell the difference. TCP and UDP both build on top of the IP stack, whether IPv4 or IPv6.
Remind me again whose content makes up 90% of the netflix catalogue (aka the stuff netflix customers care about)?
Oh ok.
As you pointed out yourself, the difference between your original statement and my correction is there. It may not be large, but there is a delta. Many independent film makers don't care about the DRM stuff, and they're a growing group. Netflix probably doesn't care much for the DRM stuff either for what they produce - also growing, and very good quality.
TCP hogs up precious BW? Since when? Only in environments where packet loss is substantial is there any real issue, but then again, UDP would likely be much worse. Throw in some of the better optional parts like selective ACK, and TCP is pretty efficient.
TCP works pretty well in environments with high packet loss. Just as good as UDP does. There is a point of no return there though.
Now, I do agree, TCP doesn't hog bandwidth. In fact, it limits an applications ability to flood the network. Each TCP stream can typically use at most 33.33% of the network. You can get around that by using multiple TCP streams, which also happens to be the best way to handle high packet loss environments (such as SatComm).
I'd be interested in hearing what other protocols would work?
The only ones I know of for network traffic are TCP and UDP. TCP guarantees in-order delivery of packets which think would be important for things like video, but I suppose that would cause lag if there were a lot of dropped packets.
TCP is not used for Video or Audio streaming as you do not want to have a lost packet cause a fault in the stream. You use UDP and build your own protocol on top of that to handle the ordering and loss of packets (which you will have).
The official protocol to use (per standards) is UDP MultiCast; however, that requires the routers throughout the Internet to support Multicasting which is generally disabled - thus you can't use it except on dedicated and unmanaged networks. Multicast is primarily targetted at having one source and many receivers, with best path algorithms built-in. Not sure if it solves the packet loss and ordering issues too, possibly. But the ISPs and their Backbone Providers are the main reason we can't actually use it.
Its almost like the discussion about having DRM support in HTML 5 was for real-world practical reasons, rather than just killing puppies and taking your freedom.
Its better than flash and silverlight because this could become standard if everyone takes their head out of the sand and accepts that HTML5 video needs DRM support to be attractive to the people distributing MPAA licensed video.
Yes, I believe the SVN buzzword for that is cherry picking.
Yes, that is the Git buzzword. I don't think SVN has a buzzword for it.
Normally I don't care what buzzwords people use as long as the meaning is clear. However since you make an minor issue of it, I feel free to get in touch with my inner pedant. "Cherrypicking" is the exact term used in SVN. However I spelled it as two words instead of one. Merriam-Webster lists it as a hyphenated word. We must standardize!
Honestly I don't care; I was more pointing to the fact that I believe it came from Git. I couldn't easily find a reference of the term for the SVN 1.4 docs; but it was there in the 1.5 docs - which would have been well after Git was established, so the SVN Red-Book authors adopted the term; I haven't really seen it used on the SVN mailing lists at all. That's all.
In fact, doing a "svn merge -r X:Y ^/project/trunk" is even part of an example in the latest documentation
I do that all the time and it's very useful. The problem (or at least the thing I'm unclear about being reliable) is "svn merge -r A:B ^/project/trunk branch1wc/" followed some time later by ""svn merge -r C:D ^/project/branches/branch1 trunkwc/" (C > B). Some would argue that you shouldn't be switching back and forth like that in the direction of selective merges, and generally I agree, but in the real world people sometimes put the fix on the "wrong" branch (whether out of sloppiness or for some good reason) and that back and forth is then difficult to deal with.
The SVN Merge Tracking introduced in SVN 1.5 does very well with keeping those things straight, and makes it quite reliable.
The problem prior to SVN 1.5 was that you had to track all the merges yourself and be very careful about how you merged. It wasn't that SVN was incapable of it, just that it was a big PITA to do it and know that you didn't double merge something. SVN 1.5 introduced Merge Tracking which has kept increasing in its smarts since - 1.5 already did the case of change A:B being done in one revision and changeset C:D in another, whether C:D came after A:B (e.g A < B < C < D) or even where it contained A:B within it (e.g C < A < B < D).
I generally don't worry about merges any more; I just do them and verify the result is what I intended - sometimes adding an extra log message in a file, or modifying a version number, and that's really about it.
Of course I almost always do a dry run (test merge) in order to know what to expect; and the only time I have seen where people have gotten into trouble with merges is when they fail to do the Double Merge - e.g Merge from destination to source, then source to Destination - when its all complete (e.g. for the reintegration merge).
You just used targetted merges instead of a reintegration merge - e.g. specify which revisions to merge over.
Yes, I believe the SVN buzzword for that is cherry picking.
Yes, that is the Git buzzword. I don't think SVN has a buzzword for it.
I do it all the time to, for example, merge a fix in one rev of the trunk into a release branch. That's not the problem. The difficulty is when sometimes you want to do a cherry picked merge from trunk to branch, and the later do a cherry pick merge from branch into trunk. SVN gets confused about that. I admit I haven't done many experiments in that regard, since I don't want to mess up work in progress. However, it's not part of any workflows in the book, and certainly appears to violate some of the rules. Even if it works sometimes, I wouldn't want to rely on it. The only other possibility I can think of is that my understanding is messed up somehow. Frankly I doubt it, but if it's true I'd be very grateful for a correction.
I have done that without any issues, as I am sure many on the SVN mailing lists have as well - both before and after the Merge Tracking was added. It's a natural part of the work flow. I can think of no SVN rules that it violates. In fact, doing a "svn merge -r X:Y ^/project/trunk" is even part of an example in the latest documentation (see the section Keeping a Branch in Sync Without Merge Tracking), and that is also found in the SVN 1.4 documentation for The Key Concept Behind Merging. True, since Merge Tracking was introduced you typically only do "svn merge ^/project/trunk" into your working copy, but that's to move all changes from the trunk in - which you may not be ready for; and doing a cherry-picked merge is still 100% supported and encouraged when that is what you need to do.
One thing the SVN devs are keen on is giving the developer (or repository administrator) the flexibility to run the VCS as they need to meet the needs of the project(s) hosted in it. There's a lot about best practices, and you'll even find two conflicting best practices as each are targetted at conflicting methods of running a repository (e.g. trunk prestine vs trunk dirty).
SVN consists of mostly weaknesses while Git consists of mostly strengths. Developers are more productive with Git. Seen it many times over. In big SVN shops, most likely you will find the clueful devs using Git frontends to SVN so they don't waste their time fighting with the VCS.
Been in mostly SVN shops, and haven't seen anyone using Git. Seen people using CVS (or PerForce or ClearCase) when they weren't aware of SVN/Git, but haven't seen anyone using Git - just open source projects.
I had one manager that tried to get me to sign off on moving my project from SVN to PerForce or ClearCase (can't remember which) because it was what he was familiar with; it required spending money to do so which I pointed out and that quickly faded.
SVN and Git both have their strengths and weaknesses. And if you need a decentralized system, the Git is certainly for you. It's all a matter of what your needs are - Git isn't for everyone, nor is SVN.
Pardon me reposting part of what I wrote above, but I think it explains what he was talking about:
It's ok to create a branch (say from trunk), work on the branch, and even update it from trunk, but you're pretty much limited to a one-time reintegration merge from that branch back to trunk. You can't easily go back and forth, choosing to put one new thing from trunk into branch and vice versa. That becomes a serious pain if, for example, you use trunk for new development and a release branch on the side. The natural way to work is, if a bug is found in the release, fix it in the release branch and then merge that one change back into trunk. Similarly you may fix a bug in trunk and realize you should also merge it into the release. Svn doesn't really let you do that, so I have to tell people to always make the fix in trunk and merge that one change to the release.
Sure you can. You just used targetted merges instead of a reintegration merge - e.g. specify which revisions to merge over. And as of SVN 1.5 it keeps track of those merges so that when you merge other branches (that synced with trunk) or finally reintegrate it back to trunk it knows that those things were properly merged back.
And, nothing is to stop you from deleting a reintegrated branch and recreating it from a fresh copy of trunk using the same name if you really wanted to only do reintegrations.
And honestly, I'm not keep on the idea of not specifying the reintegrate myself, but I'll see how it works.
SVN can be used as a VCS for other items too, like media or documents. Sometimes you want the less technical users to still get the benefit of version control.
Especially since you can just set it up as a WebDAV drive for the users on Windows. They won't even know they're using VCS as it just looks like another network share drive.
I've been using/administering svn for about 10 years now, usually w/ a Linux server and Windows clients. I've never had that happen. I'm sure your experience is different, but I've no idea why. I never even had problems with some of the older svn upgrades that automagically upgraded the repository (I faithfully did backups before hand, but never had to use them).
When I first started using SVN back in 2004 there was a lot of talk about repositories being "wedged", which I think was mostly related to the BDB backend that was primarily used at the time (and now with 1.8 deprecated); but I don't think I've ever actually had it happen to me in all that time - using it from 1.2 through 1.7.
Yes, I've screwed up a few working copies, but nothing server side, and nothing that wasn't recoverable.
See SVN copy - you can do URL to URL, or Working Copy to URL.
Also see SVN switch to change a working copy from one URL to another.
* mixed-revisions, it's a nightmare
Really? Every VCS has Mixed Revisions. Git even more so with its staging area - so you have 2 changesets and therefor two sets of mixed revisions.
For SVN, just run Update on the root of the working copy, then commit and voila it's back to a single revision.
Like requiring git commit -a, which for Mercurial would just be hg commit as a sane person would expect. Git fans spout a bunch of drivel about "staging area" to justify it, but it can't be justified.
Why can't it be justified? Not every change needs to be committed, I've had running debug changes that have never been committed because they don't need to be, and the staging area lets me ensure only the necessary changes get checked in. It also lets me prevent them from ever being a part of any commit, so I don't have to filter them out later.
Because it means the committed changeset will be different from the changeset on the developer system. So instead of having just changeset A which the VCS sends up, you have changeset A which the VCS knows about and changeset B which is what the developer sees when looking at the file system and what files have changed, and the two are not necessarily the same. If you change a file in changeset B it does not necessarily commute those changes to changeset A without another step. I can very easily see this adding bugs that only get resolved over multiple commits instead of a single commit. Then again, git has the ability to squash commits too, which is probably a result of that.
Mind you, Git is wonderful compared to Subversion which just can't do the things you need to do.
And SVN can do stuff that Git can't. Both have their strengths and weaknesses. (storing empty directory structures is one example of something Git cannot do).
What about its UI is awful? Is it because it is command line based that makes it awful?
I think the real problem is that people approach Git thinking it's like SVN, and when the SVN way of doing things doesn't work they get frustrated and proclaim it to be awful.
I use SVN, and I've used Git. I realize they're different and I expect differences. Yet, little things like Git not tracking empty directories drive me nuts. A VCS of any kind should be able to store a directory structure without a problem and before files are added to it; yet Git fails that very basic functionality. Staging is a nusance, but on that can be lived with, though I'm sure it makes complications that will itself cause bugs.
On the other hand, Git just doesn't do permissions. So everyone has access to everything. But that's the nature of DVCS tools, and you can only get around that by using a Centralized VCS tool, like SVN.
Slashdot Mirror
If your spreadsheet needs a gpu to speed up calculations, you are probably misusing spreadsheets. I know most accountants love the spreadsheet and they make insanely complicated things using spreadsheets pushing it far beyond what these are designed to do. But if you have a spreadsheet that needs this much of cpu time to recompute, you should probably be using a full fledged data base with multiple precomputed indexing.
The problem is that unlike MS Office, the ODF format does not typically store pre-calculated values of formals; so when you load a file it has to run all the formulas, etc to generate what the user wants to see. There's nothing wrong with that, it's just a little slower. An easy optimization would be for ODF to store formula results as part of the cell contents - but that's a change to the ODF standard AND the software that uses it.
Now, as per auto-calculating the spreadsheet and storing the values - that has its own issues, namely if the version of software that stored it had a bug something doing the calculation (much like Excel does is a good chunk of their mathematical functions, e.g. floor() is not the Mathematical floor() function you're use to, but Microsoft's variant of it) then that will get carried over and something will likely blame the wrong software for the bug when that software recalculates it the right way.
Note: The issues with Excel in that respect were well documented as part of the OOXML debacle - floor() doesn't work correctly on negative number IIRC.
Some are already doing this.
These aren't dumb companies, remember there are a lot of consumer protection laws and if your vehicle has a problem.
Only if you like Microsoft
Has R690M chipset which the free driver doesn't work on,
Try the open source driver.
Try reading before replying.
The free ATI drivers tend to drop support for chipsets rather regularly.
I meant the open source driver, as opposed to the commercial driver.
Well that was not clear from your original reply, which seemed to hint at using the ATI driver.
Fortunately the open source driver usually supports them pretty well when ATI does drop it.
One more time, for those with poor reading comprehension skills: the card has never worked with fglrx, nor has it ever worked with ati. In fact, the last time I tried the open driver, it was actually worse than before rather than better. ATI is not providing enough information to support my display card, which is why they are lying liars who lie about their commitment to OSS.
The fglrx is one option for OpenGL - it's the ATI proprietary opengl suite. There are other options. Again, mentioning fglrx seems to indicate use of the ATI driver. I believe the open source one doesn't care - e.g. it'll use mesa/mesa3d or whatever. So there are other options. Been there, done that.
If I recall correctly, the big deal about ME is that they completely removed DOS. It actually caused problems with people trying to play DOS games which were still common at that time.
No, it was still DOS-based. Just had to use F8 to get to DOS as they tried to hide it more, again going towards it was a merge towards the NT series.
Protectionism is why sugar prices are so high in America that we use high fructose corn syrup whereas the rest of the world uses ordinary sugar
Incorrect. Sugar prices may be artificially inflated some due to import/export taxes; but the real reason HFC is used is that corn is so cheap because (i) it is highly subsidized, and (ii) we (the federal gov't) pay a lot of farmers to plan corn just to give them work. Both of these are due to Agricultural Lobbying done on behalf the farmers and their unions.
Of course, now HFC is getting to be more expansive than regular sugar thanks to corn-based ethanol production.
Exactly. The NT branch is what Windows is on now. They ceased development of the DOS branch with ME.
I'd argue that WinME was a merge between the 9x/DOS line and the NT line. Name another version of Windows on the 9x/DOS line that had NT error messages in it.
Anyway, the point is that all the drivers you may need are probably included in some of the latest Linux distro's out there.
I have a machine which runs Vista because it won't run anything else. Has R690M chipset which the free driver doesn't work on, and which fglrx never supported. The drivers I need are not included in any Linux distribution out there — they don't exist, because ATI lied about their commitment to Open Source, and their commitment to Linux as well.
Try the open source driver. The free ATI drivers tend to drop support for chipsets rather regularly. Fortunately the open source driver usually supports them pretty well when ATI does drop it. My Dell 2003 era D600 has that issue - ATI drivers worked with it for a very short time before ATI dropped support; but the open source driver works great.
I never ran ME, but understand that it was actually worse than 98.
No, I don't think it was worse, I just think it was rushed. Me deprecated many of the VxD drivers used with Windows 98, and needed updated WDM drivers that didn't require real mode. Also, it came with generic USB drivers, and USB was just becoming widely popular, but with lots of "almost-compatible" devices on the market, requiring special drivers. The manufacturers weren't ready, and the result was highly unstable Me systems, especially when using USB or older hardware.
Agreed. ME was a very good OS. It just had requirements that most hardware vendors could not meet. My 1997 desktop worked fine with it - a nice upgrade from Win95 OSR2.1 that did resolve some things for me. I continued to run for 3-5 years until I moved the system to a pure Linux system.
But they felt they HAD to rush it - Windows 2000 was coming. Windows 2000 really was the solution, but Microsoft did the big mistake of not marketing it towards consumers. Then XP came, which basically was a dumbed down 2000 with updated graphics, and it took the world with storm. But boy, was it buggy before SP1. Anyone sane would run 2000 instead.
Win2k was suppose to have version called "Consume Edition" or CE (I remember reading about it and being disappointed when WinNT 2k didn't have the CE version, shortly after that WinME was announced); however, I strongly believe they ended up scraping it and turning out WinME instead.
Then again, one thing I always said about WinME was that it was essentially a WinNT and Win9x merge. It was the first version (and only) of the 9x series to have NT error messages in it. They probably stabilized it just enough for release and then moved on to making WinXP - which was probably the result of the work done for WinME any way, and what Windows 2000 CE was suppose to be.
I agree that TCP congestion control helps prevent hogging bandwidth, but TCP streams only using at most 33.33% of the network varies greatly on the latency, the amount of buffers in the routers between both connections, and window size. Properly tuned TCP stacks can achieve MUCH higher network utilization than that, including most current windows OS's.
Funny thing...I've done testing with directly connected computers using Fiber Channel. I didn't just pull the number out of thin air. And yes, you can do a little to adjust that; however, it's primarily the result of TCP's default control algorithm - Additive Increase, Multiplicative Decrease - which again, you can change. There has been proposals for Multiplicative Increase, Muliplicative Decrease algorithsms too, and you can certainly set those up in your Linux Kernel (and BSDs); but support for them is not very great in the wild.
TCP is not used for Video or Audio streaming as you do not want to have a lost packet cause a fault in the stream.
TCP is probably the most widely used protocol for video streaming. E.g. Youtube streams over TCP. Using TCP means you have more delay, because you have to wait for the occasional retransmit instead of just dropping a frame, but TCP is much easier to deal with overall. Network cards and IP stacks are optimized for TCP, firewalls handle TCP universally well... Unless it really matters that you are 10 seconds behind live (and it rarely does, even cable TV is several seconds behind live), go with TCP.
Video conferencing over TCP is probably not going to happen anytime soon though.
Uhh..no. All streaming services typically use UDP. You don't care if a frame is dropped, but you do care about the performance for the end-user. You cannot get that with TCP. You may be surprised to find YouTube, et al use UDP for the actual streaming. You may also be surprised to find that networks and IP stacks are just as optimized for UDP - they can't really tell the difference. TCP and UDP both build on top of the IP stack, whether IPv4 or IPv6.
Remind me again whose content makes up 90% of the netflix catalogue (aka the stuff netflix customers care about)?
Oh ok.
As you pointed out yourself, the difference between your original statement and my correction is there. It may not be large, but there is a delta. Many independent film makers don't care about the DRM stuff, and they're a growing group. Netflix probably doesn't care much for the DRM stuff either for what they produce - also growing, and very good quality.
. At least that's what someone says de Icaza told him:
And why would you believe anything de Icaza says? Especially as it relates to Microsoft?
TCP hogs up precious BW? Since when? Only in environments where packet loss is substantial is there any real issue, but then again, UDP would likely be much worse. Throw in some of the better optional parts like selective ACK, and TCP is pretty efficient.
TCP works pretty well in environments with high packet loss. Just as good as UDP does. There is a point of no return there though.
Now, I do agree, TCP doesn't hog bandwidth. In fact, it limits an applications ability to flood the network. Each TCP stream can typically use at most 33.33% of the network. You can get around that by using multiple TCP streams, which also happens to be the best way to handle high packet loss environments (such as SatComm).
And yes, I've worked in those environments.
I'd be interested in hearing what other protocols would work?
The only ones I know of for network traffic are TCP and UDP. TCP guarantees in-order delivery of packets which think would be important for things like video, but I suppose that would cause lag if there were a lot of dropped packets.
TCP is not used for Video or Audio streaming as you do not want to have a lost packet cause a fault in the stream. You use UDP and build your own protocol on top of that to handle the ordering and loss of packets (which you will have).
The official protocol to use (per standards) is UDP MultiCast; however, that requires the routers throughout the Internet to support Multicasting which is generally disabled - thus you can't use it except on dedicated and unmanaged networks. Multicast is primarily targetted at having one source and many receivers, with best path algorithms built-in. Not sure if it solves the packet loss and ordering issues too, possibly. But the ISPs and their Backbone Providers are the main reason we can't actually use it.
Its almost like the discussion about having DRM support in HTML 5 was for real-world practical reasons, rather than just killing puppies and taking your freedom.
Its better than flash and silverlight because this could become standard if everyone takes their head out of the sand and accepts that HTML5 video needs DRM support to be attractive to the people distributing MPAA licensed video.
FTFY
Yes, I believe the SVN buzzword for that is cherry picking.
Yes, that is the Git buzzword. I don't think SVN has a buzzword for it.
Normally I don't care what buzzwords people use as long as the meaning is clear. However since you make an minor issue of it, I feel free to get in touch with my inner pedant. "Cherrypicking" is the exact term used in SVN. However I spelled it as two words instead of one. Merriam-Webster lists it as a hyphenated word. We must standardize!
Honestly I don't care; I was more pointing to the fact that I believe it came from Git. I couldn't easily find a reference of the term for the SVN 1.4 docs; but it was there in the 1.5 docs - which would have been well after Git was established, so the SVN Red-Book authors adopted the term; I haven't really seen it used on the SVN mailing lists at all. That's all.
In fact, doing a "svn merge -r X:Y ^/project/trunk" is even part of an example in the latest documentation
I do that all the time and it's very useful. The problem (or at least the thing I'm unclear about being reliable) is "svn merge -r A:B ^/project/trunk branch1wc/" followed some time later by ""svn merge -r C:D ^/project/branches/branch1 trunkwc/" (C > B). Some would argue that you shouldn't be switching back and forth like that in the direction of selective merges, and generally I agree, but in the real world people sometimes put the fix on the "wrong" branch (whether out of sloppiness or for some good reason) and that back and forth is then difficult to deal with.
The SVN Merge Tracking introduced in SVN 1.5 does very well with keeping those things straight, and makes it quite reliable.
The problem prior to SVN 1.5 was that you had to track all the merges yourself and be very careful about how you merged. It wasn't that SVN was incapable of it, just that it was a big PITA to do it and know that you didn't double merge something. SVN 1.5 introduced Merge Tracking which has kept increasing in its smarts since - 1.5 already did the case of change A:B being done in one revision and changeset C:D in another, whether C:D came after A:B (e.g A < B < C < D) or even where it contained A:B within it (e.g C < A < B < D).
I generally don't worry about merges any more; I just do them and verify the result is what I intended - sometimes adding an extra log message in a file, or modifying a version number, and that's really about it.
Of course I almost always do a dry run (test merge) in order to know what to expect; and the only time I have seen where people have gotten into trouble with merges is when they fail to do the Double Merge - e.g Merge from destination to source, then source to Destination - when its all complete (e.g. for the reintegration merge).
You just used targetted merges instead of a reintegration merge - e.g. specify which revisions to merge over.
Yes, I believe the SVN buzzword for that is cherry picking.
Yes, that is the Git buzzword. I don't think SVN has a buzzword for it.
I do it all the time to, for example, merge a fix in one rev of the trunk into a release branch. That's not the problem. The difficulty is when sometimes you want to do a cherry picked merge from trunk to branch, and the later do a cherry pick merge from branch into trunk. SVN gets confused about that. I admit I haven't done many experiments in that regard, since I don't want to mess up work in progress. However, it's not part of any workflows in the book, and certainly appears to violate some of the rules. Even if it works sometimes, I wouldn't want to rely on it. The only other possibility I can think of is that my understanding is messed up somehow. Frankly I doubt it, but if it's true I'd be very grateful for a correction.
I have done that without any issues, as I am sure many on the SVN mailing lists have as well - both before and after the Merge Tracking was added. It's a natural part of the work flow. I can think of no SVN rules that it violates. In fact, doing a "svn merge -r X:Y ^/project/trunk" is even part of an example in the latest documentation (see the section Keeping a Branch in Sync Without Merge Tracking), and that is also found in the SVN 1.4 documentation for The Key Concept Behind Merging. True, since Merge Tracking was introduced you typically only do "svn merge ^/project/trunk" into your working copy, but that's to move all changes from the trunk in - which you may not be ready for; and doing a cherry-picked merge is still 100% supported and encouraged when that is what you need to do.
One thing the SVN devs are keen on is giving the developer (or repository administrator) the flexibility to run the VCS as they need to meet the needs of the project(s) hosted in it. There's a lot about best practices, and you'll even find two conflicting best practices as each are targetted at conflicting methods of running a repository (e.g. trunk prestine vs trunk dirty).
SVN consists of mostly weaknesses while Git consists of mostly strengths. Developers are more productive with Git. Seen it many times over. In big SVN shops, most likely you will find the clueful devs using Git frontends to SVN so they don't waste their time fighting with the VCS.
Been in mostly SVN shops, and haven't seen anyone using Git. Seen people using CVS (or PerForce or ClearCase) when they weren't aware of SVN/Git, but haven't seen anyone using Git - just open source projects.
I had one manager that tried to get me to sign off on moving my project from SVN to PerForce or ClearCase (can't remember which) because it was what he was familiar with; it required spending money to do so which I pointed out and that quickly faded.
SVN and Git both have their strengths and weaknesses. And if you need a decentralized system, the Git is certainly for you. It's all a matter of what your needs are - Git isn't for everyone, nor is SVN.
Pardon me reposting part of what I wrote above, but I think it explains what he was talking about:
It's ok to create a branch (say from trunk), work on the branch, and even update it from trunk, but you're pretty much limited to a one-time reintegration merge from that branch back to trunk. You can't easily go back and forth, choosing to put one new thing from trunk into branch and vice versa. That becomes a serious pain if, for example, you use trunk for new development and a release branch on the side. The natural way to work is, if a bug is found in the release, fix it in the release branch and then merge that one change back into trunk. Similarly you may fix a bug in trunk and realize you should also merge it into the release. Svn doesn't really let you do that, so I have to tell people to always make the fix in trunk and merge that one change to the release.
Sure you can. You just used targetted merges instead of a reintegration merge - e.g. specify which revisions to merge over. And as of SVN 1.5 it keeps track of those merges so that when you merge other branches (that synced with trunk) or finally reintegrate it back to trunk it knows that those things were properly merged back.
And, nothing is to stop you from deleting a reintegrated branch and recreating it from a fresh copy of trunk using the same name if you really wanted to only do reintegrations.
And honestly, I'm not keep on the idea of not specifying the reintegrate myself, but I'll see how it works.
SVN can be used as a VCS for other items too, like media or documents. Sometimes you want the less technical users to still get the benefit of version control.
Especially since you can just set it up as a WebDAV drive for the users on Windows. They won't even know they're using VCS as it just looks like another network share drive.
I've been using/administering svn for about 10 years now, usually w/ a Linux server and Windows clients. I've never had that happen. I'm sure your experience is different, but I've no idea why. I never even had problems with some of the older svn upgrades that automagically upgraded the repository (I faithfully did backups before hand, but never had to use them).
When I first started using SVN back in 2004 there was a lot of talk about repositories being "wedged", which I think was mostly related to the BDB backend that was primarily used at the time (and now with 1.8 deprecated); but I don't think I've ever actually had it happen to me in all that time - using it from 1.2 through 1.7.
Yes, I've screwed up a few working copies, but nothing server side, and nothing that wasn't recoverable.
SVN:
* no way to ignore files easily
See SVN properties - svn:ignore.
* no way to branch easily
See SVN copy - you can do URL to URL, or Working Copy to URL.
Also see SVN switch to change a working copy from one URL to another.
* mixed-revisions, it's a nightmare
Really? Every VCS has Mixed Revisions. Git even more so with its staging area - so you have 2 changesets and therefor two sets of mixed revisions. For SVN, just run Update on the root of the working copy, then commit and voila it's back to a single revision.
Why can't it be justified? Not every change needs to be committed, I've had running debug changes that have never been committed because they don't need to be, and the staging area lets me ensure only the necessary changes get checked in. It also lets me prevent them from ever being a part of any commit, so I don't have to filter them out later.
Because it means the committed changeset will be different from the changeset on the developer system. So instead of having just changeset A which the VCS sends up, you have changeset A which the VCS knows about and changeset B which is what the developer sees when looking at the file system and what files have changed, and the two are not necessarily the same. If you change a file in changeset B it does not necessarily commute those changes to changeset A without another step. I can very easily see this adding bugs that only get resolved over multiple commits instead of a single commit. Then again, git has the ability to squash commits too, which is probably a result of that.
Mind you, Git is wonderful compared to Subversion which just can't do the things you need to do.
And SVN can do stuff that Git can't. Both have their strengths and weaknesses. (storing empty directory structures is one example of something Git cannot do).
What about its UI is awful? Is it because it is command line based that makes it awful?
I think the real problem is that people approach Git thinking it's like SVN, and when the SVN way of doing things doesn't work they get frustrated and proclaim it to be awful.
I use SVN, and I've used Git. I realize they're different and I expect differences. Yet, little things like Git not tracking empty directories drive me nuts. A VCS of any kind should be able to store a directory structure without a problem and before files are added to it; yet Git fails that very basic functionality. Staging is a nusance, but on that can be lived with, though I'm sure it makes complications that will itself cause bugs.
On the other hand, Git just doesn't do permissions. So everyone has access to everything. But that's the nature of DVCS tools, and you can only get around that by using a Centralized VCS tool, like SVN.