You can only split a subdirectory out into its own project if it's not related. If changes ever cross the boundary, you want history. If you just want to point someone to a single place for a checkout, you want the versioning system to have some notion of that.
Meanwhile: Burning a DVD is possibly slower or faster depending on the situation. It's a pretty stupid option either way, though. In this day, any time you're in a situation where using physical media is a better option, you've got a broken protocol. If I don't/want/ 12GB of history for images I'm not using (even if someone else might), I should not have that data at all.
I really think it would be much better and make a lot of people happier if git would just allow a shallow checkout which asked the server for more if needed (and that server can do the same from its origin if it doesn't have it either). Give people the option of setting up servers to do history processing for people who only want a shallow copy for 99% of the work they're doing. And if I want to check out "all history up to version 2.0, but nothing earlier than that", that would likely satisfy absolutely everyone for every day-to-day work anyone ever actually does.
Pulling entire histories is _always_ asking for trouble down the line. Subversion has the fatal flaw of keeping track of everything forever, even if no one wants it anymore (google "svn obliterate" for discussions). git solves this problem by simply not caring about the ramifications, but if the primary repository deems something necessary, EVERYONE gets it. At least with svn the problem is server-side-only.
git makes branching and merging easy enough that the question of "where is the central line?" isn't really an issue- developers can easily work on their own branches without worrying about other branches, and you can still push your developer branch to the central repository so that the question of "Where is this change? Is it in Steve's branch? Do I need to connect to his repository?" is also not an issue- Steve's branch can easily be in the central repository, Steve just needs to push changes in, just like he'd normally need to commit changes. Git's primary difference there is that "Steve's repository" is pretty much just a robust staging area for changes.
However, if you're used to centralized version control, you may miss things switching to git:
- Pick whether you want all or nothing in advance. You can either have "shallow" checkouts, which leave you with a crippled, broken, and useless copy that has no access to history functions, or you can have every change ever made. Once you've made this choice, you can only change your mind by cloning again. There is no way to gracefully get history as it is required.
- This means: no partial checkouts. This is a problem if you're used to versioning large binary files, or have large files which you won't care about for anything other than auditing reasons after a certain time.
- Which also implies: no "modules". This is a problem if you have lots of small related projects, which together make up one massive pool of code. You can have one massive project which everyone uses all of, or you can choose not to track the origin of files which you copy from one project to another. Having a "common" project shared by several others is not possible.
- Unless you try the "submodule" support, which is a broken hack that can devour changes far too easily to trust it to end-users. And submodule support does NOT allow copies from one "submodule" to another, or to your main project. Not while retaining history, anyway.
This is really all one flaw, re-stated five times. Fix this and git will be able to replace any centralized system. Without the change, I can't recommend it to anyone who is involved in a centralized project- at least not when there is a reason for being centralized.
Git is, despite proponent's claims, great for small projects which don't actually need to talk to anyone else and don't need to interface with any other projects. If your project involves other "projects" where the line between one and another is the least bit blurry, avoid git.
Now people can move through as if they weren't being screened at all, as opposed to just being delayed and harassed and having their bags checked as if they weren't being screened at all.
2021: With no change in effectiveness of security measures since introduction of the "just walk through and don't bother being screened" system, the whole thing is declared a success. Thousands of unionized screeners at airports across the country continue to receive paychecks until 2221.
how is a rating system ever anything other than "black and white"? Even when it classifies things exactly how YOU might classify them, it's done so in a black and white fashion which others may not agree with. Rating systems are a sign that culture needs to take the stick out of its ass and get rid of the belief that it's not only okay to never be offended, but to be expected.
Sometimes you'll see something you object to. You can choose not to click "view next image", but saying you can choose not to accidentally ever be exposed to anything similar is just feeding the flames.
Most big businesses do not do the majority of their "business" inside their customer-facing buildings, they do them in one of two to five large office buildings around the world. The majority of "bankers" (ie: not just customer service reps) work in these few buildings, and in a world where not every person dealing with a customer also knows the first thing about banking, there are fewer bankers now than their used to be.
you seem to have forgotten that little "be bold" thing. It's always easier and usually better to implement first and ask questions later. Good ideas will be adopted by others, bad ideas won't have wasted everyone else's time in discussions which lead to nowhere.
two seconds of googling (thanks for the query string) told me that this is a problem with dhcpd, not ipchains/iptables/linux
complaining that it's possible for software to "ignore rules" by processing raw input is like complaining that it's possible for software to "ignore permissions" by writing directly to/dev/hda. It's running as root, it's okay that this is allowed. This doesn't sound like an operating system flaw, it sounds like a dhcpd flaw.
You have stated something which is either a fact or is not a fact, then followed it with "IMO". This makes your sentence meaningless. Maybe you meant "PF is also much more readable than ipchains. Clarity in configuring things with fewer options usually results on more secure setups than configurations which have more options but that you need to understand them in order to read the config. Unless it doesn't, I can't be bothered to check."
You seem to be under the illusion that lazy people should not be able to use computers, that computers are not in fact a tool for the lazy to make their lives easier. I submit that you are an idiot.
ssh has alternatives to passwords. Use them. If you can't disable password-based authentication, set your password to a random 128 character string ( head/dev/urandom | sha512sum, for example- though while you can definitely type this easily, some "password checkers" say that this is not secure and reject it ). You don't need to write this password down, as long as you've set up your key.
as opposed to lighting fire to rocks to create heat to boil water to create steam to turn turbines to move magnets to pull electrons to power capacitors (which are sometimes flywheels) to store extra power for peak times is so much worse than putting a flywheel in space.
The real problem with these things is that they describe what is generally considered to be "what is being done" rather than "how it is done."
If a patent were granted for "A method of lighting homes using electricity", it covers a lot more ground than "a method of lighting homes using electrically-heated coiled metal in a vacuum"
In general, it's better to say someone has limited monopoly on "this thing they built" than it is to do so for "this idea they had", even if they built a thing based on the idea.
Someone steals from the phone company using someone else's phone, and it's the someone else who needs to pay?
Say there's a water main and a pipe running off it to someone's house. Unscrupulous fiend taps into it. If he taps into the part closest to the street, it's a clear case of that person stealing from the water company and they're stuck with the problem. If he makes his hole six inches to the left, the water company gets to send a bill? How is that sane?
There are two actual motivations:
- Being able to charge $40 for a hunk of plastic and metal bits worth 50 cents is a nice pool of free money
- Not having to replace your customer's expensive devices after they fry them with a charger they bought at radio shack for 40 cents and don't admit it, is already worth more than negative $39.60
Just because you keep the list of possible actions in your head instead of in a menu doesn't make it any less brute force playing a text adventure. It's game quality, not format, which reduces the appearance of "brute force" nature.
"stick string into clay" after trying everything else is no less brute force than clicking on the string, then clicking on the clay, then selecting from "stick, tie to, cut with, " etc.
The only difference is in one, you get to see instantly what the developer hasn't thought of, while in the other you need to go through a list of perfectly logical options before realizing the developer is making a pun, etc.
Slashdot Mirror
You can only split a subdirectory out into its own project if it's not related. If changes ever cross the boundary, you want history. If you just want to point someone to a single place for a checkout, you want the versioning system to have some notion of that.
Meanwhile: Burning a DVD is possibly slower or faster depending on the situation. It's a pretty stupid option either way, though. In this day, any time you're in a situation where using physical media is a better option, you've got a broken protocol. If I don't /want/ 12GB of history for images I'm not using (even if someone else might), I should not have that data at all.
I really think it would be much better and make a lot of people happier if git would just allow a shallow checkout which asked the server for more if needed (and that server can do the same from its origin if it doesn't have it either). Give people the option of setting up servers to do history processing for people who only want a shallow copy for 99% of the work they're doing. And if I want to check out "all history up to version 2.0, but nothing earlier than that", that would likely satisfy absolutely everyone for every day-to-day work anyone ever actually does.
Pulling entire histories is _always_ asking for trouble down the line. Subversion has the fatal flaw of keeping track of everything forever, even if no one wants it anymore (google "svn obliterate" for discussions). git solves this problem by simply not caring about the ramifications, but if the primary repository deems something necessary, EVERYONE gets it. At least with svn the problem is server-side-only.
git makes branching and merging easy enough that the question of "where is the central line?" isn't really an issue- developers can easily work on their own branches without worrying about other branches, and you can still push your developer branch to the central repository so that the question of "Where is this change? Is it in Steve's branch? Do I need to connect to his repository?" is also not an issue- Steve's branch can easily be in the central repository, Steve just needs to push changes in, just like he'd normally need to commit changes. Git's primary difference there is that "Steve's repository" is pretty much just a robust staging area for changes.
However, if you're used to centralized version control, you may miss things switching to git:
- Pick whether you want all or nothing in advance. You can either have "shallow" checkouts, which leave you with a crippled, broken, and useless copy that has no access to history functions, or you can have every change ever made. Once you've made this choice, you can only change your mind by cloning again. There is no way to gracefully get history as it is required.
- This means: no partial checkouts. This is a problem if you're used to versioning large binary files, or have large files which you won't care about for anything other than auditing reasons after a certain time.
- Which also implies: no "modules". This is a problem if you have lots of small related projects, which together make up one massive pool of code. You can have one massive project which everyone uses all of, or you can choose not to track the origin of files which you copy from one project to another. Having a "common" project shared by several others is not possible.
- Unless you try the "submodule" support, which is a broken hack that can devour changes far too easily to trust it to end-users. And submodule support does NOT allow copies from one "submodule" to another, or to your main project. Not while retaining history, anyway.
This is really all one flaw, re-stated five times. Fix this and git will be able to replace any centralized system. Without the change, I can't recommend it to anyone who is involved in a centralized project- at least not when there is a reason for being centralized.
Git is, despite proponent's claims, great for small projects which don't actually need to talk to anyone else and don't need to interface with any other projects. If your project involves other "projects" where the line between one and another is the least bit blurry, avoid git.
Now people can move through as if they weren't being screened at all, as opposed to just being delayed and harassed and having their bags checked as if they weren't being screened at all.
2021: With no change in effectiveness of security measures since introduction of the "just walk through and don't bother being screened" system, the whole thing is declared a success. Thousands of unionized screeners at airports across the country continue to receive paychecks until 2221.
I'll try to re-state, as you've completely missed the point:
Saying "This movie is definitely badness-level [0-3]" is no less black-and-white than saying "This movie is definitely badness-level [0-1]".
And aren't we talking about different groups of ADULTS who disagree with what they find objectionable?
how is a rating system ever anything other than "black and white"?
Even when it classifies things exactly how YOU might classify them, it's done so in a black and white fashion which others may not agree with. Rating systems are a sign that culture needs to take the stick out of its ass and get rid of the belief that it's not only okay to never be offended, but to be expected.
Sometimes you'll see something you object to. You can choose not to click "view next image", but saying you can choose not to accidentally ever be exposed to anything similar is just feeding the flames.
mostly, yeah.
You seem to think computers operate using a combination of "processors" and "magic". You are mistaken.
So you haven't forgotten. Your proof is to provide a somewhat-related link to wikipedia and provide no further comment.
Well, shit, I guess I haven't forgotten anything about programming in C++, in that case. I'll prove it: http://en.wikipedia.org/wiki/Unix
Most big businesses do not do the majority of their "business" inside their customer-facing buildings, they do them in one of two to five large office buildings around the world. The majority of "bankers" (ie: not just customer service reps) work in these few buildings, and in a world where not every person dealing with a customer also knows the first thing about banking, there are fewer bankers now than their used to be.
4.28 micro-Amps
you seem to have forgotten that little "be bold" thing. It's always easier and usually better to implement first and ask questions later. Good ideas will be adopted by others, bad ideas won't have wasted everyone else's time in discussions which lead to nowhere.
3) Share openly so everyone can use your enhanced products
two seconds of googling (thanks for the query string) told me that this is a problem with dhcpd, not ipchains/iptables/linux
complaining that it's possible for software to "ignore rules" by processing raw input is like complaining that it's possible for software to "ignore permissions" by writing directly to /dev/hda. It's running as root, it's okay that this is allowed. This doesn't sound like an operating system flaw, it sounds like a dhcpd flaw.
You have stated something which is either a fact or is not a fact, then followed it with "IMO". This makes your sentence meaningless. Maybe you meant "PF is also much more readable than ipchains. Clarity in configuring things with fewer options usually results on more secure setups than configurations which have more options but that you need to understand them in order to read the config. Unless it doesn't, I can't be bothered to check."
You seem to be under the illusion that lazy people should not be able to use computers, that computers are not in fact a tool for the lazy to make their lives easier. I submit that you are an idiot.
-- Some lazy guy
ssh has alternatives to passwords. Use them. If you can't disable password-based authentication, set your password to a random 128 character string ( head /dev/urandom | sha512sum, for example- though while you can definitely type this easily, some "password checkers" say that this is not secure and reject it ). You don't need to write this password down, as long as you've set up your key.
as opposed to lighting fire to rocks to create heat to boil water to create steam to turn turbines to move magnets to pull electrons to power capacitors (which are sometimes flywheels) to store extra power for peak times is so much worse than putting a flywheel in space.
The real problem with these things is that they describe what is generally considered to be "what is being done" rather than "how it is done."
If a patent were granted for "A method of lighting homes using electricity", it covers a lot more ground than "a method of lighting homes using electrically-heated coiled metal in a vacuum"
In general, it's better to say someone has limited monopoly on "this thing they built" than it is to do so for "this idea they had", even if they built a thing based on the idea.
congratulations! You ALMOST got the joke!
Someone steals from the phone company using someone else's phone, and it's the someone else who needs to pay?
Say there's a water main and a pipe running off it to someone's house. Unscrupulous fiend taps into it. If he taps into the part closest to the street, it's a clear case of that person stealing from the water company and they're stuck with the problem. If he makes his hole six inches to the left, the water company gets to send a bill? How is that sane?
There are two actual motivations:
- Being able to charge $40 for a hunk of plastic and metal bits worth 50 cents is a nice pool of free money
- Not having to replace your customer's expensive devices after they fry them with a charger they bought at radio shack for 40 cents and don't admit it, is already worth more than negative $39.60
And due to this fear, you've never purchased online content in your life. If you had, you would know that this is not an issue and never has been.
DRM is a separate issue, and remains an issue with or without internet access.
sounds like your OCR is a bit lame if it can't read a bunch of fixed-width completely invariant characters.
...yes we do. We have DVRs just like the rest of the 1st world
Just because you keep the list of possible actions in your head instead of in a menu doesn't make it any less brute force playing a text adventure. It's game quality, not format, which reduces the appearance of "brute force" nature.
"stick string into clay" after trying everything else is no less brute force than clicking on the string, then clicking on the clay, then selecting from "stick, tie to, cut with, " etc.
The only difference is in one, you get to see instantly what the developer hasn't thought of, while in the other you need to go through a list of perfectly logical options before realizing the developer is making a pun, etc.