Except that "fast" isn't a good answer to describe earlier airplanes. "Cargo" also isn't an apt word, unless you meant the pilot (and not a weigty one). Well, "around" is also pushing, "a few metters" would fit better.
Face it, the airplane was created because people had fun doing it, there was no business case. Of course, latter, when it become able to transport the pilot for a long distance it started making business sense and then came a war...
"Only later can certain sites risk being IPv6-only, and only much later can IPv6-only devices be marketable."
Too late. VoIP is already IPv6 only if you want it to really work. Remote administration could be a nice service throug the net, but it is IPv6 only, so it doesn't exist (except for a few companies, that route the trafic through them)... There are plenty of thing that can only exist on a IPv6 network, so there will be plenty of sites that will be IPv6 only when the time comes.
We got that same moronic attitude every time somebody sugest that we must solve a problem before it causes a crisis, not after. Guess what, people are saying for 10 years that the IPv4 addresses are running out because they were planning 30 years on advance (that ended up being just 20, mind you). Up to now, the epected exaustion of IPv4 addresses moved from somewhen near 2020 to middle 2012.
"I can't even get through the setup of a DHCP server running IPv6."
That is because IPv6 networks don't generaly use DHCP. They use autoconf or similar tools.
"I can't pick a class C space (or whatever its ipv6 analog may be) or figure out if my ISP will assign enough IP's to me to make everything inside my network public."
Forget about IPv4 shortcomings, ok. Well, you should have at least a/64 network (that's for end users), you'd probably be able to get a/32 if needed, but that should be rare, since a/64 net is already bigger than the entire IPv4 space. Now, at the real life, lots of ISPs are reluctant to make IPv6 available, and some of them will just give you one address. If you get a good one, tough, you'll have nothing to fear.
In fact, that time is smaler than a milissecond for modern disks. It is only the time needed to rewrite the entire inode pointer at the directory descriptor, what is, well, 8 (consecutive) bytes long.
If the power goes off on the middle of those 8 bytes, you get a corrupt file, if it goes off before that, you get the old file, and after that you get the new one. The temporary file may be corrupted if the power goes off while writting its data, but nobody cares about that.
"do users have that expectation because it's reasonable and proper that this is the filesystem's job, or, did the failure of multiple application developers give those users a false impression of what is and is not the correct role of a filesystem?"
"Thus to be fs independent, applications should call fsync to force data be physically written to disk."
Or they could document that feature (that it seems that everybody needs badly) and fix ext4... People could also comit to a middle point, adding another system call for atomic moves, or another couple of oppening modes.
"cache, memory controllers, point-to-point coherent and IO links, buffers everywhere"
All of that, except for links, is redundant. If there is a defect somewhere on the cache, you lose one block (memory controlers are an interesting case, as it isn't completely redundant, but mostly so), if there is a defect at the fectcher, you lose a core. That makes for a huge difference between a simple fetcher and a turing complete one. IO links also have a big feature size (or redundant features, depending on manufacturing method), and thus a lower probability of defects.
"RISC machines are a pure Load/Store architecture and don't (or didn't) have the notion of load-execute or load-execute-store instructions."
Yes, that is right. And load-execute is slower than pure load-store unless you spend a fortune optimizing your projects for that bottleneck.
Now, you are right about gcc using SSE and SSE2 when compiling for AMD64. I got myself stucked at the 32 bit times here.
"Some people may not like the x86 architecture for whatever silly reasons, but the fact remains that it's going to be around for a long time. It's proven technology that is simply expanded as time goes on. First with 32-bit, now 64-bit. I don't know about you, but I very much enjoy the fact that, at its core, my computer is still the same machine it was 20 years ago, and can still run the same old software if I so chose."
"I wish Slashdotters would stop with the incessant "x86 sucks" mantra. You're all fools."
Well, ok, I'll bite. For an architecture that doesn't suck, the following list is way too big:
"There's plenty of crufty old instructions in the x86 ISA; no modern compilers generate them though, so no one cares that they're there."
"There's plenty of crufty segmentation and weird ways of laying out memory and whatnot; no modern OS uses that though, so no one cares that it's there."
"Yes, of course an x86 decoder is bigger (i.e. more expensive, more difficult to implement, etc.) than a RISC fixed-length decoder, but again, no one cares..."
They still use die area, they still can't be turned off (to save power), and they still introduce defects (what cache almost doesn't do). So, they still lead to a more expensive and power hungry chips.
"Sure there's the crufty x87 floating point stack. But there's also the shiny new SSE/SSE2/SSE3/whatever instructions, and modern compilers can exclusively use SSE/SSE2 to do the exact same thing..."
It doesn't matter (except for the die area, number of defects and not being able to turn offf), the compiler won't use it, unless you are compiling your own binaries to your own machine. Those instructions are too varied for pre-packaged software.
"And CISC-style+variable-length instructions get you a smaller code footprint and thus better instruction cache utilization..."
And that is the one advantaje of CISC. Ok, but RISC has no problem compressing the code stream, making even better use of cache (CISC could also compress, of course, making the point moot). And, now, to the important topic:
"And 64-bit stuff gives you extra registers too (8 extra integer, 8 extra SSE for a total of 16 each), which is great and a nod to the large number of registers that RISC machines give you."
RISC machines used to give you 32 register of each kind, by the time they were 32 bits. That was a long time ago... Now they usualy come with 64 or more registers of each kind. One of the problems the compact instruction set gives you is that once you use all the instructions, you can't address more registers, that is why x86 is stuck at 16 of them.
"Don't most people running Vista already run the 64 bit version?"
No. 32 bits Vista is more stable (DRM stuf and the old closed source impatibilities), so many people prefer it. My bet is that MS won't be able to transition to 64 bits, ever.
"A simple tasks such as sharing directories already becomes complicated, since NFS for example is pretty insecure by default"
That is a very ilustrative example. NFS isn't insecure by default. Except for very specific distros, NFS is DISABLED by default. An incompetent admin would have a bad time trying to activate it.
Well, if it is that important that your data survives a power outrage, you need durability. There is nothing stupid on asking for durability when you need it.
Now, of course, losing some desktop configurations isn't as huge a loss, but who am I to imply that the article is sensationalist?
I'd agree that they are 100% correct, but I wouldn't recommend people to not use it, I'd just ignore it. There are lots of applications where it could be reliably used and would give a good performance.
Too bad the FS name is ext4, what implies that it is fully compatible with the ext family. Maybe a name change would be good, or we need an ext5 already...
Slashdot Mirror
Oh, no. That's 2012.
Except that "fast" isn't a good answer to describe earlier airplanes. "Cargo" also isn't an apt word, unless you meant the pilot (and not a weigty one). Well, "around" is also pushing, "a few metters" would fit better.
Face it, the airplane was created because people had fun doing it, there was no business case. Of course, latter, when it become able to transport the pilot for a long distance it started making business sense and then came a war...
Too late. VoIP is already IPv6 only if you want it to really work. Remote administration could be a nice service throug the net, but it is IPv6 only, so it doesn't exist (except for a few companies, that route the trafic through them)... There are plenty of thing that can only exist on a IPv6 network, so there will be plenty of sites that will be IPv6 only when the time comes.
We got that same moronic attitude every time somebody sugest that we must solve a problem before it causes a crisis, not after. Guess what, people are saying for 10 years that the IPv4 addresses are running out because they were planning 30 years on advance (that ended up being just 20, mind you). Up to now, the epected exaustion of IPv4 addresses moved from somewhen near 2020 to middle 2012.
That is because IPv6 networks don't generaly use DHCP. They use autoconf or similar tools.
Forget about IPv4 shortcomings, ok. Well, you should have at least a /64 network (that's for end users), you'd probably be able to get a /32 if needed, but that should be rare, since a /64 net is already bigger than the entire IPv4 space. Now, at the real life, lots of ISPs are reluctant to make IPv6 available, and some of them will just give you one address. If you get a good one, tough, you'll have nothing to fear.
In fact, that time is smaler than a milissecond for modern disks. It is only the time needed to rewrite the entire inode pointer at the directory descriptor, what is, well, 8 (consecutive) bytes long.
If the power goes off on the middle of those 8 bytes, you get a corrupt file, if it goes off before that, you get the old file, and after that you get the new one. The temporary file may be corrupted if the power goes off while writting its data, but nobody cares about that.
Well, let's say:
$cat file1
file1 contents
$echo "test" > file1.tmp
$mv file1.tmp file1
Now, there were some data at file1, you moved a file with some data into it, but the power goes off. Do you really expect file1 to be empty now?
Well, here goes a hint:
If you want to write a ninche FS for specialized uses, DON'T name it after the ext family.
Because the standard wasn't fixed, just the code.
Or they could document that feature (that it seems that everybody needs badly) and fix ext4... People could also comit to a middle point, adding another system call for atomic moves, or another couple of oppening modes.
Much less than you have at yuor head. Of course, all that talk about a dicrete universe, with complete knowledge applies here.
Well, if those bacteria originated here, we still have panspermia, but we are the ones seeding.
Conditions at 41km are more like open space than the surface of any planet.
All of that, except for links, is redundant. If there is a defect somewhere on the cache, you lose one block (memory controlers are an interesting case, as it isn't completely redundant, but mostly so), if there is a defect at the fectcher, you lose a core. That makes for a huge difference between a simple fetcher and a turing complete one. IO links also have a big feature size (or redundant features, depending on manufacturing method), and thus a lower probability of defects.
Yes, that is right. And load-execute is slower than pure load-store unless you spend a fortune optimizing your projects for that bottleneck.
Now, you are right about gcc using SSE and SSE2 when compiling for AMD64. I got myself stucked at the 32 bit times here.
What a long line just to say "it runs Windows."
Power X Sparc
Let the flame-wars begin!
Well, ok, I'll bite. For an architecture that doesn't suck, the following list is way too big:
They still use die area, they still can't be turned off (to save power), and they still introduce defects (what cache almost doesn't do). So, they still lead to a more expensive and power hungry chips.
It doesn't matter (except for the die area, number of defects and not being able to turn offf), the compiler won't use it, unless you are compiling your own binaries to your own machine. Those instructions are too varied for pre-packaged software.
And that is the one advantaje of CISC. Ok, but RISC has no problem compressing the code stream, making even better use of cache (CISC could also compress, of course, making the point moot). And, now, to the important topic:
RISC machines used to give you 32 register of each kind, by the time they were 32 bits. That was a long time ago... Now they usualy come with 64 or more registers of each kind. One of the problems the compact instruction set gives you is that once you use all the instructions, you can't address more registers, that is why x86 is stuck at 16 of them.
No. 32 bits Vista is more stable (DRM stuf and the old closed source impatibilities), so many people prefer it. My bet is that MS won't be able to transition to 64 bits, ever.
Yeah, but Intel would lose the entire server market.
That is a very ilustrative example. NFS isn't insecure by default. Except for very specific distros, NFS is DISABLED by default. An incompetent admin would have a bad time trying to activate it.
Oh, now that is clearer. I've replied to another one of your posts, but I thought you wanted durability...
Now, I have a question for you. Do NFS and AFS support atomic renames? They don't look like supporting any ordered operation.
Well, if it is that important that your data survives a power outrage, you need durability. There is nothing stupid on asking for durability when you need it.
Now, of course, losing some desktop configurations isn't as huge a loss, but who am I to imply that the article is sensationalist?
I'd agree that they are 100% correct, but I wouldn't recommend people to not use it, I'd just ignore it. There are lots of applications where it could be reliably used and would give a good performance.
Too bad the FS name is ext4, what implies that it is fully compatible with the ext family. Maybe a name change would be good, or we need an ext5 already...
You'd probably take an eon. Bash takes a few minutes.
Mouse-jockey.
How the hell can a neutron star post on /.?
Myself, I'm also made of leptons...