Having used primarily Debian at home for years, I installed Ubuntu a couple of days ago (a switch from Windows, as I tend to run side-by-side but lost the use of one PC about a year ago).
Ubuntu dropped me right into a nice desktop with zero configuration, then asked me if I wanted to install the nvidia driver.
I seem to remember that every time I installed Debian, it left me on the console or failed to start X despite trying, after asking a bunch of configuration questions. I usually ended up doing everything by hand and installing only what I wanted, because whenever I asked for "the defaults" they just didnt work. Debian certainly never asked me to install the Nvidia driver- the only way to do so would be to go get it myself. Lack of a working 3d driver is why I was on Windows for so long, and I only went back to Linux because I was sick of trying to get cygwin to do what I wanted.
Now I'm in Linux, with 3d and sound working perfectly. It only dropped me to console once (and once is enough to mean I'd never recommend it for ANYONE). Using default options for nearly everything. Tablet still doesn't work correctly, I've yet to meet a Linux where it does, but I can live without pressure sensitivity for a week or so.
In short: people don't use defaults in debian because they are broken and suck. People use proprietary software in Ubuntu because they're given the option.
If a web browser/office suit/file manager takes four seconds to be usable, something is wrong with it.
If that is an open source project which is bundled with a "fast" operating system, that bundle should take the speed of its most frequently-accessed bundled apps into account when declaring itself speedy.
"Hi, I've got this free trial, want it?" "sure, what's the harm. You said free, right?" "Yeah, completely free. Just give me your credit card number and agree to this payment authorization."
This is what MOST of the so-called "tricks" are: Just plain asking for the number and permission. It's how the so-often-complained-about AOL did it, it's how "Free Credit Report".com does it, it's likely how these guys were doing it.
If you're stupid enough to hand over PAYMENT DETAILS to use a service, and expect it to be free, your bank should not have issued you an account in the first place.
Spreadsheets are often used for purposes which go above and beyond their intention, acting in some cases as almost a general-purpose programming environment.
Since this abuse is so common, why not take it to the next level and make a programming language which acts like a spreadsheet?
C doesn't have any "built in functions", that I'm aware of. It's got a standard library, yeah, but no "built ins". It's a pedantic issue of semantics, but it's technically true.
MS Word comes "free" with many systems, or is allowed for employees to use at home (yes, legally, with some hoops).
And.. what about its interface is non-intuitive? What obscure thing are you trying to do which you think requires a prominent interface for all the 99.9999% of people who will never use that function?
If you're trying to do print work with MS Word, you've got some problems, yeah. But that sentence could be repeated anyway.
I work for a web-based travel company. We log IP addresses as part of our regular process, not due to government mandate, but because we're a web company, it would be rather stupid of us to _not_ ever log IP addresses, just for general site security and bot-banning purposes.
If the government required us to hand over logs, our logs would include the I.P. address. This should not be surprising to anyone.
Two points:
- Can I copy from one module to another while retaining relationships and history? I can in svn (as long as it's not an external) since svn doesn't care what you declare to be a "module".
- Last I checked, Submodules are broken to the point of being worse than svn:externals. A simple note in a wiki page for using submodules says, as if it didn't matter: "It's not safe to run "git submodule update" if you've made changes within a submodule. They will be silently overwritten". In my book that makes submodules unsuitable for any purpose. When I last investigated this problem it seemed that submodules were still considered to be in "dirty hack" status, and haven't yet been fully integrated into git.
Other points in your post, like claiming that editing directly on a remote share uses less bandwidth than sending periodic diffs, or that "don't worry, we all have a copy somewhere" is a valid backup strategy for a business, were ignored.
Git is like multimaster replication of a database, yeah. But in this example that's used as an alternative to/transactions/.
And it's not just a matter of "big enough", but basic organization. Would you rather tell someone who asks "where can I find this project?":
- this url: svn+ssh://path/to/repos/path/within/repos/foo; and that's all
- or, this url: ssh://path/to/master; "And within that you want the "foobar" directory. It'll be in there along with every other project that uses libfoo, since that's the only way to share things with libfoo and other projects when using git."
- or, this url: ssh://path/to/masterfoobar; and this one: ssh://path/to/masterlibfoo; and instructions on how to set them up manually
I understand "well then, don't do that!", but this pretty much just assumes that nobody will ever want two things, or not already be familiar with one thing, or that everybody/likes/ setting up PATH variables.
Your idea of a "brutal hack to do what svn does" would.. not at all do what svn does. I'm guessing you work only in a "/SingleProjectInARepos/{trunk,branches}" environment, and have never had to deal with maintaining a large repository which is useful to more than one person and useful to more than one person at a time.
I've been annoyed with svn's limitations before. A lot. I've in two jobs been in charge of maintaining SVN repositories, and/often/ wish that git were an option. But it just wasn't, for either. On one, due mainly to the limited (and various) systems we were working on. But I find it strangely coincidental that events conspired to put me in two situations where these needs, for whatever reason, existed. SVN was not ideal, and needed a lot of help to keep it going.
BUT: It could be made to work. It had ways worked out of doing what I needed to do, by people who were smarter than me. That information could be found online easily. Subversion's difficulties often amounted to needing to write good commit messages. When SVN failed due to my own fuck-ups, it did so in a way which hurt no one, and was easily restored.
Git is apparently not mature enough to have these things worked out yet. When git fails, it can need arcane magicks to get it working right.
And because git encourages you to keep your "working" branches local, fucking up your local repository can mean a serious headache.
And I can go on and on, but I've done that already.
remote tracking branches are just branches which are easy to pull someone else's change into. This has nothing to do with sharing changes between different projects, sub-projects, etc. The "master" branch, unless I've gotten my terminology mixed up, is often a remote-tracking branch. ie: It's a thing you almost can't avoid using regularly in git anyway. It is unrelated to any post I have made on the subject, other than being the place where some of the features I yearn for would need to be added.
Why worry about those claiming to be an existing well-known social networking site? It's already common practice for these places to, no impostering involved, ask for login details of completely unrelated sites when you sign up. That should _NOT_ be considered in any way okay, even from a site you "trust".
And then there's OpenID or whatever it's called, which basically says "make it not just disturbingly common, but recommended!" wtf?
We know from random statistics of crashes involving cars which are supposedly equipped with airbags capable of deploying during an accident that a high percentage of all "untested airbag readiness" (UAR from here on) cars actually do have airbags. The risk of these not deploying is low.
Meanwhile, however magically, we know that car X's airbag will _not_ work in an accident. The risk in driving that car is high.
If X is also a UAR car, the risk is identical. If X is known to be defective, the risk is greater. If X is known, however magically, to not be defective, the risk is higher.
I use SVN and don't keep the history in one place, I only/access/ it from one place. Having history in EVERY copy that accesses it is like copying an entire relational database to every client that accesses it.
using --depth doesn't just "limit" what you can do, it turns git into a retard. Not having the ability to say "hmm, actually, I need that too. Go fetch it." without using low-level operations is brain-dead.
As for "it's possibly to rewrite history", yes, I said that. Git solves the problems involved in rewriting history by ignoring those problems, which I personally think is just fine. The problem is that if you're pulling from some other repository which/hasn't/ decided that the 2GigsOfCachedStatistics folder belongs somewhere else, you can't just tell git not to pull it. Git only operates on an entire deep tree at a time.
This is just the SVN "directory structure is good enough to keep track of any type of change" mentality which Linus calls "brain dead", but.. well, it works, and git doesn't.
All expected to be fixed in a future release, I hope.
The specific scenario I use SVN for is where a single repository (not svn:externals, which I agree are broken, though for other reasons) has several related but independently developed projects, and a couple of "common" projects shared by all (mostly library-type functions). Using svn we can check out these individual folders easily, work on them independently, and ignore completely (ie: never check out) folders for projects we aren't involved in. It is possible and easy to copy files from one project to another, retaining history. I do this semi-regularly, for example when a "common" change necessitates the creation of a supporting object in several of the other projects, I create the common object, create the supporting object (which inherits from the common object), then copy+history that supporting object to the other projects which need it (making changes as I go).
I'd expect git, which seems to be all about decentralization, to at least have a similar option, perhaps retaining history (no clue how) when copying from one repository to another. I would expect that the ability for different "Open Source" projects to share code easily would be a priority, but I guess that's not the case.
Trying to learn git a few months ago, I started up a handful of projects which had some similar needs. I quickly learned that in git, things were either the same project or entirely unrelated, and that sharing common files between them would mean having an entirely separate library which I could commit changes to with about as much ease as an SVN:External. Less ease, really, as git chose to silently squash changes I made when a common command, through use of git submodules, turned lethal. Googling revealed that submodules were really just a clever hack at this point and that it would silently eat changes if you didn't use some specific and very-hack-feeling commands to update.
Perhaps git is only for completely-encapsulated projects (which is what I currently use it for- one shot scripts that I'd rather version than be sorry about), or for very very mature projects, which have already made all their decisions about what goes where, and who owns what. For starting a new project, where I wasn't sure what would be shared, what wouldn't, and what was truly related, I found git clunky and tedious.
Slashdot Mirror
I'm guessing he doesn't want to pay for it.
"This provides a life expectancy of over four years, which is reasonable for a hard disk."
the target is only four years? Am I missing something here?
No wonder I've had so many disk failures, a mere four years is considered /reasonable/ by these asshats.
Just like those accountants.. never doing any real work, just saving money!
dude, when you do... the coincidence is gonna blow your mind!
Having used primarily Debian at home for years, I installed Ubuntu a couple of days ago (a switch from Windows, as I tend to run side-by-side but lost the use of one PC about a year ago).
Ubuntu dropped me right into a nice desktop with zero configuration, then asked me if I wanted to install the nvidia driver.
I seem to remember that every time I installed Debian, it left me on the console or failed to start X despite trying, after asking a bunch of configuration questions. I usually ended up doing everything by hand and installing only what I wanted, because whenever I asked for "the defaults" they just didnt work. Debian certainly never asked me to install the Nvidia driver- the only way to do so would be to go get it myself. Lack of a working 3d driver is why I was on Windows for so long, and I only went back to Linux because I was sick of trying to get cygwin to do what I wanted.
Now I'm in Linux, with 3d and sound working perfectly. It only dropped me to console once (and once is enough to mean I'd never recommend it for ANYONE). Using default options for nearly everything. Tablet still doesn't work correctly, I've yet to meet a Linux where it does, but I can live without pressure sensitivity for a week or so.
In short: people don't use defaults in debian because they are broken and suck. People use proprietary software in Ubuntu because they're given the option.
If a web browser/office suit/file manager takes four seconds to be usable, something is wrong with it.
If that is an open source project which is bundled with a "fast" operating system, that bundle should take the speed of its most frequently-accessed bundled apps into account when declaring itself speedy.
"Hi, I've got this free trial, want it?"
"sure, what's the harm. You said free, right?"
"Yeah, completely free. Just give me your credit card number and agree to this payment authorization."
This is what MOST of the so-called "tricks" are: Just plain asking for the number and permission. It's how the so-often-complained-about AOL did it, it's how "Free Credit Report".com does it, it's likely how these guys were doing it.
If you're stupid enough to hand over PAYMENT DETAILS to use a service, and expect it to be free, your bank should not have issued you an account in the first place.
Spreadsheets are often used for purposes which go above and beyond their intention, acting in some cases as almost a general-purpose programming environment.
Since this abuse is so common, why not take it to the next level and make a programming language which acts like a spreadsheet?
http://www.subtextual.org/
C doesn't have any "built in functions", that I'm aware of. It's got a standard library, yeah, but no "built ins". It's a pedantic issue of semantics, but it's technically true.
MS Word comes "free" with many systems, or is allowed for employees to use at home (yes, legally, with some hoops).
And.. what about its interface is non-intuitive? What obscure thing are you trying to do which you think requires a prominent interface for all the 99.9999% of people who will never use that function?
If you're trying to do print work with MS Word, you've got some problems, yeah. But that sentence could be repeated anyway.
Order now, and as a special bonus you also get: It's butt ugly!
Strange in a society where streamlined aerodynamic everything tends to be viewed as beautiful.
and then as a bonus, your password is in the clipboard for any application to read, intentionally or not. Good work.
the Spore case is very clearly one of a handful of trolls on Amazon. Games with DRM in general, however, are a clear case of what you said.
I work for a web-based travel company. We log IP addresses as part of our regular process, not due to government mandate, but because we're a web company, it would be rather stupid of us to _not_ ever log IP addresses, just for general site security and bot-banning purposes.
If the government required us to hand over logs, our logs would include the I.P. address. This should not be surprising to anyone.
Why have multiple SD cards per person? They're huge.
Or, you can use submodules. Problem solved!
Two points:
- Can I copy from one module to another while retaining relationships and history? I can in svn (as long as it's not an external) since svn doesn't care what you declare to be a "module".
- Last I checked, Submodules are broken to the point of being worse than svn:externals. A simple note in a wiki page for using submodules says, as if it didn't matter: "It's not safe to run "git submodule update" if you've made changes within a submodule. They will be silently overwritten". In my book that makes submodules unsuitable for any purpose. When I last investigated this problem it seemed that submodules were still considered to be in "dirty hack" status, and haven't yet been fully integrated into git.
Other points in your post, like claiming that editing directly on a remote share uses less bandwidth than sending periodic diffs, or that "don't worry, we all have a copy somewhere" is a valid backup strategy for a business, were ignored.
Git is like multimaster replication of a database, yeah. But in this example that's used as an alternative to /transactions/.
And it's not just a matter of "big enough", but basic organization. Would you rather tell someone who asks "where can I find this project?":
- this url: svn+ssh://path/to/repos/path/within/repos/foo; and that's all
- or, this url: ssh://path/to/master; "And within that you want the "foobar" directory. It'll be in there along with every other project that uses libfoo, since that's the only way to share things with libfoo and other projects when using git."
- or, this url: ssh://path/to/masterfoobar; and this one: ssh://path/to/masterlibfoo; and instructions on how to set them up manually
I understand "well then, don't do that!", but this pretty much just assumes that nobody will ever want two things, or not already be familiar with one thing, or that everybody /likes/ setting up PATH variables.
Your idea of a "brutal hack to do what svn does" would.. not at all do what svn does. I'm guessing you work only in a "/SingleProjectInARepos/{trunk,branches}" environment, and have never had to deal with maintaining a large repository which is useful to more than one person and useful to more than one person at a time.
I've been annoyed with svn's limitations before. A lot. I've in two jobs been in charge of maintaining SVN repositories, and /often/ wish that git were an option. But it just wasn't, for either. On one, due mainly to the limited (and various) systems we were working on. But I find it strangely coincidental that events conspired to put me in two situations where these needs, for whatever reason, existed. SVN was not ideal, and needed a lot of help to keep it going.
BUT: It could be made to work. It had ways worked out of doing what I needed to do, by people who were smarter than me. That information could be found online easily. Subversion's difficulties often amounted to needing to write good commit messages. When SVN failed due to my own fuck-ups, it did so in a way which hurt no one, and was easily restored.
Git is apparently not mature enough to have these things worked out yet. When git fails, it can need arcane magicks to get it working right.
And because git encourages you to keep your "working" branches local, fucking up your local repository can mean a serious headache.
And I can go on and on, but I've done that already.
remote tracking branches are just branches which are easy to pull someone else's change into. This has nothing to do with sharing changes between different projects, sub-projects, etc. The "master" branch, unless I've gotten my terminology mixed up, is often a remote-tracking branch. ie: It's a thing you almost can't avoid using regularly in git anyway. It is unrelated to any post I have made on the subject, other than being the place where some of the features I yearn for would need to be added.
Why worry about those claiming to be an existing well-known social networking site? It's already common practice for these places to, no impostering involved, ask for login details of completely unrelated sites when you sign up. That should _NOT_ be considered in any way okay, even from a site you "trust".
And then there's OpenID or whatever it's called, which basically says "make it not just disturbingly common, but recommended!" wtf?
We know from random statistics of crashes involving cars which are supposedly equipped with airbags capable of deploying during an accident that a high percentage of all "untested airbag readiness" (UAR from here on) cars actually do have airbags. The risk of these not deploying is low.
Meanwhile, however magically, we know that car X's airbag will _not_ work in an accident. The risk in driving that car is high.
If X is also a UAR car, the risk is identical.
If X is known to be defective, the risk is greater.
If X is known, however magically, to not be defective, the risk is higher.
Unless you're an infant in the front seat.
I use SVN and don't keep the history in one place, I only /access/ it from one place. Having history in EVERY copy that accesses it is like copying an entire relational database to every client that accesses it.
using --depth doesn't just "limit" what you can do, it turns git into a retard. Not having the ability to say "hmm, actually, I need that too. Go fetch it." without using low-level operations is brain-dead.
As for "it's possibly to rewrite history", yes, I said that. Git solves the problems involved in rewriting history by ignoring those problems, which I personally think is just fine. The problem is that if you're pulling from some other repository which /hasn't/ decided that the 2GigsOfCachedStatistics folder belongs somewhere else, you can't just tell git not to pull it. Git only operates on an entire deep tree at a time.
This is just the SVN "directory structure is good enough to keep track of any type of change" mentality which Linus calls "brain dead", but.. well, it works, and git doesn't.
All expected to be fixed in a future release, I hope.
Can you elaborate on this?
The specific scenario I use SVN for is where a single repository (not svn:externals, which I agree are broken, though for other reasons) has several related but independently developed projects, and a couple of "common" projects shared by all (mostly library-type functions). Using svn we can check out these individual folders easily, work on them independently, and ignore completely (ie: never check out) folders for projects we aren't involved in. It is possible and easy to copy files from one project to another, retaining history. I do this semi-regularly, for example when a "common" change necessitates the creation of a supporting object in several of the other projects, I create the common object, create the supporting object (which inherits from the common object), then copy+history that supporting object to the other projects which need it (making changes as I go).
I'd expect git, which seems to be all about decentralization, to at least have a similar option, perhaps retaining history (no clue how) when copying from one repository to another. I would expect that the ability for different "Open Source" projects to share code easily would be a priority, but I guess that's not the case.
Trying to learn git a few months ago, I started up a handful of projects which had some similar needs. I quickly learned that in git, things were either the same project or entirely unrelated, and that sharing common files between them would mean having an entirely separate library which I could commit changes to with about as much ease as an SVN:External. Less ease, really, as git chose to silently squash changes I made when a common command, through use of git submodules, turned lethal. Googling revealed that submodules were really just a clever hack at this point and that it would silently eat changes if you didn't use some specific and very-hack-feeling commands to update.
Perhaps git is only for completely-encapsulated projects (which is what I currently use it for- one shot scripts that I'd rather version than be sorry about), or for very very mature projects, which have already made all their decisions about what goes where, and who owns what. For starting a new project, where I wasn't sure what would be shared, what wouldn't, and what was truly related, I found git clunky and tedious.
being able to save checkpoints of your own work is NOT the same thing as having decentralized version control. It's just a feature of them.
Properly-managed centralized version control allows anyone to check in at any time.
Properly-written centralized version control software allows anyone to save checkpoints at any time without requiring access to the server.
If git would only allow a centralized model, it would be perfect.
Git's low-level design is simple enough that I'd say that was okay. It's very easy to grasp.
And then git ate my changes and overwrote a directory I was working on. So, maybe not.
So you're saying: "Your arguments against using git for these purposes are invalid because git is a poor choice for these purposes"?