By the major credit card companies for gross negligence and conspiracy for fraud.
No, the major credit card companies need to be sued by the entire US population for setting up the entire credit card processing system in this nation to be a sick a security joke. A plaintext number embossed on a plastic card available for every restaurant waiter to jot down? Give me a break.
The only piece of sensitive info used during a credit card transaction should be a private key that stays inside in a tamper-resistant chip embedded inside my credit card. Everything else should be encrypted, and not even seen by parties such as waiters or Target.
The text contains 100 characters. How much memory should I allocate for UTF8, without wasting memory?
If you try to allocate 100 characters, you're probably wasting something like 28 bytes on the heap without even knowing it. You could be wasting even more if your usage pattern fragments the heap.
In the real world, you just use a vector, waste about 33% of the space on average (not a huge deal), and move on. Moreover, you probably end up with fewer buffer overflow bugs by not doing hand-crafted buffer allocation.
- Build and maintain networks - Building data centres (construction) - Network management and services (ISPs, etc...) - IT support (hundreds of thousands of jobs and probably millions, small consultant companies and mom and pop shops) - Research has tremendously increase
Continued developments in server and infrastructure technology are introducing major efficiency, automation and density improvements that will significantly reduce the need for jobs in all but the last of those points. So you better start looking for the next trend now.
Whenever I try out a new language, one of the first things I do is implement the program described in the well-known paper by Lutz Prechelt: "An empirical comparison of C, C++, Java, Perl, Python, Rexx, and Tcl for a search/string-processing program". The program is not too big, but it gives a good feel for the features of a language and how fast it will run when you feed in a good-sized data set.
Over many years, I've done a couple of dozen implementations. However, I've found that the first impression after just learning a language may not be the best indicator. After getting very familiar with a language, I've found that I can sometimes write a much more elegant implementation than the first try.
Just like the "TPS reports" in Office Space, it doesn't really matter what the TLA actually stands for. Just from the context, you can infer enough about it to understand the point.
Of course user demand is, at least from a marketing PoV, important, but why the user demand for git over Hg? Both have technical pros and cons (and fortunately for both the dev teams compete with each other), but Hg has always had a much better command line user interface, better GUI integration, and was well designed from the ground up to be portable, as opposed to a pile of shell scripts and C programs to run on Linux. Arguably git's use on the Linux kernel is a factor, but why?
The network effect explains it. Git probably got an early boost of popularity because of who its author was. This initial momentum was enough to snowball into the most popular distributed RCS. Once it is established, learning curves and database lock-in create a barrier to other alternatives, and they apparently aren't currently "better enough" to prompt people to work through those barriers.
For example, even if Hg has a better CLI than git as you say, I'm sure that just learning and using just the git CLI is easier than filling one's head with both git and Hg knowledge. (In a similar circumstance, I currently have to use both yum and apt. They have similar concepts but different CLIs, and now I have to use a cheat sheet to run almost any command on either one. If I only used one or the other, I could probably keep the common commands straight in my head.)
I doubt that git is going to get knocked out of prominence until someone invents the next major concept in version control. This has happened before: both when Subversion surpassed CVS in buzz factor, and when git surpassed Subversion.
One reason the resistive heat costs 3X the gas heat is because they have to burn about 3X the amount of fuel to actually get the same amount of energy into your house via electrons. A heat pump takes advantage of thermodynamics to reverse that 3X penalty and achieve approximate parity with gas; someobdy who thinks that a light bulb is a good way to heat their house just pays the penalty. As they say, a fool and his money are soon parted.
On average, to deliver that 95W of thermal energy to your house, about 175W of thermal energy is wasted up the cooling towers and smokestacks of the power station. This is due to the thermodynamic losses involved in converting heat energy to mechanical energy. (A few high-tech power stations are somewhat more efficient, but electricity is a fungible commodity that is freely traded, so it doesn't really help if you happen to live near one. And hydroelectric dams, which don't have these thermodynamic conversion losses, are nevertheless environmental disasters in their own right.)
In contrast, a modern gas furnace can waste as little as 5W out the vent to deliver that same 95W of thermal energy into your house.
You have a standard power conditioner unit installed next to your electrical service panel inside your house. It will also protect your TV and computer and other electronic equipment, which are all apparently under a dire threat of zapping out even as we speak.
Nice try at being a smartass, but you fail it. It's not cheaper. The lightbulb costs much more, and once you replace a lightbulb that gives off 1000 lm of light and 100W of heating with a lightbulb that gives 1000 lm of light and 5W of heating you'll have to turn up heating by 95W. Or do liberals think that this energy comes from unicorns?
No, but a lot of liberals know the laws of thermodynamics, which essentially say that chemical and thermal energy go into one bin, and electrical and mechanical energy go into another. These two bins can not be compared directly the way you did in your conservative rant.
Research shows that there is good news and bad news on this approach.
The good news: Certain SQL queries can get a massive speedup by using a GPU.
The bad news: Only a small subset of queries got any benefit. They generally looked like this:
SELECT pixels FROM characters JOIN polygons JOIN textures ON characters.character_id = polygons.character_id WHERE characters.name = 'orc-wielding-mace' AND textures.name = 'heavy-leather-armor' AND color_theme = 'green' ORDER BY y, x
Assuming that Chinese health authorities have their priorities straight, that must mean that eating US corn is more dangerous than breathing the air in Beijing. This is worrisome!
While MD5 isn't really secure against intentional attacks any more, the probability of an random collision is still negligible.
I originally started using MD5 for this purpose because in a test I did many years ago one some machine, md5sum actually ran faster than cksum. The shorter cksum data also does have a chance to generate hash collisions on reasonable sized data sets, although that probably doesn't matter too much for just disk error checking. I don't use the newer algorithms because they're overkill and their hash strings just look too long.
It's always good to run md5sum --check right after copying or burning the data. In the past, at least a couple of percent of all the DVDs that I've burned had some kind of immediate data error
(A while back, I rescanned a couple of hundred old DVDs that I burned ranging up to 10 years old, and I didn't find a single additional data error. I think that a lot of cases where people report that DVDs deteriorate over time, they never had good data on them in the first place and only discover it later.)
In the context of FAT file systems, "short file names" has a very specific technical meaning. It's a name of exactly 8.3 upper case ASCII letters which is baked into the file system format.
We're not talking about just using short strings for the arbitrary file names supported by modern file systems. Your data set wouldn't even begin to fit on an old DOS machine that only understands short FAT filenames.
You typically need cooling water to efficiently generate electricity, no matter what source of heat is used to drive the boilers. You have to be able to condense the steam coming from the turbines to create a near vacuum, which requires a vast heat sink. That's why coal-fired stations are also often put next to rivers or lakes.
You wouldn't forego the interoperability. It's fine to continue using FAT.
I was simply saying that the patent system should be changed so that the patent on the short file name feature should have been revoked long ago (even if it had not been found to be obvious), due to the fact that nobody needs to interoperate with DOS machines any more, which was the original point of the invention. Having to use the patented feature so that FAT can interoperate with FAT is just a tautology that provides no benefit to a patent licensee. Thus, people should be free to use FAT today without worrying about this patent.
I would like to pretend that DOS is not still with us today, but that would be false. There's still people out there using short file names today. They're useful to someone.
Ok, so there are a few embedded industrial controllers still running DOS, and a few dorks running retro games in their moms' basements.
That doesn't mean that any of them are loading media files off of today's hardware gadgets into these relics. (In fact, a single one of these media files typically exceeds the entire addressable storage capacity of a DOS machine.) Yet Microsoft extracts royalties from the gadget manufacturers as if compatibility with short file names were an essential feature of the media libraries of everybody on the planet.
One of the important requirements for a patentable invention is that it must be "useful".
This patent originally covered a way to provide compatibility between short and long file names. But nobody has used short file names in decades.
So now, the "feature" continues to be necessary only so that FAT can provide compatibility with itself. That's like begging the question. The feature no longer has any intrinsic usefulness, and in fact just serves to make the file system format more convoluted and less efficient.
The patent system ought to be changed so that any patent should be revoked once it is no longer useful for its intended purpose. This particular patent has recently been "useful" solely as a way to give Microsoft leverage in the media device market. The covered feature provides zero benefit to end users.
What they *should* be saying is not to consume poisons, or not to consume sufficient volumes of the good stuff that it becomes poisonous. Neither of these has anything at all to do with the level of processing involved.
They don't in theory.
In reality, the two are very highly correlated. So in the real world, for real people, the advice about processed foods is valid.
Slashdot Mirror
By the major credit card companies for gross negligence and conspiracy for fraud.
No, the major credit card companies need to be sued by the entire US population for setting up the entire credit card processing system in this nation to be a sick a security joke. A plaintext number embossed on a plastic card available for every restaurant waiter to jot down? Give me a break.
The only piece of sensitive info used during a credit card transaction should be a private key that stays inside in a tamper-resistant chip embedded inside my credit card. Everything else should be encrypted, and not even seen by parties such as waiters or Target.
The text contains 100 characters.
How much memory should I allocate for UTF8, without wasting memory?
If you try to allocate 100 characters, you're probably wasting something like 28 bytes on the heap without even knowing it. You could be wasting even more if your usage pattern fragments the heap.
In the real world, you just use a vector, waste about 33% of the space on average (not a huge deal), and move on. Moreover, you probably end up with fewer buffer overflow bugs by not doing hand-crafted buffer allocation.
- Build and maintain networks
- Building data centres (construction)
- Network management and services (ISPs, etc...)
- IT support (hundreds of thousands of jobs and probably millions, small consultant companies and mom and pop shops)
- Research has tremendously increase
Continued developments in server and infrastructure technology are introducing major efficiency, automation and density improvements that will significantly reduce the need for jobs in all but the last of those points. So you better start looking for the next trend now.
Whenever I try out a new language, one of the first things I do is implement the program described in the well-known paper by Lutz Prechelt: "An empirical comparison of C, C++, Java, Perl, Python, Rexx, and Tcl for a search/string-processing program". The program is not too big, but it gives a good feel for the features of a language and how fast it will run when you feed in a good-sized data set.
Over many years, I've done a couple of dozen implementations. However, I've found that the first impression after just learning a language may not be the best indicator. After getting very familiar with a language, I've found that I can sometimes write a much more elegant implementation than the first try.
Just like the "TPS reports" in Office Space, it doesn't really matter what the TLA actually stands for. Just from the context, you can infer enough about it to understand the point.
Of course user demand is, at least from a marketing PoV, important, but why the user demand for git over Hg? Both have technical pros and cons (and fortunately for both the dev teams compete with each other), but Hg has always had a much better command line user interface, better GUI integration, and was well designed from the ground up to be portable, as opposed to a pile of shell scripts and C programs to run on Linux. Arguably git's use on the Linux kernel is a factor, but why?
The network effect explains it. Git probably got an early boost of popularity because of who its author was. This initial momentum was enough to snowball into the most popular distributed RCS. Once it is established, learning curves and database lock-in create a barrier to other alternatives, and they apparently aren't currently "better enough" to prompt people to work through those barriers.
For example, even if Hg has a better CLI than git as you say, I'm sure that just learning and using just the git CLI is easier than filling one's head with both git and Hg knowledge. (In a similar circumstance, I currently have to use both yum and apt. They have similar concepts but different CLIs, and now I have to use a cheat sheet to run almost any command on either one. If I only used one or the other, I could probably keep the common commands straight in my head.)
I doubt that git is going to get knocked out of prominence until someone invents the next major concept in version control. This has happened before: both when Subversion surpassed CVS in buzz factor, and when git surpassed Subversion.
They're not equivalent at all.
One reason the resistive heat costs 3X the gas heat is because they have to burn about 3X the amount of fuel to actually get the same amount of energy into your house via electrons. A heat pump takes advantage of thermodynamics to reverse that 3X penalty and achieve approximate parity with gas; someobdy who thinks that a light bulb is a good way to heat their house just pays the penalty. As they say, a fool and his money are soon parted.
On average, to deliver that 95W of thermal energy to your house, about 175W of thermal energy is wasted up the cooling towers and smokestacks of the power station. This is due to the thermodynamic losses involved in converting heat energy to mechanical energy. (A few high-tech power stations are somewhat more efficient, but electricity is a fungible commodity that is freely traded, so it doesn't really help if you happen to live near one. And hydroelectric dams, which don't have these thermodynamic conversion losses, are nevertheless environmental disasters in their own right.)
In contrast, a modern gas furnace can waste as little as 5W out the vent to deliver that same 95W of thermal energy into your house.
No, Einstien.
You have a standard power conditioner unit installed next to your electrical service panel inside your house. It will also protect your TV and computer and other electronic equipment, which are all apparently under a dire threat of zapping out even as we speak.
How hard is this to understand?
Nice try at being a smartass, but you fail it. It's not cheaper. The lightbulb costs much more, and once you replace a lightbulb that gives off 1000 lm of light and 100W of heating with a lightbulb that gives 1000 lm of light and 5W of heating you'll have to turn up heating by 95W. Or do liberals think that this energy comes from unicorns?
No, but a lot of liberals know the laws of thermodynamics, which essentially say that chemical and thermal energy go into one bin, and electrical and mechanical energy go into another. These two bins can not be compared directly the way you did in your conservative rant.
so figure 90kwh/year per light bulb that you're running five hours a day. That's ~$2/year at typical current rates.
Only if you can get your power at 2.2 cents/kWh. In most places, it would cost $9 to $12 per year to run a 60W incandescent that much.
Research shows that there is good news and bad news on this approach.
The good news: Certain SQL queries can get a massive speedup by using a GPU.
The bad news: Only a small subset of queries got any benefit. They generally looked like this:
SELECT pixels FROM characters JOIN polygons JOIN textures
ON characters.character_id = polygons.character_id
WHERE characters.name = 'orc-wielding-mace' AND textures.name = 'heavy-leather-armor' AND color_theme = 'green'
ORDER BY y, x
Assuming that Chinese health authorities have their priorities straight, that must mean that eating US corn is more dangerous than breathing the air in Beijing. This is worrisome!
While MD5 isn't really secure against intentional attacks any more, the probability of an random collision is still negligible.
I originally started using MD5 for this purpose because in a test I did many years ago one some machine, md5sum actually ran faster than cksum. The shorter cksum data also does have a chance to generate hash collisions on reasonable sized data sets, although that probably doesn't matter too much for just disk error checking. I don't use the newer algorithms because they're overkill and their hash strings just look too long.
I never archive any significant amount of data without first running this script at the top:
find -type f -not -name md5sum.txt -print0|xargs -0 md5sum >> md5sum.txt
It's always good to run md5sum --check right after copying or burning the data. In the past, at least a couple of percent of all the DVDs that I've burned had some kind of immediate data error
(A while back, I rescanned a couple of hundred old DVDs that I burned ranging up to 10 years old, and I didn't find a single additional data error. I think that a lot of cases where people report that DVDs deteriorate over time, they never had good data on them in the first place and only discover it later.)
In the context of FAT file systems, "short file names" has a very specific technical meaning. It's a name of exactly 8.3 upper case ASCII letters which is baked into the file system format.
We're not talking about just using short strings for the arbitrary file names supported by modern file systems. Your data set wouldn't even begin to fit on an old DOS machine that only understands short FAT filenames.
You typically need cooling water to efficiently generate electricity, no matter what source of heat is used to drive the boilers. You have to be able to condense the steam coming from the turbines to create a near vacuum, which requires a vast heat sink. That's why coal-fired stations are also often put next to rivers or lakes.
You wouldn't forego the interoperability. It's fine to continue using FAT.
I was simply saying that the patent system should be changed so that the patent on the short file name feature should have been revoked long ago (even if it had not been found to be obvious), due to the fact that nobody needs to interoperate with DOS machines any more, which was the original point of the invention. Having to use the patented feature so that FAT can interoperate with FAT is just a tautology that provides no benefit to a patent licensee. Thus, people should be free to use FAT today without worrying about this patent.
Sorry, but I'm unable to parse your question in its entirety, nor do I see how any of its fragments are relevant to the discussion.
I would like to pretend that DOS is not still with us today, but that would be false. There's still people out there using short file names today. They're useful to someone.
Ok, so there are a few embedded industrial controllers still running DOS, and a few dorks running retro games in their moms' basements.
That doesn't mean that any of them are loading media files off of today's hardware gadgets into these relics. (In fact, a single one of these media files typically exceeds the entire addressable storage capacity of a DOS machine.) Yet Microsoft extracts royalties from the gadget manufacturers as if compatibility with short file names were an essential feature of the media libraries of everybody on the planet.
Whether it's relevant any more or not is neither here nor there.
I was arguing that it should be.
If I invent a way to make a clockwork mechanism work more efficiently, that's still an invention, still patentable.
And it's useful to someone. People still buy mechanical timekeeping devices, often at a very high price premium.
Short file names aren't useful to anyone in this day and age.
The network effect is similar to begging the question.
Something is popular because it's popular.
One of the important requirements for a patentable invention is that it must be "useful".
This patent originally covered a way to provide compatibility between short and long file names. But nobody has used short file names in decades.
So now, the "feature" continues to be necessary only so that FAT can provide compatibility with itself. That's like begging the question. The feature no longer has any intrinsic usefulness, and in fact just serves to make the file system format more convoluted and less efficient.
The patent system ought to be changed so that any patent should be revoked once it is no longer useful for its intended purpose. This particular patent has recently been "useful" solely as a way to give Microsoft leverage in the media device market. The covered feature provides zero benefit to end users.
- and who will guard the guards themselves?
What they *should* be saying is not to consume poisons, or not to consume sufficient volumes of the good stuff that it becomes poisonous. Neither of these has anything at all to do with the level of processing involved.
They don't in theory.
In reality, the two are very highly correlated. So in the real world, for real people, the advice about processed foods is valid.