As has been debunked I'm sure hundreds of times before on Slashdot, I will debunk this falsehood once again. The number of writes is not a limiting factor in the life cycle of a modern flash drive. It was a limiting factor 10-ish years ago, but it is not now. Even if you swapped to a modern flash drive constantly at maximum throughput and the drive was completely full except for one block (the worst possible scenario for a flash drive), it would conservatively last for at least 60 years (if I remember right). Maybe modern drives are now into the hundreds of years.
I'm not saying a flash drive will last 60 years. I'm saying the number of writes is not the limiting factor. Wear levelling and block moving (the nice thing about flash is you can relocate a rather static block of memory somewhere else, since it's all random-access) algorithms are to the point where the number of writes is not a limiting factor. Once again, write and swap and rewrite as much as you like to a modern flash drive. The number of writes is not a limiting factor.
I'm starting to think early flash drives will have the same effect of rechargeable batteries. When people think of rechargeable batteries, they too often think of the ones from yesteryear with a limited number of recharges and that awful "charge memory". So too it seems with flash drives. Even otherwise informed people seem to think that writing to a flash drive some billions of times will somehow have a deleterious effect. It won't.
Dude, if some thief threatened to cut my fingers off, I'd give him the damn password. If there's anything in your life right now that's password protected and worth more than your fingers, you're living your life wrong.
If it ain't broke, don't fix it. This is what the article is talking about.
Change for the sake of change. I can't see too many people going along with this unless they're morons and/or fanboys.
Change when the benefits outweigh the drawbacks. I assume most people fit into this category. What I never thought about before reading comment is that there's a further distinction in this case. I'll speak for myself, though I assume a lot of people are like me, will switch to something better even if it takes a long time to learn the new thing. I.e., when I'm weighing the benefits vs. drawbacks of switching to something new, I don't consider the cost of retraining myself. Maybe it's because I'm a geek (aka Slashdot reader) and retraining myself is fun.
Anyway I think I'll stick to my (ironically) old ways of switching to new things. After all, isn't the joy of life to be constantly learning new things?
It should be obvious that you can represent 10^80 things without 10^80 elementary particles
I'll accept that this is true.
for example, you just did, when you typed "10^80".:-)
This, however, is comically untrue. From an information theory standpoint, "10^80" contains just a couple bits (I'm too lazy to do the calculation to determine exactly how much information it contains). I'm sure you can appreciate that "a couple" is less than 10^80.
Our brains are another perfect example: between 50bil-150bil cells, a relatively small number (the transistors in a CPU are slowly approaching that point), capable of representing a virtually limitless interlocking, overlapping arrangement of information.
Here's an experiment for you: take a complete ignoramus, person A, and a wealth of information, person B. Give person A information to Wikipedia. No ask them random trivia questions and see who does better. Hypothesis: the brain is a terrible information storage medium. While it's great that the brain has interesting computational properties, that's not the topic at hand. The topic at hand is storing information. The brain is not terribly great at storing information.
While it may be possible to store multiple bits of information using a single particle (I don't know, I'm not a physicist), we're nowhere near being able to do that yet.
If, like the summary (but not the article for some reason) states, total data is growing by a factor of 10 every 5 years, then somewhere around the year 2300 we'll have 10^80 bits stored. The number of elementary particles in the known universe is estimated to be between 10^79 and 10^81. Seems we're kind of screwed at that point.
The Acid tests are, to put it kindly, perverse. They basically try to hit every corner case of the standards in the most convoluted way possible. I'm not saying 60% is adequate, but it's understandable for a browser that's under development.
I keep hearing this mantra, but I think a lot of it is a case of people looking at the past through rose-coloured glasses. Do people really think that software was more efficient in the days of the Commodore 64?
I remember in the late 1980s, a fair number of games for the PC would take at least 3 minutes to start up, just to initialize look-up tables and pre-render sprites! In the early 1990s, Netscape would literally take more than 45 minutes to start up on his PC. In the mid 1990s, I remember seeing, for the first time in my life, a game rendered at more than 30fps.
My point is, people are a lot less patient these days with computers. No one in their right mind is going to wait a minute for an application to start up, and certainly not 45 minutes for a browser!
If you want to know how bad software was in the 1980s, try to run some software from the 1980s. I used to think like you do, that software was incredibly efficient and incredibly well written in the 1980s. Then I tried to run some software from the 1980s. A game from the 1980s often runs slower on today's hardware than today's games do. There are all sorts of ill-conceived hard coded limits in old games. Take software from the 1980s and try to run it on data sets measuring in the gigabytes: no dice.
Again, people expect more from their software today than they did from yesteryear. I'm extremely suspicious of people who say that old software is more efficient/better written than today's software. I've used software from the C64 age. Guess what: IT SUCKED.
I don't understand what you mean. If I were to sum up Singularity in one idea, it would be its use of static analysis to ensure the stability of its components. Where does JNode use static analysis?
Besides, I thought that "NP-complete" was a pure math term. Since when has pure math had anything to do with physics?
Since Church's thesis, I would say, which is to say, since the beginning of computer science as a discipline.
Actually for a lot longer than that. Pure math has almost always been almost inseparable from physics. Would a particle exhibiting non-linear acceleration due to gravity violate the laws of physics? Regardless of whether this is true or not, a linear function is a "pure math" term, as you state it. Something being mathematical doesn't render it totally separate from physics.
Being able to solve an NP-complete problem in polynomial time is either physically possible or physically impossible. Period. We don't know which one yet because we don't understand the physics yet.
What the fuck?! I would outraged when this was at +4, but +5?!
NP-completeness relates to the scalability of the algorithm with the size of the input.
This is misleading. NP-completeness relates to how other problems can be reduced to it. Currently we can't say much about how NP-completeness and complexity relate. We know that if a problem is NP-complete, it must take at least polynomial time and at most exponential time (on a classical computer), but beyond that, we know nothing.
Quantum computers "solve" NP-complete questions in "Polynomial time"
This is factually incorrect. So far we have not found a quantum algorithm to solve any NP-complete problem in less than exponential time.
(actually constant time?)
Ha!
they also limit the size of the input significantly.
This is factually incorrect. Perhaps you're getting confused by the fact that quantum algorithms are often described in circuit notation. Classical algorithms are also sometimes described in circuit notation, but this is much less common. In any case, quantum algorithms do not bound the size of the input any more than classical computers do.
For instance, quicksort on a classical computer might be "bounded" in that you cannot sort an array of 50 billion petabytes. This is not inherent in the algorithm; it's inherent in our inability to construct a computer with 50 billion petabytes of memory. Similarly, we have not been able to use quantum computers to date to factor integers larger than 15. This limit is not inherent in the algorithm; it's inherent in the fact that engineers have not been able to construct a viable quantum computer to date with more than 5 (if I remember correctly) qubits.
Again, quantum algorithms to not bound the size of their input.
Since Quantum Computers seem to run on inputs of a specific size, O() notation does not seem to apply at all.
This is factually incorrect. Almost all of the research into quantum computation in the past 10 years has been in the area of quantum complexity. Perhaps you have heard of the BQP complexity class, which was mentioned in the article you were supposed to have read. By the way, BQP can in some way be thought of as quantum computers' "P"; i.e., the class of problems which can viably be computed on a quantum computer in polynomial time.
Quantum complexity very much uses big-O notation (as well as big- notation and any other complexity notation used in classical complexity theory).
So "solving" NP-complete problems cannot really violate laws of physics in this sense.
Non sequitur. It's not clear at this point. If you could answer that question, you'd probably be drowning in money right now.
It was a bad summary (surprise, surprise). Most of the article was crap, but I quite liked the ending, when he got into relativistic computing. Relativistic computing isn't exactly novel, but he gave a good survey of the problems it (doesn't) solve.
About 3 or 4 years ago, I installed Debian GNU/Hurd. Incidentally, Debian GNU/Hurd is infinitely easier to install than Debian GNU/Linux, and the hardware support was better as well. I'm not exactly sure how, as the Hurd was based on Linux 2.0's drivers as well, but it worked perfectly with my hardware when Debian GNU/Linux wouldn't.
My impessions of Debian GNU/Hurd was that it was very cool, very very fun, very unstable, and very slow.
I don't know that his suggestion that people complain after trying out a microkernel OS is a good one, as there are a lot of bad microkernel OSes out there. For what it's worth, I think Microsoft's direction with Singular is the Correct way to go: many of the advantages of a microkernel without many of the disadvantages (namely no context switches between parts of the kernel).
FYI, a number of compilers do define a long as 64 bits. It's called the LP64 model (longs and pointers are 64 bits long), and Microsoft and Linux/GCC follow it for 64-bit platforms, if I remember right. I've heard rumours of some compilers even following the ILP64 model (ints, longs and pointers are 64 bits long), though as I said before, I don't think that's the greatest idea.
Really? There are no (and will be no) 64-bit architectures where working with 32-bit ints isn't slower (due to needing to mask the value, or correctly do overflow, or...) than 64-bit ints?
Why would you need to mask anything? I think you misunderstand what an int being 32 bits means. That doesn't mean that it only uses 32 bits in the register. A 32 bit int can use 32 or 64 or 128 or 4096 bits in a register. There is absolutely no point in masking it in the register to keep it contained within 32 bits. Yes, it might start overflowing into the 33rd or 34th bits, or sign extend all the way into the 63rd bit. Who cares? That has no visible effect in the program.
What makes the int "32 bits" is when you start reading from or storing to memory. When you start pushing an int onto the stack, do you use a "st" (store word) or "std" (store double-word)? (Using SPARC's instructions). Aside from storing and loading, 32-bit and 64-bit arithmetic is exactly the same, even in 64-bit registers.
I'm less versed in x86-64, so I can't say conclusively that there are no performance penalties there for working with 32-bit data, but on SPARC and PowerPC at the least, a 64-bit int offers no performance advantage over a 32-bit int.
And "long" is perfectly capable of being defined as 64-bit and dealing with that need. But no-one defines "long" as 64 bits. Why might that be?
I am a C programmer. I need an integer which is at least 40 bits long. What do I use? A long? It's possible than a long is 40 bits long, but it's not guaranteed. Therein lies the difference.
People needed to start using 64-bit integers, but the compiler folks couldn't alter "long" to do that as all the existing code that relies on "long" being 32-bit would break.
That might be why compiler folks invented long long, but it is not why the C standard adopted long long. As I said before, people need a guarantee of an integer longer than 32 bits. long will never be guaranteed to be longer than 32 bits.
What happens when they want to add 128-bit numbers to the standard? Would you prefer that "long long long int" be added? Or does int128_t make a bit more sense?
You're thinking about this from the wrong perspective. If compiler writers want to add a 128-bit integer, they are perfectly within their right to make a long long, or a long, or an int, or a short, 128 bits in length. The standard is not there to satisfy compiler writers (okay I lie a little bit, but it's a mental exercise).
The standard is there to provide guarantees about what C programmers can expect. Do C programmers need a guarantee that, on all platforms, under all compilers, there is an integer type at least 128 bits long? If yes, then the C standard should add a type to support that (probably long long long). There are different mentalities behind the phrase "using a 128 bit integer".
One mentality is that just happens to be what the compiler gave you. You know, "I used long because I only required 32 bits, but the compiler gave me a 128-bit integer because it would be just as natural. Bonus!" In that light, it's obvious why compiler writers are so free to go beyond the requirements of the standard.
The other mentality is that you need a 128-bit integer. In that case, using a long is totally out of the question, no matter if your compiler provides a 128-bit integer or not. If you ever want your code to run with a different compiler, you have to use a new type (say long long long), because that's the only one that guarantees the length you need.
Oops there is a bug in my write_long. That's what I get for coding off the top of my head. Regardless of my bug, hopefully the sentiment still gets across that you only need to write these functions once, and it shouldn't be TOO hard to code them.
Also note that these functions will use for things like the PNG header or a TCP header. It's just a little more portable, that's all.
It is actually not difficult to portably read/write binary files. It may be a little time consuming, but you only have to do it once. For example:
void write_long(long x, FILE *f) { if (x < 0) write_long(~(-x), f); else { unsigned char c; c = (x & 0xff000000) >> 24; if (fwrite(&c, 1, 1, f) != 1) {... } c = (x & 0xff0000) >> 16; if (fwrite(&c, 1, 1, f) != 1) {... } c = (x & 0xff00) >> 8; if (fwrite(&c, 1, 1, f) != 1) {... } c = x & 0xff; if (fwrite(&c, 1, 1, f) != 1) {... } } }
And you'd need read_long, write_int, read_int, write_short, read_short, etc. etc. It relies on the fact that the C standard guarantees: characters are AT LEAST 8 bits; sizeof(char) = 1; longs are AT LEAST 32 bits in size. I force the value into 4 8-bit characters comprising a 32-bit 2's complement number, regardless of what underlying representation the architecture uses.
Yes, true, fwrite(&x, 4, 1, f) is more efficient, but not so conforming or portable:P
long long was added to create an integer which is at least 64 bits in size. It was created because people needed integers longer than 32 bits. It has nothing to do with people making assumptions.
I don't see why an int should be 64 bits wide on a 64-bit machine. It's not any faster; it doesn't save any cycles anywhere. The general rule of thumb is to use "long" if you need a long integer. Consequently, people who use int are (theoretically) doing so because they don't need a long integer. Seeing as there is no performance penalty, I think using 32-bit integers on a 64-bit machine is fairly prudent just for the memory savings.
You make a good point. The way I would look at it is in those cases you're already making assumptions (8-bit bytes, 2's complement, etc.), you may as well make some other assumptions. I guess the nice thing about int32_t and the such is that, in the cases where you are making these sorts of assumptions, you don't have to typedef these themselves. It saves a little bit of #ifdef hell.
Boolean does not mean "true or false". Boolean means any group which satisfies the boolean axioms. The real numbers between 0.0 and 1.0 are, in fact, very common boolean types. Typically the boolean operators are implemented as:
x AND y = xy (multiplication)
x OR y = x + y - xy
NOT x = 1.0 - x
Sorry, but it's just kind of a pet peeve of mine when people use "boolean" as a synonym for "true or false". Have none of you taken a course on boolean algebra?
These types are a huge abomination to C, as far as I'm concerned. There is no way to write standard C where the exact size of an integer is needed. My only hypothesis for why int64_t and int32_t and the like were included in the standard is to appease giant dumbasses who write integers directly to binary files, a practice which of course is not conforming to the standard.
The C integer types are, in fact, very logical, very useful, and very much your friend. Here's a quick guide:
If you need to store some portable task-specific value, then use the type provided for that purpose (e.g., time_t, size_t, intptr_t, ptrdiff_t,...)
Otherwise, by default, use int. An int is guaranteed to be the most "natural" size for your architecture (it's up to the compiler to determine what "natural" means, but just trust your compiler: use "int" unless you have a reason not to)
If you are storing massive arrays/structs and wish to save memory, and are confident your values won't fall below -32767 (note not -32768: the C standard does not guarantee 2's complement) or above 32767, then use short
If you are confident that your values will fall below -32767, or above 32767, then use a long
If you are confident that your values will fall below about -4 billion or above about 4 billion, then use a long long
The most important point: never just dump an integer into a binary file (as through fwrite). The most portable way to read and write files is through text, of course, as text is guaranteed to be portable by the C standard. This is not always practical, and in the real world binary files are needed, but make sure to write your data portably. Do not assume signed integer representation (e.g., 2's complement), do not assume exact integer sizes, and do not assume 8-bit bytes. None of these things is guaranteed by the standard.
The types mentioned above will do everything that the int64_t, int_least32_t, etc. types will provide. intmax_t seems equally useless. Contrary to the parent's suggestion, the C standard says nothing along the lines of intmax_t providing the largest int that an architecture can handle. What would that even mean? That it's the biggest int that can be stored in a register? Oops, I guess x86 can't have a 64-bit intmax_t then, eh? That it's the biggest int that the architecture can perform arithmetic on? Well then I guess on most architectures, intmax_t must be at least a couple billion bits in size, right? There's no meaningful definition of this sort can be used.
What the standard says about intmax_t is, and I quote, "The following type [intmax_t] designates a signed integer capable of representing any value of any signed integer". That's it. All it says is that an intmax_t can store any value from a signed char, short, int, long, or long long. In other words, as far as the standard is concerned, there is no difference between a long long and an intmax_t. And indeed, I would be very surprised if there were ever an architecture where intmax_t were not just a synonym for long long: after all, there is no way to write conforming C code where an intmax_t can be depended on to do anything that a long long won't.
So why would you ever use an intmax_t? You wouldn't. There's no reason to. If you're writing conforming code.
Please stop spreading FUD. An out-of-date flash drive, being written to CONSTANTLY (under MUCH harder conditions than just swapping) should last for no less than 51 years. For modern flash drives, that number should be in the hundreds of years.
This is not to say that flash drives last forever, or even that they last 51 years. This is to say that, no matter what you're doing, there is nothing in this world perverse enough you could be doing which will make a modern flash drive level out. As mentioned in a parent post, the limiting factor in flash drives these days is NOT how many writes it can do. It's probably not too hard to abuse a flash drive to render it useless, but writes are NOT the limiting factor.
I will remain pseudonymous, but I will say that my current area of research (I am a graduate student) is tangentially related to this field, related enough that I've looked into trying to convince GM to give me funding (so far nothing has materialized). Specifically my research looks deals with programming language design (e.g., making less-than-Turing-complete-but-still-useful programming languages structured in useful ways) to aid in static analysis. The aim is at safety-critical code (nuclear power plant code, industrial controller code, automotive software) such that you can say "barring hardware failure, this code is 100% guaranteed to meet hard realtime constraints", etc.
Anyway, at least publicly, GM is probably the most impressive car company in terms of researching these sorts of things. I feel kind of bad for GM. I hear they're selling terribly and are even selling at a loss on many cars, but their research department really is something impressive. Maybe they're a little bit Microsoft-ish in that their research department is heavily insulated from the rest of the company, I don't know. But GM is doing a lot of cool stuff and funding a lot of cool stuff with regards to "correct" software.
If it were some other random company, I would probably roll my eyes and say "oh they'll probably just test it really really heavily and then tell us that it works", but more than most companies, I trust GM to develop cool technology (such as novel static analysis techniques) to get this to work. Their R&D is active in a lot of areas, 99% I'm sure will never amount to anything, but I wouldn't doubt it if they could get the technology together to get auto-driving cars in 10 years.
Disclaimer: as I mentioned before, my efforts to get GM funding are still unsuccessful, and consequently I'm not on GM payroll in any imaginable way. I don't even drive a GM car (or any car). In fact their cars look kind of lame in general, but their R&D department in Cool.
Slashdot Mirror
As has been debunked I'm sure hundreds of times before on Slashdot, I will debunk this falsehood once again. The number of writes is not a limiting factor in the life cycle of a modern flash drive. It was a limiting factor 10-ish years ago, but it is not now. Even if you swapped to a modern flash drive constantly at maximum throughput and the drive was completely full except for one block (the worst possible scenario for a flash drive), it would conservatively last for at least 60 years (if I remember right). Maybe modern drives are now into the hundreds of years.
I'm not saying a flash drive will last 60 years. I'm saying the number of writes is not the limiting factor. Wear levelling and block moving (the nice thing about flash is you can relocate a rather static block of memory somewhere else, since it's all random-access) algorithms are to the point where the number of writes is not a limiting factor. Once again, write and swap and rewrite as much as you like to a modern flash drive. The number of writes is not a limiting factor.
I'm starting to think early flash drives will have the same effect of rechargeable batteries. When people think of rechargeable batteries, they too often think of the ones from yesteryear with a limited number of recharges and that awful "charge memory". So too it seems with flash drives. Even otherwise informed people seem to think that writing to a flash drive some billions of times will somehow have a deleterious effect. It won't.
Dude, if some thief threatened to cut my fingers off, I'd give him the damn password. If there's anything in your life right now that's password protected and worth more than your fingers, you're living your life wrong.
The way I see it, there are three cases:
Anyway I think I'll stick to my (ironically) old ways of switching to new things. After all, isn't the joy of life to be constantly learning new things?
I'll accept that this is true.
This, however, is comically untrue. From an information theory standpoint, "10^80" contains just a couple bits (I'm too lazy to do the calculation to determine exactly how much information it contains). I'm sure you can appreciate that "a couple" is less than 10^80.
Here's an experiment for you: take a complete ignoramus, person A, and a wealth of information, person B. Give person A information to Wikipedia. No ask them random trivia questions and see who does better. Hypothesis: the brain is a terrible information storage medium. While it's great that the brain has interesting computational properties, that's not the topic at hand. The topic at hand is storing information. The brain is not terribly great at storing information.
While it may be possible to store multiple bits of information using a single particle (I don't know, I'm not a physicist), we're nowhere near being able to do that yet.
If, like the summary (but not the article for some reason) states, total data is growing by a factor of 10 every 5 years, then somewhere around the year 2300 we'll have 10^80 bits stored. The number of elementary particles in the known universe is estimated to be between 10^79 and 10^81. Seems we're kind of screwed at that point.
The Acid tests are, to put it kindly, perverse. They basically try to hit every corner case of the standards in the most convoluted way possible. I'm not saying 60% is adequate, but it's understandable for a browser that's under development.
Fair enough, the Amiga was quite impressive.
I keep hearing this mantra, but I think a lot of it is a case of people looking at the past through rose-coloured glasses. Do people really think that software was more efficient in the days of the Commodore 64?
I remember in the late 1980s, a fair number of games for the PC would take at least 3 minutes to start up, just to initialize look-up tables and pre-render sprites! In the early 1990s, Netscape would literally take more than 45 minutes to start up on his PC. In the mid 1990s, I remember seeing, for the first time in my life, a game rendered at more than 30fps.
My point is, people are a lot less patient these days with computers. No one in their right mind is going to wait a minute for an application to start up, and certainly not 45 minutes for a browser!
If you want to know how bad software was in the 1980s, try to run some software from the 1980s. I used to think like you do, that software was incredibly efficient and incredibly well written in the 1980s. Then I tried to run some software from the 1980s. A game from the 1980s often runs slower on today's hardware than today's games do. There are all sorts of ill-conceived hard coded limits in old games. Take software from the 1980s and try to run it on data sets measuring in the gigabytes: no dice.
Again, people expect more from their software today than they did from yesteryear. I'm extremely suspicious of people who say that old software is more efficient/better written than today's software. I've used software from the C64 age. Guess what: IT SUCKED.
I don't understand what you mean. If I were to sum up Singularity in one idea, it would be its use of static analysis to ensure the stability of its components. Where does JNode use static analysis?
Since Church's thesis, I would say, which is to say, since the beginning of computer science as a discipline.
Actually for a lot longer than that. Pure math has almost always been almost inseparable from physics. Would a particle exhibiting non-linear acceleration due to gravity violate the laws of physics? Regardless of whether this is true or not, a linear function is a "pure math" term, as you state it. Something being mathematical doesn't render it totally separate from physics.
Being able to solve an NP-complete problem in polynomial time is either physically possible or physically impossible. Period. We don't know which one yet because we don't understand the physics yet.
What the fuck?! I would outraged when this was at +4, but +5?!
This is misleading. NP-completeness relates to how other problems can be reduced to it. Currently we can't say much about how NP-completeness and complexity relate. We know that if a problem is NP-complete, it must take at least polynomial time and at most exponential time (on a classical computer), but beyond that, we know nothing.
This is factually incorrect. So far we have not found a quantum algorithm to solve any NP-complete problem in less than exponential time.
Ha!
This is factually incorrect. Perhaps you're getting confused by the fact that quantum algorithms are often described in circuit notation. Classical algorithms are also sometimes described in circuit notation, but this is much less common. In any case, quantum algorithms do not bound the size of the input any more than classical computers do.
For instance, quicksort on a classical computer might be "bounded" in that you cannot sort an array of 50 billion petabytes. This is not inherent in the algorithm; it's inherent in our inability to construct a computer with 50 billion petabytes of memory. Similarly, we have not been able to use quantum computers to date to factor integers larger than 15. This limit is not inherent in the algorithm; it's inherent in the fact that engineers have not been able to construct a viable quantum computer to date with more than 5 (if I remember correctly) qubits.
Again, quantum algorithms to not bound the size of their input.
This is factually incorrect. Almost all of the research into quantum computation in the past 10 years has been in the area of quantum complexity. Perhaps you have heard of the BQP complexity class, which was mentioned in the article you were supposed to have read. By the way, BQP can in some way be thought of as quantum computers' "P"; i.e., the class of problems which can viably be computed on a quantum computer in polynomial time.
Quantum complexity very much uses big-O notation (as well as big- notation and any other complexity notation used in classical complexity theory).
Non sequitur. It's not clear at this point. If you could answer that question, you'd probably be drowning in money right now.
It was a bad summary (surprise, surprise). Most of the article was crap, but I quite liked the ending, when he got into relativistic computing. Relativistic computing isn't exactly novel, but he gave a good survey of the problems it (doesn't) solve.
About 3 or 4 years ago, I installed Debian GNU/Hurd. Incidentally, Debian GNU/Hurd is infinitely easier to install than Debian GNU/Linux, and the hardware support was better as well. I'm not exactly sure how, as the Hurd was based on Linux 2.0's drivers as well, but it worked perfectly with my hardware when Debian GNU/Linux wouldn't.
My impessions of Debian GNU/Hurd was that it was very cool, very very fun, very unstable, and very slow.
I don't know that his suggestion that people complain after trying out a microkernel OS is a good one, as there are a lot of bad microkernel OSes out there. For what it's worth, I think Microsoft's direction with Singular is the Correct way to go: many of the advantages of a microkernel without many of the disadvantages (namely no context switches between parts of the kernel).
Actually, someone gave him currency in exactly zero of those cases. He never mentioned anything about selling, just generating wealth.
FYI, a number of compilers do define a long as 64 bits. It's called the LP64 model (longs and pointers are 64 bits long), and Microsoft and Linux/GCC follow it for 64-bit platforms, if I remember right. I've heard rumours of some compilers even following the ILP64 model (ints, longs and pointers are 64 bits long), though as I said before, I don't think that's the greatest idea.
Why would you need to mask anything? I think you misunderstand what an int being 32 bits means. That doesn't mean that it only uses 32 bits in the register. A 32 bit int can use 32 or 64 or 128 or 4096 bits in a register. There is absolutely no point in masking it in the register to keep it contained within 32 bits. Yes, it might start overflowing into the 33rd or 34th bits, or sign extend all the way into the 63rd bit. Who cares? That has no visible effect in the program.
What makes the int "32 bits" is when you start reading from or storing to memory. When you start pushing an int onto the stack, do you use a "st" (store word) or "std" (store double-word)? (Using SPARC's instructions). Aside from storing and loading, 32-bit and 64-bit arithmetic is exactly the same, even in 64-bit registers.
I'm less versed in x86-64, so I can't say conclusively that there are no performance penalties there for working with 32-bit data, but on SPARC and PowerPC at the least, a 64-bit int offers no performance advantage over a 32-bit int.
I am a C programmer. I need an integer which is at least 40 bits long. What do I use? A long? It's possible than a long is 40 bits long, but it's not guaranteed. Therein lies the difference.
That might be why compiler folks invented long long, but it is not why the C standard adopted long long. As I said before, people need a guarantee of an integer longer than 32 bits. long will never be guaranteed to be longer than 32 bits.
You're thinking about this from the wrong perspective. If compiler writers want to add a 128-bit integer, they are perfectly within their right to make a long long, or a long, or an int, or a short, 128 bits in length. The standard is not there to satisfy compiler writers (okay I lie a little bit, but it's a mental exercise).
The standard is there to provide guarantees about what C programmers can expect. Do C programmers need a guarantee that, on all platforms, under all compilers, there is an integer type at least 128 bits long? If yes, then the C standard should add a type to support that (probably long long long). There are different mentalities behind the phrase "using a 128 bit integer".
One mentality is that just happens to be what the compiler gave you. You know, "I used long because I only required 32 bits, but the compiler gave me a 128-bit integer because it would be just as natural. Bonus!" In that light, it's obvious why compiler writers are so free to go beyond the requirements of the standard.
The other mentality is that you need a 128-bit integer. In that case, using a long is totally out of the question, no matter if your compiler provides a 128-bit integer or not. If you ever want your code to run with a different compiler, you have to use a new type (say long long long), because that's the only one that guarantees the length you need.
I'd never heard of Bogglific before. It looks pretty sweet. Thanks for the free advertising, Hasbro!
Oops there is a bug in my write_long. That's what I get for coding off the top of my head. Regardless of my bug, hopefully the sentiment still gets across that you only need to write these functions once, and it shouldn't be TOO hard to code them.
Also note that these functions will use for things like the PNG header or a TCP header. It's just a little more portable, that's all.
It is actually not difficult to portably read/write binary files. It may be a little time consuming, but you only have to do it once. For example:
... } ... } ... } ... }
:P
void
write_long(long x, FILE *f)
{
if (x < 0)
write_long(~(-x), f);
else {
unsigned char c;
c = (x & 0xff000000) >> 24;
if (fwrite(&c, 1, 1, f) != 1) {
c = (x & 0xff0000) >> 16;
if (fwrite(&c, 1, 1, f) != 1) {
c = (x & 0xff00) >> 8;
if (fwrite(&c, 1, 1, f) != 1) {
c = x & 0xff;
if (fwrite(&c, 1, 1, f) != 1) {
}
}
And you'd need read_long, write_int, read_int, write_short, read_short, etc. etc. It relies on the fact that the C standard guarantees: characters are AT LEAST 8 bits; sizeof(char) = 1; longs are AT LEAST 32 bits in size. I force the value into 4 8-bit characters comprising a 32-bit 2's complement number, regardless of what underlying representation the architecture uses.
Yes, true, fwrite(&x, 4, 1, f) is more efficient, but not so conforming or portable
long long was added to create an integer which is at least 64 bits in size. It was created because people needed integers longer than 32 bits. It has nothing to do with people making assumptions.
I don't see why an int should be 64 bits wide on a 64-bit machine. It's not any faster; it doesn't save any cycles anywhere. The general rule of thumb is to use "long" if you need a long integer. Consequently, people who use int are (theoretically) doing so because they don't need a long integer. Seeing as there is no performance penalty, I think using 32-bit integers on a 64-bit machine is fairly prudent just for the memory savings.
You make a good point. The way I would look at it is in those cases you're already making assumptions (8-bit bytes, 2's complement, etc.), you may as well make some other assumptions. I guess the nice thing about int32_t and the such is that, in the cases where you are making these sorts of assumptions, you don't have to typedef these themselves. It saves a little bit of #ifdef hell.
Boolean does not mean "true or false". Boolean means any group which satisfies the boolean axioms. The real numbers between 0.0 and 1.0 are, in fact, very common boolean types. Typically the boolean operators are implemented as:
Sorry, but it's just kind of a pet peeve of mine when people use "boolean" as a synonym for "true or false". Have none of you taken a course on boolean algebra?
These types are a huge abomination to C, as far as I'm concerned. There is no way to write standard C where the exact size of an integer is needed. My only hypothesis for why int64_t and int32_t and the like were included in the standard is to appease giant dumbasses who write integers directly to binary files, a practice which of course is not conforming to the standard.
The C integer types are, in fact, very logical, very useful, and very much your friend. Here's a quick guide:
The types mentioned above will do everything that the int64_t, int_least32_t, etc. types will provide. intmax_t seems equally useless. Contrary to the parent's suggestion, the C standard says nothing along the lines of intmax_t providing the largest int that an architecture can handle. What would that even mean? That it's the biggest int that can be stored in a register? Oops, I guess x86 can't have a 64-bit intmax_t then, eh? That it's the biggest int that the architecture can perform arithmetic on? Well then I guess on most architectures, intmax_t must be at least a couple billion bits in size, right? There's no meaningful definition of this sort can be used.
What the standard says about intmax_t is, and I quote, "The following type [intmax_t] designates a signed integer capable of representing any value of any signed integer". That's it. All it says is that an intmax_t can store any value from a signed char, short, int, long, or long long. In other words, as far as the standard is concerned, there is no difference between a long long and an intmax_t. And indeed, I would be very surprised if there were ever an architecture where intmax_t were not just a synonym for long long: after all, there is no way to write conforming C code where an intmax_t can be depended on to do anything that a long long won't.
So why would you ever use an intmax_t? You wouldn't. There's no reason to. If you're writing conforming code.
Please stop spreading FUD. An out-of-date flash drive, being written to CONSTANTLY (under MUCH harder conditions than just swapping) should last for no less than 51 years. For modern flash drives, that number should be in the hundreds of years.
This is not to say that flash drives last forever, or even that they last 51 years. This is to say that, no matter what you're doing, there is nothing in this world perverse enough you could be doing which will make a modern flash drive level out. As mentioned in a parent post, the limiting factor in flash drives these days is NOT how many writes it can do. It's probably not too hard to abuse a flash drive to render it useless, but writes are NOT the limiting factor.
I will remain pseudonymous, but I will say that my current area of research (I am a graduate student) is tangentially related to this field, related enough that I've looked into trying to convince GM to give me funding (so far nothing has materialized). Specifically my research looks deals with programming language design (e.g., making less-than-Turing-complete-but-still-useful programming languages structured in useful ways) to aid in static analysis. The aim is at safety-critical code (nuclear power plant code, industrial controller code, automotive software) such that you can say "barring hardware failure, this code is 100% guaranteed to meet hard realtime constraints", etc.
Anyway, at least publicly, GM is probably the most impressive car company in terms of researching these sorts of things. I feel kind of bad for GM. I hear they're selling terribly and are even selling at a loss on many cars, but their research department really is something impressive. Maybe they're a little bit Microsoft-ish in that their research department is heavily insulated from the rest of the company, I don't know. But GM is doing a lot of cool stuff and funding a lot of cool stuff with regards to "correct" software.
If it were some other random company, I would probably roll my eyes and say "oh they'll probably just test it really really heavily and then tell us that it works", but more than most companies, I trust GM to develop cool technology (such as novel static analysis techniques) to get this to work. Their R&D is active in a lot of areas, 99% I'm sure will never amount to anything, but I wouldn't doubt it if they could get the technology together to get auto-driving cars in 10 years.
Disclaimer: as I mentioned before, my efforts to get GM funding are still unsuccessful, and consequently I'm not on GM payroll in any imaginable way. I don't even drive a GM car (or any car). In fact their cars look kind of lame in general, but their R&D department in Cool.
What is MOEP? Even Google could not save me this time.
I like cumulative voting for multi-member elections, which is basically range voting with some normalization. It ends up being fairly proportional.