Yeah, because that always works. Every time MS pulls some slimy stunt, it's always been so easy to get the masses to realize what's truly going on. They're not easily swayed by mere sound-bite FUD.
Moderators, please note the parent deserves (Score:5, Sarcastic)
Microsoft once had a Unix OS product of their own, Xenix. It ran on the old PC/AT processor (Linux needs at least a 386 for the hardware MMU)
The 286 has a hardware MMU, but it only supports 16 bit segmented virtual addresses and sucks for many other reasons besides. Unix in general wants 32 bit virtual addresses, however, that hasn't stopped people from implementing Linux on 16 bit processors, in real mode even (so your statements are inaccurate for a number of reasons). I don't know if anybody has bothered implementing Linux using the 16 bit 286-style MMU, which incidently is emulated on all later 86-familly processors.
One simple reason: Licensing Unix from SCO strengthen's SCO's claim to Linux. Microsoft has pretty much publicly declared war on Linux (in as much as that is possible) and I don't think it's coincidence that this announcement comes days after SCO announced their plans to sue Linux out of existence. By licensing the offending code, Microsoft is essentially backing SCO up here by saying "They have a legitimate claim on this code and should be paid licensing fees." The fees are inconsequential to Microsoft, it's the implications of paying them that they want.
In my mind, it also lends weight to the theory that Microsoft has been quietly orchestrating this thing from the start. There are just too many signature signs.
Actually, they implemented a wallhack block not too long ago into Counter-Strike. It doesn't transmit player locations behind walls it seems...
That's something I suppose, but what about players partly behind walls?
Players not in the viewport should also be culled of course.
but the problem is, the client still needs to know where footstep sounds are coming from, and some cheats actually take advantage of this and show the footsteps through the walls
This one can be dealt with by trasmitting two amplitudes (one for each ear) instead of the position or direction/distance of each footstep. A cheating client could still be able to do some kind of ambiguous visual reconstruction, but it would look ugly and it wouldn't necessarily be better than what you get via your ears. Or, hmm, you could look at the cheat as a feature that enables someone who's deaf to compete fairly.
Re:My experiences with Gentoo
on
Gentoo Reviewed
·
· Score: 1
Anything CPU intensive (and especially math intensive) is going to get a nice boost. LAME went from 2x encode to 4-5x encode by recompiling after playing with compiler settings (from defaults to using -march, -mcpu, -pipe, -fomit-frame-pointer, and a few others)
-pipe won't affect run speed, it affects only how the compiler communicates between passes internally.
Re:My experiences with Gentoo
on
Gentoo Reviewed
·
· Score: 1
In other words, the install takes forever, and does demand a fair bit of linux knowledge, but the process IS worth it, once you are finished.
Like many developers, I've considered switching from Debian Sid to Gentoo, because of Gentoo's reputation for being an up-to-the-minute distro that also has a good stability and is highly configurable. Though Debian has great strengths, particularly the massive number of maintainers that take their work so seriously, and a huge, detailed policy structure, it also has its limitations, such as no downgrades, breakage in important packages that sometimes lasts for months, and sometimes being a long way behind current development, KDE3 being an example of that.
Supposedly, Gentoo doesn't have the above problems. The only drawback of Gentoo I've heard about is the long initial compile. On a fast machine, it may not be that bad, but in the long run, something could be done about it. For example, certain common configurations could be pre-compiled and cached on a server that acts like a database, so some large chunks of code wouldn't have to be compiled for every install (much like Compiler Cache). Well, I'm sure the Gentoo guys have thought of that.
Another thing that could be done, and this would require some pretty serious gcc hacking, would be to compile the source into an intermediate form, something like java bytecode, or a tokenized version of the intermediate format gcc already uses, that is, RTL. The final code generation would happen on the installation target, so the intermediate binary would be cross-platform. RTL might not work for this because of processor specific features and other problems (I haven't yet looked at it closely enough to know for sure) so ideally, you'd design a new intermediate form that's ideally suited to the problem, optimized both for accurate representation of the partly-compiled code, and for quick code generation.
Needless to say, this would be a massive amount of work, but it would also be a legendary hack.
Regardless of the above, I think I'll install Gentoo on the next machine that comes in here.
Of course it's not the only security problem. Anyone who thinks that any piece of complex software is 100% secure is kidding themself.
Other next-gen phones will have issues.
But don't you think that Microsoft's Smartphone will have more security holes than all the others put together, and worse ones? It's a tradition, after all.
I work for Microsoft (program manager for Mac Internet Explorer), and I own a 2002 BMW 745i. Though the underlying OS the vehicle is running is Windows CE for Automotive...
Thanks. I've been thinking about upgrading my BMW, and now I know which model to avoid.
Well, of course if you're a pro Astroturfer you get your astroturfer friends to mod you up, or use your alternate accounts. Whatever. In a business sense, the astroturfers are a big win for Slashdot, since they create traffic, and lots of it. Unfortunately for Microsoft, that traffic tends to be overwhelmingly negative, and rich with interesting information supplied by clueful people, exposing various seamy strategies to unwelcome scrutiny. So astroturfing Slashdot is a self-defeating strategy for Microsoft.
The entire purpose of Internet Explorer was to put Netscape out of business, and it did essentially that.
That was only half the plan. The other half was to take over the client side of the web. At the same time, IIS would take over the server side, and Microsoft would hence own both sides of the communication link, and be able to coopt the protocols, "decommoditize" in Microsoft-speak. This plan was foiled by Linux, BSD and the Apache project, fortunately for the public.
Internet Explorer: Agreed - I can't see it benefiting MS with the exception of market share. Unless, however, there is a master plan in place to charge all those corporations/individuals royalty fees in future for embedding the IE rendering component within applications.
That was the plan all right, but it's now essentially dead because Apache refuses give up its dominant share of the web server market. Without control of both sides of the link, Microsoft can't force netizens into using its proprietary content delivery systems. It would take force to make people use these, because they won't do it willingly, so long as the content is heavily restricted.
Now, it's become more dangerous both in a legal and mindshare sense for Microsoft to further leverage its OS monopoly in attempts to extend control over browser content. Big defeat for Microsoft here, and a big win for the public.
"Stattdessen soll Embedded Linux mit 27 Prozent zur bei weitem am häufigsten eingesetzten Plattform werden"
27% is not 50%. But even so, 50% does not imply a standard, it just means it's the most popular.
Allow me to help you a little with the language. It says: "[in future projects] Embedded Linux should become by far the most widely deployed platform, with 27 percent" and goes on to say:
"Fast die Hälfte der Embedded-Entwickler will innerhalb der nächsten zwölf Monate eine Anwendung für Linux oder ein anderes Open-Source-System fertigstellen", that is, "Almost half of Embedded developers want to do a project with Linux or another Open Source system within the next 12 months."
So half of embedded developers plan to use Linux (or BSD as most likely second choice) for a project this year, Linux will have 27% of all projects, more than twice the second place platform, CE. While I would not describe this as a "takeover" in so many words, it is certainly a "dominant" position, apparently well on its way to "takeover".
The "Security" problem enabled people to hack the provisioning of the phone, during (and only during) it's first-time boot. To take advantage of it, you must do a manual hard-reset, then manually copy a file across at the right point of the boot. It wasn't easy and usually took several attempts to get right.
So... then that must surely be the *only* Smartphone security problem? And I should not worry, because there's no other possible exploit for the security hole already found?
I meant shared mmap, i.e., multi-host. Pardon me for not being specific.
Try this: mmap the same file on two different hosts, then write the same file location on each host via the mmap with different data. Result: two different versions of the file, and it's random which one is finally written to disk. Also, write one host's mmap, read on the other. Result: it's random whether one host sees what the other wrote.
A clustered filesystem that fails as above is not worthy of the name. It's also important to do the shared mmap efficiently, and GFS does.
I know that this is going to be the most common answer, but just go with NFS. It's not the most secure option around, but obviously the simplest to implement and the best documented.
NFS has a lot of problems, the worst of which you can summarize as: it doesn't act the same as a local filesystem. For example, mmap just doesn't work over NFS. Anyway, NFS is properly called a network filesystem, not a distributed filesystem. It lacks a lot of features you'd expect in a distributed filesystem, such as disconnected operation.
Have you ever worked in a shop where the home directories are mounted on NFS? The server stops and everybody freezes. This is not nice. NFS has horrible security holes too. The best thing about NFS is, it's commonly available, and you can also say that it's a lot better than no network filesystem at all.
As far as I can see, GFS, the Global Filesystem by Sistina is better than NFS in every way. It actually provides POSIX semantics, including mmap, over the network, which is a pretty nice trick. It's considerably faster than NFS. It acts just like a local filesystem, even though it's not. You can even use it as a local filesystem, like Ext2/3.
Caveat: I recently joined Sistina as a kernel developer, though at the moment I'm working in the logical volume manager group ratjer than GFS. While GFS is a commercial product, we also have OpenGFS, a sourceforge project forked from the most recent GPLed release of GFS from Sistina. Developers on the OpenGFS project include Alan Cox and Christoph Hellwig, i.e., its supported by core Linux developers.
I believe we'd all be better off in the long run if GFS takes over and NFS gradually dies out. I'll make an analogy betweedn NFS and rsh: rsh filled a need at one time, but it's broken by design (plaintext passwords). These days, nobody uses rsh and everybody uses ssh, which by the way, is also available in both commercial and open versions. (Note that while the OpenGFS project may not be strictly compatible with Sistina GFS, it shares the same goals in terms of POSIX compliance, performance characteristics, etc.)
it's your kind of short-sighted thinking that got us into the current address space shortage. It's not 128 bits for reasons we can think of now, it's 128 bits because of the reasons we can't think of.
"Exactly: you can't think of a reason why it's good, but we can think of several reasons why it's bad. That kind of engineering is stupid. I stand by my prediction that because of this and other dumb mistakes, ipv6 will never be generally adopted, it will be found only in niches or hidden away in backbones, not adopted wholesale by end users."
Waitaminute. The reason you say it's bad has to do with the fact you can't remember that many bits anymore. What's all the other reasons that 128 bits is bad? Too much bandwidth consumed to build the IPv6 header??
You can't remember that many bits either, or I will eat this disk. Nobody can, so that's already a big, fat (that's "big", "fat") problem.
It's not just that, of course. Will you ever have to type in all those, eh, "bits", as you call them? Yes you will. Sometimes you will have to do that. It takes 4 ("four") times as much typing to type in 128 (ehm) bits, as 32.
Current ip address notation, using decimal digits separated by dots, it's human-friendly. Push it to 128 bits and its just evil. However, at 5 bytes its still fine. Note: going to hex notation for 5 byte addresses would be a good idea. It saves typing and is easier to remember the addresses, if anything. On the downside, it could conceivable become easier to confuse a host name with an IP address. A little.
Did you ever set up WEP? Setting up WEP is painful. It wasn't meant to be done by humans. The numbers you have to type in are just too long, and you have to try many times, usually, because there are quite a few settings to tweak before you get it working. (Hey! Just like setting up a machine on the net!) Now, there's an excuse in the case of WEP. You do need a cryptographic key. But public net addresses are not cryptogrpahic keys. The shorter the better, from the point of view of usability.
Suppose postal codes had 35 digits. Do you think anyone would bother?
Now I don't expect you to understand the next point, but: give programmers an easy way out, and they get lazy. Let them route by indexing on a simple prefix of the net address, and they won't bother thinking up indexing algorithms for routers that work just as well, and don't rely on simple prefixes, but are a little harder to design.
In summary: going to 128 bits was just plain stupid, given that the problems are real and the benefits imaginary. Going to 40 bits would have been smart, it does the job with minimum fuss. For bonus points, write the RFC so that going to 48 bits later is painless, even though it's pretty obvious we won't be needing more than a trillian public addresses until we start colonizing the galaxy.
Anyway, we'll get another chance to do it right, because ipv6 is going to fail - it's never going to be widely deployed on personal computers. People will just keep using ipv4 with NAT, because ipv6 has too many problems.
Not just theoretical problems, but actual nasty, time wasting problems that get in your face. (And we didn't even talk about the way they dropped the ball on IPv4 address compatibility, or did we.)
It's your kind of short-sighted thinking that got us into the current address space shortage. It's not 128 bits for reasons we can think of now, it's 128 bits because of the reasons we can't think of.
Exactly: you can't think of a reason why it's good, but we can think of several reasons why it's bad. That kind of engineering is stupid. I stand by my prediction that because of this and other dumb mistakes, ipv6 will never be generally adopted, it will be found only in niches or hidden away in backbones, not adopted wholesale by end users.
I made a statement that GIFs can be made that most readers will accept and yet is patent free.
Bullshit, you were supporting a thesis that open source coders can always work around patents, which is, ahem, patently false. Even with your gif example, the workaround turns out to be inferior to the patent-encumbered version. The bright side is that GIF never was, and never will be, part of any official standard. However, it is (probably) well-meaning but (perhaps just seemingly) dull-witted people such as yourself that could steer the outcome of future gif-like stories towards a far worse outcome, where there is in fact no alternative but to pay the toll.
So, I'll modify "clueless" to "well-meaning but clueless" if you like. You certainly do not have a grasp of the situation, or you do, and you are trolling.
Maybe when they start sending nanotechnology to mars they want it all to have different ips?
Boy, you're in luck, because with 128 bits you can address every single atom in the galaxy, individually.
Maybe your identification card will have ip address?
I hope not, and even if it did, we are still far from the 100 IP addresses per person we could have with a 40 bit IP address instead of 128.
People who can't think of uses for advanced technology are definatly lacking in imagination.
People who justify bad designs with bogus arguments are hazardous.
Also there's a lot more to ipv6 than just more addresses...
But we're talking about the stupidity of 128 bit addresses.
So argueing against future proofing the address size isn't even addressing half the advantages of ipv6.
We're not talking about any aspect of ipv6 beyond the type of the address. By making it 128 bits you simply make it user-hostile, which is a fine kind of future-proofing.
Also when you say "MY toaster doesn't need to be networked" That sounds a lot like the visionless dumbasses who said "A laptop? Oh ya who is gonna carry a fricken computer around with them everywhere!" Well not only where those people morons but now we have PDAs that take laptops a whole step farther than anyone was expecting at that time.
OK, you give *your* toaster a public IP address, and call yourself a visionary.
Really you sound like one of those unemployed lamewads who sits around his public housing apartment talking about "Dude! Amiga for LIFE! Assembly is what REAL hackers use! You all suck!"
You should talk, my fine Anonymous Coward. Beyond your rhetoric, there's no substance.
Good thing "640k is enough for anyone" types such as yourself aren't responsible for anything
Excuse me for repeating myself, but we're not talking about memory, we're talking about public IP addresses. A byte of memory is not the same as an IP address. (And argument by analogy is just rhetoric.)
"My question is simply, why does every appliance need an IP address?"
It doesn't. But in many cases it would be useful. How about an IP address for each envelope you put in the mail, so you can easily track them without relying on your local postal service?
Oh, and so my letter can serve me a web page as it crosses the Gobi desert?
How about not doing any such wrong-headed thing, and give your envelope a url instead, if you must. The things you want to do with an envelope just do not resemble the things an IP stack wants to do with a web host. In short, an envelope is not a web host, so does not need a web address, let alone a public one.
Now, go back and read your own post critically.
Which of your ideas requires an IP address and wouldn't work perfectly well with a url?
"For starters, it's essential that the old addressing scheme be a straightforward subset of the new one."
Actually, it is. There is a whole block of IPv6 which is the IPv4 address space. So if your IPv4 address is 10.20.30.40 your IPV6 address is:0a14:1e28 (you convert the bytes to hex).
You're talking about rfc 2893 ipv4 compatibility? Well, "IPv4-compatible addresses are assigned exclusively to nodes that support automatic tunneling". Dumb dumb dumb.
The IPV6 designers spent (and continue to spend) far more time on the migration issues than on the actual protocol changes.
That's because they didn't make it enough like the current system, even though that would not have been hard to do. Come on, is this or is this not an observed fact?
If I could just drop in an IPv6 stack and have everything just work, I'd no doubt be running IPv6 right now, and I'd own at least one public IPv6 address. As it is, I don't own any IPv6 addresses because I wouldn't be able to connect to them from outside anyway. And yes, there would still need to be a way of enabling the most significant octet, but with the stack in place at home and at my ISP (because it just works, duh) we're already most of the way there.
"So you're advocating security through obscurity?"
Well, I think everyone advocates this. If you don't beleive in the obscurity thing, then tell me, what is your credit card number, bank account, ATM pin code, Slashdot password, etc..., or would you rather keep them secure by making them obscure?
It's not a credit card or bank account, it's an IP address. I will happily tell you my IP address, and you will still not be able to log onto my system.
But I've got advice for you: just don't tell anybody your IP address, then you can use your girlfriend's name for your ssh login, in complete confidence:-)
Do you think before you post or just say what ever come out of your butt? Sorry, but this post is so uninformed that it is distrubing. IPv6 was designed from the ground up to deal with the existing limitations of IPv4; therefore, you would be an idiot to make things a subset of the existing design...
It's hard to see how you got modded as "informative". What I said was: "For starters, it's essential that the old addressing scheme be a straightforward subset of the new one." In other words, you read it backwards, dear Coward.
The primary design goals of it were to 1) Increase the # addresses available and to have addresses autoconfiguring. 2) Increase security 3) Improve network routing and ease network autoconfiguration. IPv6 accomplishes all these goals and very well.
Maybe it does. But it falls flat on its ass on the big ones: compatibility and usability. Unfortunately, that's what you get when a design committee goes to work in splendid isolation, and without the benefit of talent.
"* For starters, it's essential that the old addressing scheme be a straightforward subset of the new one."
You can simply run dual stack. No problem in there.
Glad you think so. Tell that to all the admins that now have to change their setups from "one stack" to "multi-stack". And don't even try to tell me you won't get mysterious glitches.
"* What the heck was the idea of making it 128 bits, so no human can deal with the raw numbers?"
No human should ever want to, even in the IPv4 world.
That is utter bullshit. Either you have never done any admin, or you have Alzheimer disease.
We've got a nice little thing called DNS which makes it possible to assign nice and easy names to those horrible numeric addresses.
Oh, and you've never had your DNS down? You never had to ping your gateway by IP address? You've never had to set up ARP? Track down mysterious problems using ipdump?
"* And we DON'T NEED TO BE ABLE TO ADDRESS EVERY THUMBTACK ON THE PLANET."
We don't need more than 640 K of memory either.
We are not talking about memory, we are talking about PUBLIC ip addresses (i.e., doesn't include the ones embedded in your stereo).
Let me try to explain this in terms you'll understand: when you were 1 year old, you were only two feet tall, so now you're a million miles high, right? Or to put it in precise terms: public addresses are not memory. They are not like memory. Analogies with memory do not support your argument. At all.
Slashdot Mirror
I'm not sure how to take that, I'll assume it's a [left handed] compliment?
Compliment, and I'm in fact left-handed, so correct either way.
Yeah, because that always works. Every time MS pulls some slimy stunt, it's always been so easy to get the masses to realize what's truly going on. They're not easily swayed by mere sound-bite FUD.
Moderators, please note the parent deserves (Score:5, Sarcastic)
Microsoft once had a Unix OS product of their own, Xenix. It ran on the old PC/AT processor (Linux needs at least a 386 for the hardware MMU)
The 286 has a hardware MMU, but it only supports 16 bit segmented virtual addresses and sucks for many other reasons besides. Unix in general wants 32 bit virtual addresses, however, that hasn't stopped people from implementing Linux on 16 bit processors, in real mode even (so your statements are inaccurate for a number of reasons). I don't know if anybody has bothered implementing Linux using the 16 bit 286-style MMU, which incidently is emulated on all later 86-familly processors.
One simple reason: Licensing Unix from SCO strengthen's SCO's claim to Linux. Microsoft has pretty much publicly declared war on Linux (in as much as that is possible) and I don't think it's coincidence that this announcement comes days after SCO announced their plans to sue Linux out of existence. By licensing the offending code, Microsoft is essentially backing SCO up here by saying "They have a legitimate claim on this code and should be paid licensing fees." The fees are inconsequential to Microsoft, it's the implications of paying them that they want.
In my mind, it also lends weight to the theory that Microsoft has been quietly orchestrating this thing from the start. There are just too many signature signs.
Actually, they implemented a wallhack block not too long ago into Counter-Strike. It doesn't transmit player locations behind walls it seems...
That's something I suppose, but what about players partly behind walls?
Players not in the viewport should also be culled of course.
but the problem is, the client still needs to know where footstep sounds are coming from, and some cheats actually take advantage of this and show the footsteps through the walls
This one can be dealt with by trasmitting two amplitudes (one for each ear) instead of the position or direction/distance of each footstep. A cheating client could still be able to do some kind of ambiguous visual reconstruction, but it would look ugly and it wouldn't necessarily be better than what you get via your ears. Or, hmm, you could look at the cheat as a feature that enables someone who's deaf to compete fairly.
Anything CPU intensive (and especially math intensive) is going to get a nice boost. LAME went from 2x encode to 4-5x encode by recompiling after playing with compiler settings (from defaults to using -march, -mcpu, -pipe, -fomit-frame-pointer, and a few others)
-pipe won't affect run speed, it affects only how the compiler communicates between passes internally.
In other words, the install takes forever, and does demand a fair bit of linux knowledge, but the process IS worth it, once you are finished.
Like many developers, I've considered switching from Debian Sid to Gentoo, because of Gentoo's reputation for being an up-to-the-minute distro that also has a good stability and is highly configurable. Though Debian has great strengths, particularly the massive number of maintainers that take their work so seriously, and a huge, detailed policy structure, it also has its limitations, such as no downgrades, breakage in important packages that sometimes lasts for months, and sometimes being a long way behind current development, KDE3 being an example of that.
Supposedly, Gentoo doesn't have the above problems. The only drawback of Gentoo I've heard about is the long initial compile. On a fast machine, it may not be that bad, but in the long run, something could be done about it. For example, certain common configurations could be pre-compiled and cached on a server that acts like a database, so some large chunks of code wouldn't have to be compiled for every install (much like Compiler Cache). Well, I'm sure the Gentoo guys have thought of that.
Another thing that could be done, and this would require some pretty serious gcc hacking, would be to compile the source into an intermediate form, something like java bytecode, or a tokenized version of the intermediate format gcc already uses, that is, RTL. The final code generation would happen on the installation target, so the intermediate binary would be cross-platform. RTL might not work for this because of processor specific features and other problems (I haven't yet looked at it closely enough to know for sure) so ideally, you'd design a new intermediate form that's ideally suited to the problem, optimized both for accurate representation of the partly-compiled code, and for quick code generation.
Needless to say, this would be a massive amount of work, but it would also be a legendary hack.
Regardless of the above, I think I'll install Gentoo on the next machine that comes in here.
Of course it's not the only security problem. Anyone who thinks that any piece of complex software is 100% secure is kidding themself.
Other next-gen phones will have issues.
But don't you think that Microsoft's Smartphone will have more security holes than all the others put together, and worse ones? It's a tradition, after all.
I work for Microsoft (program manager for Mac Internet Explorer), and I own a 2002 BMW 745i. Though the underlying OS the vehicle is running is Windows CE for Automotive...
Thanks. I've been thinking about upgrading my BMW, and now I know which model to avoid.
What idiot modded this guy up?
Well, of course if you're a pro Astroturfer you get your astroturfer friends to mod you up, or use your alternate accounts. Whatever. In a business sense, the astroturfers are a big win for Slashdot, since they create traffic, and lots of it. Unfortunately for Microsoft, that traffic tends to be overwhelmingly negative, and rich with interesting information supplied by clueful people, exposing various seamy strategies to unwelcome scrutiny. So astroturfing Slashdot is a self-defeating strategy for Microsoft.
The entire purpose of Internet Explorer was to put Netscape out of business, and it did essentially that.
That was only half the plan. The other half was to take over the client side of the web. At the same time, IIS would take over the server side, and Microsoft would hence own both sides of the communication link, and be able to coopt the protocols, "decommoditize" in Microsoft-speak. This plan was foiled by Linux, BSD and the Apache project, fortunately for the public.
Internet Explorer: Agreed - I can't see it benefiting MS with the exception of market share. Unless, however, there is a master plan in place to charge all those corporations/individuals royalty fees in future for embedding the IE rendering component within applications.
That was the plan all right, but it's now essentially dead because Apache refuses give up its dominant share of the web server market. Without control of both sides of the link, Microsoft can't force netizens into using its proprietary content delivery systems. It would take force to make people use these, because they won't do it willingly, so long as the content is heavily restricted.
Now, it's become more dangerous both in a legal and mindshare sense for Microsoft to further leverage its OS monopoly in attempts to extend control over browser content. Big defeat for Microsoft here, and a big win for the public.
"Stattdessen soll Embedded Linux mit 27 Prozent zur bei weitem am häufigsten eingesetzten Plattform werden"
27% is not 50%. But even so, 50% does not imply a standard, it just means it's the most popular.
Allow me to help you a little with the language. It says: "[in future projects] Embedded Linux should become by far the most widely deployed platform, with 27 percent" and goes on to say:
"Fast die Hälfte der Embedded-Entwickler will innerhalb der nächsten zwölf Monate eine Anwendung für Linux oder ein anderes Open-Source-System fertigstellen", that is, "Almost half of Embedded developers want to do a project with Linux or another Open Source system within the next 12 months."
So half of embedded developers plan to use Linux (or BSD as most likely second choice) for a project this year, Linux will have 27% of all projects, more than twice the second place platform, CE. While I would not describe this as a "takeover" in so many words, it is certainly a "dominant" position, apparently well on its way to "takeover".
The "Security" problem enabled people to hack the provisioning of the phone, during (and only during) it's first-time boot. To take advantage of it, you must do a manual hard-reset, then manually copy a file across at the right point of the boot. It wasn't easy and usually took several attempts to get right.
So... then that must surely be the *only* Smartphone security problem? And I should not worry, because there's no other possible exploit for the security hole already found?
So, you're wrong: MMAP does work over NFS.
I meant shared mmap, i.e., multi-host. Pardon me for not being specific.
Try this: mmap the same file on two different hosts, then write the same file location on each host via the mmap with different data. Result: two different versions of the file, and it's random which one is finally written to disk. Also, write one host's mmap, read on the other. Result: it's random whether one host sees what the other wrote.
A clustered filesystem that fails as above is not worthy of the name. It's also important to do the shared mmap efficiently, and GFS does.
I know that this is going to be the most common answer, but just go with NFS. It's not the most secure option around, but obviously the simplest to implement and the best documented.
NFS has a lot of problems, the worst of which you can summarize as: it doesn't act the same as a local filesystem. For example, mmap just doesn't work over NFS. Anyway, NFS is properly called a network filesystem, not a distributed filesystem. It lacks a lot of features you'd expect in a distributed filesystem, such as disconnected operation.
Have you ever worked in a shop where the home directories are mounted on NFS? The server stops and everybody freezes. This is not nice. NFS has horrible security holes too. The best thing about NFS is, it's commonly available, and you can also say that it's a lot better than no network filesystem at all.
As far as I can see, GFS, the Global Filesystem by Sistina is better than NFS in every way. It actually provides POSIX semantics, including mmap, over the network, which is a pretty nice trick. It's considerably faster than NFS. It acts just like a local filesystem, even though it's not. You can even use it as a local filesystem, like Ext2/3.
Caveat: I recently joined Sistina as a kernel developer, though at the moment I'm working in the logical volume manager group ratjer than GFS. While GFS is a commercial product, we also have OpenGFS, a sourceforge project forked from the most recent GPLed release of GFS from Sistina. Developers on the OpenGFS project include Alan Cox and Christoph Hellwig, i.e., its supported by core Linux developers.
I believe we'd all be better off in the long run if GFS takes over and NFS gradually dies out. I'll make an analogy betweedn NFS and rsh: rsh filled a need at one time, but it's broken by design (plaintext passwords). These days, nobody uses rsh and everybody uses ssh, which by the way, is also available in both commercial and open versions. (Note that while the OpenGFS project may not be strictly compatible with Sistina GFS, it shares the same goals in terms of POSIX compliance, performance characteristics, etc.)
it's your kind of short-sighted thinking that got us into the current address space shortage. It's not 128 bits for reasons we can think of now, it's 128 bits because of the reasons we can't think of.
"Exactly: you can't think of a reason why it's good, but we can think of several reasons why it's bad. That kind of engineering is stupid. I stand by my prediction that because of this and other dumb mistakes, ipv6 will never be generally adopted, it will be found only in niches or hidden away in backbones, not adopted wholesale by end users."
Waitaminute. The reason you say it's bad has to do with the fact you can't remember that many bits anymore. What's all the other reasons that 128 bits is bad? Too much bandwidth consumed to build the IPv6 header??
You can't remember that many bits either, or I will eat this disk. Nobody can, so that's already a big, fat (that's "big", "fat") problem.
It's not just that, of course. Will you ever have to type in all those, eh, "bits", as you call them? Yes you will. Sometimes you will have to do that. It takes 4 ("four") times as much typing to type in 128 (ehm) bits, as 32.
Current ip address notation, using decimal digits separated by dots, it's human-friendly. Push it to 128 bits and its just evil. However, at 5 bytes its still fine. Note: going to hex notation for 5 byte addresses would be a good idea. It saves typing and is easier to remember the addresses, if anything. On the downside, it could conceivable become easier to confuse a host name with an IP address. A little.
Did you ever set up WEP? Setting up WEP is painful. It wasn't meant to be done by humans. The numbers you have to type in are just too long, and you have to try many times, usually, because there are quite a few settings to tweak before you get it working. (Hey! Just like setting up a machine on the net!) Now, there's an excuse in the case of WEP. You do need a cryptographic key. But public net addresses are not cryptogrpahic keys. The shorter the better, from the point of view of usability.
Suppose postal codes had 35 digits. Do you think anyone would bother?
Now I don't expect you to understand the next point, but: give programmers an easy way out, and they get lazy. Let them route by indexing on a simple prefix of the net address, and they won't bother thinking up indexing algorithms for routers that work just as well, and don't rely on simple prefixes, but are a little harder to design.
In summary: going to 128 bits was just plain stupid, given that the problems are real and the benefits imaginary. Going to 40 bits would have been smart, it does the job with minimum fuss. For bonus points, write the RFC so that going to 48 bits later is painless, even though it's pretty obvious we won't be needing more than a trillian public addresses until we start colonizing the galaxy.
Anyway, we'll get another chance to do it right, because ipv6 is going to fail - it's never going to be widely deployed on personal computers. People will just keep using ipv4 with NAT, because ipv6 has too many problems.
Not just theoretical problems, but actual nasty, time wasting problems that get in your face. (And we didn't even talk about the way they dropped the ball on IPv4 address compatibility, or did we.)
It's your kind of short-sighted thinking that got us into the current address space shortage. It's not 128 bits for reasons we can think of now, it's 128 bits because of the reasons we can't think of.
Exactly: you can't think of a reason why it's good, but we can think of several reasons why it's bad. That kind of engineering is stupid. I stand by my prediction that because of this and other dumb mistakes, ipv6 will never be generally adopted, it will be found only in niches or hidden away in backbones, not adopted wholesale by end users.
I made a statement that GIFs can be made that most readers will accept and yet is patent free.
Bullshit, you were supporting a thesis that open source coders can always work around patents, which is, ahem, patently false. Even with your gif example, the workaround turns out to be inferior to the patent-encumbered version. The bright side is that GIF never was, and never will be, part of any official standard. However, it is (probably) well-meaning but (perhaps just seemingly) dull-witted people such as yourself that could steer the outcome of future gif-like stories towards a far worse outcome, where there is in fact no alternative but to pay the toll.
So, I'll modify "clueless" to "well-meaning but clueless" if you like. You certainly do not have a grasp of the situation, or you do, and you are trolling.
Maybe when they start sending nanotechnology to mars they want it all to have different ips?
Boy, you're in luck, because with 128 bits you can address every single atom in the galaxy, individually.
Maybe your identification card will have ip address?
I hope not, and even if it did, we are still far from the 100 IP addresses per person we could have with a 40 bit IP address instead of 128.
People who can't think of uses for advanced technology are definatly lacking in imagination.
People who justify bad designs with bogus arguments are hazardous.
Also there's a lot more to ipv6 than just more addresses...
But we're talking about the stupidity of 128 bit addresses.
So argueing against future proofing the address size isn't even addressing half the advantages of ipv6.
We're not talking about any aspect of ipv6 beyond the type of the address. By making it 128 bits you simply make it user-hostile, which is a fine kind of future-proofing.
Also when you say "MY toaster doesn't need to be networked" That sounds a lot like the visionless dumbasses who said "A laptop? Oh ya who is gonna carry a fricken computer around with them everywhere!" Well not only where those people morons but now we have PDAs that take laptops a whole step farther than anyone was expecting at that time.
OK, you give *your* toaster a public IP address, and call yourself a visionary.
Really you sound like one of those unemployed lamewads who sits around his public housing apartment talking about "Dude! Amiga for LIFE! Assembly is what REAL hackers use! You all suck!"
You should talk, my fine Anonymous Coward. Beyond your rhetoric, there's no substance.
Good thing "640k is enough for anyone" types such as yourself aren't responsible for anything
Excuse me for repeating myself, but we're not talking about memory, we're talking about public IP addresses. A byte of memory is not the same as an IP address. (And argument by analogy is just rhetoric.)
http://nl.linux.org/~phillips
"My question is simply, why does every appliance need an IP address?"
It doesn't. But in many cases it would be useful. How about an IP address for each envelope you put in the mail, so you can easily track them without relying on your local postal service?
Oh, and so my letter can serve me a web page as it crosses the Gobi desert?
How about not doing any such wrong-headed thing, and give your envelope a url instead, if you must. The things you want to do with an envelope just do not resemble the things an IP stack wants to do with a web host. In short, an envelope is not a web host, so does not need a web address, let alone a public one.
Now, go back and read your own post critically.
Which of your ideas requires an IP address and wouldn't work perfectly well with a url?
"For starters, it's essential that the old addressing scheme be a straightforward subset of the new one."
:0a14:1e28 (you convert the bytes to hex).
Actually, it is. There is a whole block of IPv6 which is the IPv4 address space. So if your IPv4 address is 10.20.30.40 your IPV6 address is
You're talking about rfc 2893 ipv4 compatibility? Well, "IPv4-compatible addresses are assigned exclusively to nodes that support automatic tunneling". Dumb dumb dumb.
The IPV6 designers spent (and continue to spend) far more time on the migration issues than on the actual protocol changes.
That's because they didn't make it enough like the current system, even though that would not have been hard to do. Come on, is this or is this not an observed fact?
If I could just drop in an IPv6 stack and have everything just work, I'd no doubt be running IPv6 right now, and I'd own at least one public IPv6 address. As it is, I don't own any IPv6 addresses because I wouldn't be able to connect to them from outside anyway. And yes, there would still need to be a way of enabling the most significant octet, but with the stack in place at home and at my ISP (because it just works, duh) we're already most of the way there.
"So you're advocating security through obscurity?"
:-)
Well, I think everyone advocates this. If you don't beleive in the obscurity thing, then tell me, what is your credit card number, bank account, ATM pin code, Slashdot password, etc..., or would you rather keep them secure by making them obscure?
It's not a credit card or bank account, it's an IP address. I will happily tell you my IP address, and you will still not be able to log onto my system.
But I've got advice for you: just don't tell anybody your IP address, then you can use your girlfriend's name for your ssh login, in complete confidence
Do you think before you post or just say what ever come out of your butt? Sorry, but this post is so uninformed that it is distrubing. IPv6 was designed from the ground up to deal with the existing limitations of IPv4; therefore, you would be an idiot to make things a subset of the existing design...
It's hard to see how you got modded as "informative". What I said was: "For starters, it's essential that the old addressing scheme be a straightforward subset of the new one." In other words, you read it backwards, dear Coward.
The primary design goals of it were to 1) Increase the # addresses available and to have addresses autoconfiguring. 2) Increase security 3) Improve network routing and ease network autoconfiguration. IPv6 accomplishes all these goals and very well.
Maybe it does. But it falls flat on its ass on the big ones: compatibility and usability. Unfortunately, that's what you get when a design committee goes to work in splendid isolation, and without the benefit of talent.
"* For starters, it's essential that the old addressing scheme be a straightforward subset of the new one."
You can simply run dual stack. No problem in there.
Glad you think so. Tell that to all the admins that now have to change their setups from "one stack" to "multi-stack". And don't even try to tell me you won't get mysterious glitches.
"* What the heck was the idea of making it 128 bits, so no human can deal with the raw numbers?"
No human should ever want to, even in the IPv4 world.
That is utter bullshit. Either you have never done any admin, or you have Alzheimer disease.
We've got a nice little thing called DNS which makes it possible to assign nice and easy names to those horrible numeric addresses.
Oh, and you've never had your DNS down? You never had to ping your gateway by IP address? You've never had to set up ARP? Track down mysterious problems using ipdump?
"* And we DON'T NEED TO BE ABLE TO ADDRESS EVERY THUMBTACK ON THE PLANET."
We don't need more than 640 K of memory either.
We are not talking about memory, we are talking about PUBLIC ip addresses (i.e., doesn't include the ones embedded in your stereo).
Let me try to explain this in terms you'll understand: when you were 1 year old, you were only two feet tall, so now you're a million miles high, right? Or to put it in precise terms: public addresses are not memory. They are not like memory. Analogies with memory do not support your argument. At all.
Thank you.