I mean the idea of being able to commit changes to your local copy of the repository (whatever that is called in your DVCS of choice) without having them pushed up automatically to a "safe" central location. We encourage the use of private branches in SVN instead. Yes, merging in SVN stinks, but svnmerge.py at least makes it tolerable.
In my environment servers are backed up and PCs are not, which is why local repository copies I think are risky.
I appreciate that you could add this sort of feature to a centralized repository but I see that as one of the key differentiators between DVCS and CVCS. If it was a feature in a CVCS I'd be pretty negative about people making use of it without particularly good reasons...
I don't think it's necessarily bad - people are bringing up valuable points about contexts in which it is useful - I worry that local checkins encourage individuals working in a disconnected fashion and thinking less like a team.
"Commit" has always had an air of safety for me which DVCS seems to compromise. But maybe I'm a Luddite as well as being ugly and stupid;-)
"Valuable changes" doesn't only mean changes which are destined for HEAD or the equivalent. "Valuable changes" in my opinion is anything and everything that you are doing on a codebase.
I take your point - if you are responsible in how you use DVCS then I can see that it can be made to work. But in my environment I want all of the changes being made (however offensive or broken) to be centrally auditable and not stashed away in some private repository.
Yes, but the point is that it encourages and allows behaviour that is not desirable in a corporate development environment - local checkins. You CAN push your changes to it but equally you CAN just check stuff in locally. In some contexts this is great - but I think in corporate environments it promotes risky behaviour.
Look - it's a tool - you can use it responsibly or use it irresponsibly - with the right set of rules and processes I'm sure it can be made to work. Local checkins are what really get my goat;-)
What worries me is that it encourages behaviour which leaves valuable changes sitting on a disk which may not be backed up. I see changes being made to a codebase like valuable little bits of gold which need to be kept somewhere nice and safe, which is not on individual machines but on the server (RAID, redundant power, UPS, etc)
Yes, if you are disciplined about how you use it then I'm sure you can use it like any centralised VC. It is a tool - it is not evil - it just encourages what I see as risky behaviour in my particular environment. But I can fully understand that in other contexts it may be useful.
I'm using the terms backup and integrity in slightly different ways than you are.
By backup - I mean a tape or location where I know I can look to find the "good" copy that contains the official tree of code that represents what is going into my product. What you are describing is copies of repositories sitting in various locations that isn't really the same as a backup. It's also a bit upside-down - I don't want to be "pulling" fixes from engineers, I want engineers "pushing" fixes into a known-good integration environment.
By integrity - I mean ensuring that you have all of the fixes you want to have from everyone who should be making changes on a project. NOT file corruption.
Errr. I don't see how without jumping through a lot of hoops.
If I have n users in my software team and they each have a local repository copy and "commits" that they make are made to that local repository then it basically requires me to backup everyone's PC in order to ensure that work is not lost. I don't back up PCs, we have a clear rule that if you want something to be safe it goes on the server.
Now, sure, I can see that with some effort and mucking about you can ensure that everyone's local repository copies are backed up. But this is a whole lot of hassle and I fail to see why you would bother - other than if you have a particular religious requirement to use a DVCS;-)
I run the IT systems for my small software company and frankly Subversion is a great tool for the job. I don't *want* a distributed VC system because I don't want the hassle of trying to ensure that everyone's modifications to the code tree are backed up correctly and stored safely somewhere. I want it in a central spot I can back up and manage without my employees having to worry about it.
Basically Subversion is not suited for development with a diverse population of loosely connected individuals, each with their own private branches. Frankly, for corporate work, I don't understand why you would want the backup and integrity hassles of a distributed version control system. But maybe that's because I'm ugly and stupid:-)
Not trying to write a new Godwin's law - my point is that we as a society have decided that child pornography is so distastefully abhorrent that it is worth suspending free speech/expression in order to stamp it out. I don't believe that this is the only example of information which ought to be kept locked away, I do believe that we should be extremely (extraordinarily!) careful in what we decide to suppress, but I would have thought that design details for nuclear weaponry would fit into this category.
It's not information I don't like - hey, who isn't interested in design details for a powerful piece of technology - but maybe, just maybe, I shouldn't be given the opportunity to scratch this particular itch.
...am I the only one who thinks that this sort of information is a little too important to "leak"? I mean, I'm all in favour of free information and stuff but surely there comes a point when you have to exercise a little bit of judgement?
This probably isn't going to go down well in these parts - but there are some people out there who really don't need any more encouragement in this direction than they already have. Surely this is the engineering equivalent of child porn...
The Marathon series was a mac-only creation written by Bungie (before they were bought by Microsoft - they went on to do Halo I think) and it was an example of a FPS with a seriously deep storyline. It was so complex and deep that I couldn't even follow it! But they put in loads of effort to make it consistent, a great game and practically an FPS novel. An oldie but a goodie.
Although I guess I can sympathize with Parallels, who have spotted a niche and gone for it, I think that competition is great. It will be particularly interesting to see whether or not VMWare charge for this or whether it's just a freebie a la VMWare Player on the PC - I suppose it's likely they'll charge for it though. In any case, I'll be buying it, along with my Parallels license. And hey, may the best product win.
m) No built-in Unicode support (Waaak! How can a modern language not support a wide string type!) n) Variables are global BY DEFAULT and not local. To declare a local variable you have to say local foo = "blah".
Hate to tell you, but Purify is most definitely a dynamic analysis tool. Basically it works by substituting malloc, new and friends and then showing you on the fly your program behaviour (good at catching things like memory leaks). Static analysis tools like lint do not involve executing the programs, just analyzing it's structure to see which code paths are followed; dynamic analysis tools hook the actual execution.
$LOAD_PATH.select do |base|
base = File.expand_path(base)
extended_root = File.expand_path(RAILS_ROOT) - base[0, extended_root.length] == extended_root || base =~ %r{rails-[\d.]+/builtin} + base.match(/\A#{Regexp.escape(extended_root)}\/*#{ file_kinds(:lib) * '|'}/) || base =~ %r{rails-[\d.]+/builtin}
end
Not seen the context (so this is guesswork), but looks suspciously to me like you could supply a path like;
RAILS_ROOT/../../../../etc/passwd
Or something substantially similar to it...
Re:Even if you could do Quad SLI...
on
Quad PCIe Motherboard
·
· Score: 2, Interesting
I was under the impression that the way these SLI things worked was that each card renders a different scanline; so the graphics performance would continue to increase as you added more cards (up to the total number of visible scanlines, obviously). Each new card just makes proportionally less difference.
So if 4 cards take 1 ms each to render a scanline, and you have 1000 scanlines (and it was perfectly parallel) it would take 250ms to render the screen. 2 cards of the same performance would take 500ms. So 1 extra video card gave you a 500ms improvement, whereas 3 extra video cards gave you 750ms improvement, etc.
Note that this is based on scant understanding of how SLI works - this is probably a radical simplification.
Yeah "mobile software stats" that only includes PDA-like platforms. No mention of the billions of handsets out there which are running MIDP, BREW or similar - surely MIDP platforms are more popular than Palm?
The public apology comes *first*, then comes the fixing of your product specifications and removing incorrect data. You do it in this order and frankly, it's almost certainly a lame attempt at a cover-up.
Making a mistake? Fair enough. Treating your customers like idiots and trying to hide what you've done, though, is not something that is going to fly in this day and age. ATI are going to pay through the nose on this one and doing stupid things like this to try to paint over the damage done is just plain stupid.
Come clean, apologise publicly, recall products, do whatever you can to ensure that you have supported and looked after your customers. But to do this sort of thing smacks of burying your head in the sand.
> 1. I know what package installed what file. (rpm -qf
Yeah, on one Linux install. On another one it might be dpkg -l. On another one it might be some portage thing with unknown arguments. And what about locally compiled packages?
> 2. I can move applications EASILY from one system to another without going through the install process.
A man who has obviously never been through.so dependency hell. Good luck to you.
> 3. I can backup and restore a Linux/UNIX box from a centralized tape backup system MUCH easier than a Windows server with custom RAID. You haven't experienced IT to the fullest until you tried to recover an older server class Windows NT/2000 box.
Okay, so you can use tar better on Unicies. Point taken.
> 5. Remote adminstration can be done EASILY from the command line under Linux. In XP I've installed Cygwin SSH on XP and have written some VBS scripts. Windows is definately catching up in the area of remote administration, but is still hard to use and books are scarce.
Okay, so remote admin is improving, we can agree on that one.
> 6. Patching for security flaws is a breeze under Linux/UNIX. With Microsoft, install a SUS server and maybe, just maybe if the planets align the patch will saunter down to the PC. I had to write some scripts to slam patches in and reboot. Seems like every critical patch requires a reboot.
What about a kernel vulnerability? Last time I looked you still got to reboot a linux kernel. I agree that segmentation of applications is better on unix, but don't kid yourself; security patching linux requires a lot more effort. And to compare apples with apples here, you're talking about supplying a security patch to a bunch of linux boxes? That's at least as hard as deploying a windows security patch and, in a mixed linux distribution environment, an order of magnitude harder.
> 7. Figuring out what's going on under Linux/UNIX is pretty simple. You can clearly see what launches applications, what files they have open, what resources they are using etc...
Yeah, right. cat/proc/???? is easy?!? The administrative tools in Win 2k, for example, aren't that hard to use. I would say that they're probably even on that front.
...by mobile processors, I would say. To be honest, I think it's likely (if it isn't already the case) that processors in mobile networked devices will fast surpass desktop and server processors as objects of desire. Instead of one or two souped up power hungry beasts on your desk, you'll have 5-6 devices floating around (phone, pda, mp3 player + more) that will start to displace your desktop machine as what you spend most of your time and money on. PC processors will become an important minority concern in the world of mobility. I think that the ARM architecture is the likely future market leader by volume (if it isn't already!)
Slashdot Mirror
I mean the idea of being able to commit changes to your local copy of the repository (whatever that is called in your DVCS of choice) without having them pushed up automatically to a "safe" central location. We encourage the use of private branches in SVN instead. Yes, merging in SVN stinks, but svnmerge.py at least makes it tolerable.
In my environment servers are backed up and PCs are not, which is why local repository copies I think are risky.
I appreciate that you could add this sort of feature to a centralized repository but I see that as one of the key differentiators between DVCS and CVCS. If it was a feature in a CVCS I'd be pretty negative about people making use of it without particularly good reasons...
I don't think it's necessarily bad - people are bringing up valuable points about contexts in which it is useful - I worry that local checkins encourage individuals working in a disconnected fashion and thinking less like a team.
;-)
"Commit" has always had an air of safety for me which DVCS seems to compromise. But maybe I'm a Luddite as well as being ugly and stupid
"Valuable changes" doesn't only mean changes which are destined for HEAD or the equivalent. "Valuable changes" in my opinion is anything and everything that you are doing on a codebase.
I take your point - if you are responsible in how you use DVCS then I can see that it can be made to work. But in my environment I want all of the changes being made (however offensive or broken) to be centrally auditable and not stashed away in some private repository.
Yes, but the point is that it encourages and allows behaviour that is not desirable in a corporate development environment - local checkins. You CAN push your changes to it but equally you CAN just check stuff in locally. In some contexts this is great - but I think in corporate environments it promotes risky behaviour.
;-)
Look - it's a tool - you can use it responsibly or use it irresponsibly - with the right set of rules and processes I'm sure it can be made to work. Local checkins are what really get my goat
What worries me is that it encourages behaviour which leaves valuable changes sitting on a disk which may not be backed up. I see changes being made to a codebase like valuable little bits of gold which need to be kept somewhere nice and safe, which is not on individual machines but on the server (RAID, redundant power, UPS, etc)
Yes, if you are disciplined about how you use it then I'm sure you can use it like any centralised VC. It is a tool - it is not evil - it just encourages what I see as risky behaviour in my particular environment. But I can fully understand that in other contexts it may be useful.
I'm using the terms backup and integrity in slightly different ways than you are.
By backup - I mean a tape or location where I know I can look to find the "good" copy that contains the official tree of code that represents what is going into my product. What you are describing is copies of repositories sitting in various locations that isn't really the same as a backup. It's also a bit upside-down - I don't want to be "pulling" fixes from engineers, I want engineers "pushing" fixes into a known-good integration environment.
By integrity - I mean ensuring that you have all of the fixes you want to have from everyone who should be making changes on a project. NOT file corruption.
Errr. I don't see how without jumping through a lot of hoops.
;-)
If I have n users in my software team and they each have a local repository copy and "commits" that they make are made to that local repository then it basically requires me to backup everyone's PC in order to ensure that work is not lost. I don't back up PCs, we have a clear rule that if you want something to be safe it goes on the server.
Now, sure, I can see that with some effort and mucking about you can ensure that everyone's local repository copies are backed up. But this is a whole lot of hassle and I fail to see why you would bother - other than if you have a particular religious requirement to use a DVCS
I run the IT systems for my small software company and frankly Subversion is a great tool for the job. I don't *want* a distributed VC system because I don't want the hassle of trying to ensure that everyone's modifications to the code tree are backed up correctly and stored safely somewhere. I want it in a central spot I can back up and manage without my employees having to worry about it.
:-)
Basically Subversion is not suited for development with a diverse population of loosely connected individuals, each with their own private branches. Frankly, for corporate work, I don't understand why you would want the backup and integrity hassles of a distributed version control system. But maybe that's because I'm ugly and stupid
Not trying to write a new Godwin's law - my point is that we as a society have decided that child pornography is so distastefully abhorrent that it is worth suspending free speech/expression in order to stamp it out. I don't believe that this is the only example of information which ought to be kept locked away, I do believe that we should be extremely (extraordinarily!) careful in what we decide to suppress, but I would have thought that design details for nuclear weaponry would fit into this category.
It's not information I don't like - hey, who isn't interested in design details for a powerful piece of technology - but maybe, just maybe, I shouldn't be given the opportunity to scratch this particular itch.
Hope that make sense.
...am I the only one who thinks that this sort of information is a little too important to "leak"? I mean, I'm all in favour of free information and stuff but surely there comes a point when you have to exercise a little bit of judgement?
This probably isn't going to go down well in these parts - but there are some people out there who really don't need any more encouragement in this direction than they already have. Surely this is the engineering equivalent of child porn...
The Marathon series was a mac-only creation written by Bungie (before they were bought by Microsoft - they went on to do Halo I think) and it was an example of a FPS with a seriously deep storyline. It was so complex and deep that I couldn't even follow it! But they put in loads of effort to make it consistent, a great game and practically an FPS novel. An oldie but a goodie.
Quoth the article:
"Read the full interview or listen the podcast (available to download also) on San Franscisco Chronicle."
Yeah, you'd think they'd have edited that one out...
Although I guess I can sympathize with Parallels, who have spotted a niche and gone for it, I think that competition is great. It will be particularly interesting to see whether or not VMWare charge for this or whether it's just a freebie a la VMWare Player on the PC - I suppose it's likely they'll charge for it though. In any case, I'll be buying it, along with my Parallels license. And hey, may the best product win.
Some other little gotchas:
m) No built-in Unicode support (Waaak! How can a modern language not support a wide string type!)
n) Variables are global BY DEFAULT and not local. To declare a local variable you have to say local foo = "blah".
Yeah, but my point is that the parent and the site he referenced claimed that Purify was a static analysis tool; it isn't.
Hate to tell you, but Purify is most definitely a dynamic analysis tool. Basically it works by substituting malloc, new and friends and then showing you on the fly your program behaviour (good at catching things like memory leaks). Static analysis tools like lint do not involve executing the programs, just analyzing it's structure to see which code paths are followed; dynamic analysis tools hook the actual execution.
$LOAD_PATH.select do |base|{ file_kinds(:lib) * '|'}/) || base =~ %r{rails-[\d.]+/builtin}
base = File.expand_path(base)
extended_root = File.expand_path(RAILS_ROOT)
- base[0, extended_root.length] == extended_root || base =~ %r{rails-[\d.]+/builtin}
+ base.match(/\A#{Regexp.escape(extended_root)}\/*#
end
Not seen the context (so this is guesswork), but looks suspciously to me like you could supply a path like;
RAILS_ROOT/../../../../etc/passwd
Or something substantially similar to it...
I was under the impression that the way these SLI things worked was that each card renders a different scanline; so the graphics performance would continue to increase as you added more cards (up to the total number of visible scanlines, obviously). Each new card just makes proportionally less difference.
So if 4 cards take 1 ms each to render a scanline, and you have 1000 scanlines (and it was perfectly parallel) it would take 250ms to render the screen. 2 cards of the same performance would take 500ms. So 1 extra video card gave you a 500ms improvement, whereas 3 extra video cards gave you 750ms improvement, etc.
Note that this is based on scant understanding of how SLI works - this is probably a radical simplification.
Talk about getting a bargain - if you can't figure out a way of raising that sort of money on your own you really shouldn't be in business.
Remember, folks, venture capital is like heroin; easy to get hooked on and bloody hard to get off.
Yeah "mobile software stats" that only includes PDA-like platforms. No mention of the billions of handsets out there which are running MIDP, BREW or similar - surely MIDP platforms are more popular than Palm?
The public apology comes *first*, then comes the fixing of your product specifications and removing incorrect data. You do it in this order and frankly, it's almost certainly a lame attempt at a cover-up.
Making a mistake? Fair enough. Treating your customers like idiots and trying to hide what you've done, though, is not something that is going to fly in this day and age. ATI are going to pay through the nose on this one and doing stupid things like this to try to paint over the damage done is just plain stupid.
Come clean, apologise publicly, recall products, do whatever you can to ensure that you have supported and looked after your customers. But to do this sort of thing smacks of burying your head in the sand.
Dumb, dumb, dumb.
Uh? You what?!?
.so dependency hell. Good luck to you.
...
/proc/???? is easy?!? The administrative tools in Win 2k, for example, aren't that hard to use. I would say that they're probably even on that front.
> 1. I know what package installed what file. (rpm -qf
Yeah, on one Linux install. On another one it might be dpkg -l. On another one it might be some portage thing with unknown arguments. And what about locally compiled packages?
> 2. I can move applications EASILY from one system to another without going through the install process.
A man who has obviously never been through
> 3. I can backup and restore a Linux/UNIX box from a centralized tape backup system MUCH easier than a Windows server with custom RAID. You haven't experienced IT to the fullest until you tried to recover an older server class Windows NT/2000 box.
Okay, so you can use tar better on Unicies. Point taken.
> 5. Remote adminstration can be done EASILY from the command line under Linux. In XP I've installed Cygwin SSH on XP and have written some VBS scripts. Windows is definately catching up in the area of remote administration, but is still hard to use and books are scarce.
Okay, so remote admin is improving, we can agree on that one.
> 6. Patching for security flaws is a breeze under Linux/UNIX. With Microsoft, install a SUS server and maybe, just maybe if the planets align the patch will saunter down to the PC. I had to write some scripts to slam patches in and reboot. Seems like every critical patch requires a reboot.
What about a kernel vulnerability? Last time I looked you still got to reboot a linux kernel. I agree that segmentation of applications is better on unix, but don't kid yourself; security patching linux requires a lot more effort. And to compare apples with apples here, you're talking about supplying a security patch to a bunch of linux boxes? That's at least as hard as deploying a windows security patch and, in a mixed linux distribution environment, an order of magnitude harder.
> 7. Figuring out what's going on under Linux/UNIX is pretty simple. You can clearly see what launches applications, what files they have open, what resources they are using etc
Yeah, right. cat
Anyway, just correcting a few biases there....
Um, yeah, but did you check the date on that announcement? Sounds like an April Fool's joke to me...
...by mobile processors, I would say. To be honest, I think it's likely (if it isn't already the case) that processors in mobile networked devices will fast surpass desktop and server processors as objects of desire. Instead of one or two souped up power hungry beasts on your desk, you'll have 5-6 devices floating around (phone, pda, mp3 player + more) that will start to displace your desktop machine as what you spend most of your time and money on. PC processors will become an important minority concern in the world of mobility. I think that the ARM architecture is the likely future market leader by volume (if it isn't already!)