Five years is still a long time to wait for a book or film that everyone else has read / watched.
Indeed. Around here you can get almost any book at the library around 6 months after its release. Yet people still buy books.
Also, I have several copies of books which were available electronically for free (legally) at the time I bought them. The publishers paid the authors, even though they weren't obliged to -- but otherwise I probably wouldn't have bought the books.
On x86, a context switch (between processes - threads don't do a full context switch) requires a TLB flush, which means that the next few hundred memory accesses will all involve a TLB miss, which means that they will require the CPU to walk the page tables.
That's what software thinks is happening. However, on x86 the hardware is responsible for the page tables, so it tags the TLB entries behind the scenes.
On SPARC, it requires updating the context ID register. A SPARC context switch has about the same cost as a function call.
A SPARC context switch has to save all the damn registers. All 192 of them or however many they have these days. Even if it's just a thread switch. Probably twice. Function calls get away with moving the register window, which is a lot faster.
Targeted is a form of enforcing. The opposite of targeted is strict, the opposite of enforcing is permissive. Any combination is possible, including strict permissive (which won't actually do anything except write a lot to your logs).
Most applications have inherently parallel workloads that are implemented in sequential code because context switching on x86 is painfully expensive.
Context switching on x86 is dead cheap. It's probably the cheapest of all general purpose architectures available right now. We're talking a few hundred cycles cheap. Only the P4 is a bit behind, and Nehalem makes things faster, to the point where Intel almost catches up with AMD.
Windows manages to make process switches a lot more expensive than necessary, but thread switching isn't bad. With Linux it hardly matters whether you switch processes or threads, they're both fast.
Why in god's name would you statically encode IP addresses when the DNS system is sitting right there to make sure you don't have to do that manual work?
Because that's how firewalls work, in general. Some firewalls will helpfully resolve domain names into IP addresses, but there's no guarantee that the IP addresses that the firewall gets from DNS are the same the client gets, so that is a dead end too.
To do better you need to look into the actual HTTP session. If the poster had a firewall which could do that, he would most likely know, and therefore wouldn't ask the question in the first place.
So, I don't think it would make sense to pick it as a language for a new web application project unless you happen to have legacy perl code to integrate. That makes it a legacy language
In fact there is a YouTube video of some masochists, booting Linux on their PS3, then running Windows XP in VM Ware, crazy, considering there is not a LOT of memory there!
Those would be fakes then. PS3 is a PPC-based system. VMWare doesn't run on PPC. You could do it in Qemu, but it would be so slow that there would be no point.
You sound as if there's a list of a hundred points I forgot. In fact, the only other thing is that IPv6 headers don't have a checksum. Calculating the checksum is completely trivial when you are doing it in hardware, and if you're doing it in software, the IP header is in L1 cache, so you can fix it up faster than you can access memory or I/O anyway.
I'm pretty sure the idea was considered and there was a valid reason (not the obviously invalid reasons about trouble holding the market captive) for not considering it, but it sure seems to me like (it could have been) a great solution.
Variable-length addresses were considered but it was decided that it would make hardware routing too difficult and in general it would be too complicated.
At the time IPv6 was conceived, IPv4 wasn't such a dominant protocol (obviously it was on the Internet, but not in the enterprise or the LAN). People believed that it was possible to have an extra protocol running without too much trouble. In hindsight, a variable-length solution with classic IPv4 as a special case would have been better -- simply because it has a chance of being deployed. Hardware cost wouldn't be a problem, because only people needing the new-fangled addresses would have to pay it.
Waiting for a 3+ GHz ARM, so we can see whether Steve will switch again.
Start by getting FPU's into common ARM implementations...
There's also the fact that with NAT nobody outside knows for sure there's more than the single machine connected.
It is generally trivial to find out whether a traffic pattern is coming from one or several machines, whether they are behind NAT or not. The only thing you can't find out easily is which private addresses are in use. Not really a problem, there are only 4 billion IPv4 addresses, just try them all.
There were other considerations during the reinvention. In particular, IPV6 routing requires much less cpu power.
"Much" is debatable. All you get at the individual packet level is that the router doesn't have to fragment packets. That's practically a nonproblem anyway, since 90%+ of routing is done between interfaces where fragmentation can't happen, and even in the cases where fragmentation can happen, it doesn't for 99%+ of the traffic.
If you have a route lookup table in hardware (like Cisco tends to do), IPv6 requires more space. Somewhat mitigated by the fact that there should be fewer routes overall, since deaggregation should hopefully be almost non-existent. Either way, a current high-end Cisco router has 256,000 spots for IPv6 routes before it croaks, so Cisco gear is basically useless if IPv6 takes off... Anyway, IPv6 won't take off, so that isn't a problem.
Having a bunch of unemployed rocket scientists roaming the world did not seem like an especially good idea at the time. We can just deorbit ISS if the cold war comes back in full force.
Now if the ISS was actually something important that the countries in the joint venture couldn't do without, you would have a point.
If a country sends thousands of its citizens to settle in an occupied part of a different country, does that part then belong to the people who were sent there?
Wait 5 years, and you'll see that exact quote. Just like when XP came out and a lot of people preferred 2000 or 98. Or when 95 came out and a lot of people preferred 3.11 (Yes, that one is pure madness).
People will get used to Vista, and drivers will get better. Meanwhile I'll stick to Linux, of course.
The company I'm working for has bought several hundred WRT54GL in order to run OpenWRT. We're switching to Routerboards for most new deployments though (running RouterOS, not OpenWRT).
Both HP and Dell make a number of Linux systems and if foxconn have such an attitude towards linux support, it's likely their orders from hp/dell will decrease...
BIOS programming is the lowest programming job there is. It's where those people too dumb to handle a call center end up. HP BIOS's aren't any better.
Slashdot Mirror
Only if there are exploitable holes in the kernel. For anything else, you can just restart the service.
But there are.
Five years is still a long time to wait for a book or film that everyone else has read / watched.
Indeed. Around here you can get almost any book at the library around 6 months after its release. Yet people still buy books.
Also, I have several copies of books which were available electronically for free (legally) at the time I bought them. The publishers paid the authors, even though they weren't obliged to -- but otherwise I probably wouldn't have bought the books.
On x86, a context switch (between processes - threads don't do a full context switch) requires a TLB flush, which means that the next few hundred memory accesses will all involve a TLB miss, which means that they will require the CPU to walk the page tables.
That's what software thinks is happening. However, on x86 the hardware is responsible for the page tables, so it tags the TLB entries behind the scenes.
On SPARC, it requires updating the context ID register. A SPARC context switch has about the same cost as a function call.
A SPARC context switch has to save all the damn registers. All 192 of them or however many they have these days. Even if it's just a thread switch. Probably twice. Function calls get away with moving the register window, which is a lot faster.
Puzzle Pirates is persistent and has no quests. The only non-persistence is brigands/barbarians which sail around for no apparent reason.
(Ok, it has three non-persistent quests, but those were only added a month ago or so, and they're rather silly.)
In a production environment where you're likely to have 13 month uptimes, that would mean a reinstall every time you reboot the machine.
Upgrade != reinstall. And if security updates worry you, a 13 month uptime is a bad idea.
I believe /lib/ld-linux.so.2 actually checks that the partition isn't mounted noexec. That doesn't make relying on noexec safe, of course.
However, selinux can do it securely (even if it could be a pain to define the policy).
Targeted is a form of enforcing. The opposite of targeted is strict, the opposite of enforcing is permissive. Any combination is possible, including strict permissive (which won't actually do anything except write a lot to your logs).
Most applications have inherently parallel workloads that are implemented in sequential code because context switching on x86 is painfully expensive.
Context switching on x86 is dead cheap. It's probably the cheapest of all general purpose architectures available right now. We're talking a few hundred cycles cheap. Only the P4 is a bit behind, and Nehalem makes things faster, to the point where Intel almost catches up with AMD.
Windows manages to make process switches a lot more expensive than necessary, but thread switching isn't bad. With Linux it hardly matters whether you switch processes or threads, they're both fast.
Why in god's name would you statically encode IP addresses when the DNS system is sitting right there to make sure you don't have to do that manual work?
Because that's how firewalls work, in general. Some firewalls will helpfully resolve domain names into IP addresses, but there's no guarantee that the IP addresses that the firewall gets from DNS are the same the client gets, so that is a dead end too.
To do better you need to look into the actual HTTP session. If the poster had a firewall which could do that, he would most likely know, and therefore wouldn't ask the question in the first place.
I mean, CO2 doesn't cause cancer, or kill animals, or cause acid rain, blacken the skies, etc
The others won't kill us off as a species, that is practically guaranteed. CO2 probably won't either, but it could.
So, I don't think it would make sense to pick it as a language for a new web application project unless you happen to have legacy perl code to integrate. That makes it a legacy language
Not everything is a web application.
In fact there is a YouTube video of some masochists, booting Linux on their PS3, then running Windows XP in VM Ware, crazy, considering there is not a LOT of memory there!
Those would be fakes then. PS3 is a PPC-based system. VMWare doesn't run on PPC. You could do it in Qemu, but it would be so slow that there would be no point.
That's not all you get at the packet level.
You sound as if there's a list of a hundred points I forgot. In fact, the only other thing is that IPv6 headers don't have a checksum. Calculating the checksum is completely trivial when you are doing it in hardware, and if you're doing it in software, the IP header is in L1 cache, so you can fix it up faster than you can access memory or I/O anyway.
The WRT54G is software upgradable to IPv6. If IPv6 should take off, it's likely that they will, and otherwise you just need a third party firmware.
I'm pretty sure the idea was considered and there was a valid reason (not the obviously invalid reasons about trouble holding the market captive) for not considering it, but it sure seems to me like (it could have been) a great solution.
Variable-length addresses were considered but it was decided that it would make hardware routing too difficult and in general it would be too complicated.
At the time IPv6 was conceived, IPv4 wasn't such a dominant protocol (obviously it was on the Internet, but not in the enterprise or the LAN). People believed that it was possible to have an extra protocol running without too much trouble. In hindsight, a variable-length solution with classic IPv4 as a special case would have been better -- simply because it has a chance of being deployed. Hardware cost wouldn't be a problem, because only people needing the new-fangled addresses would have to pay it.
Waiting for a 3+ GHz ARM, so we can see whether Steve will switch again.
Start by getting FPU's into common ARM implementations...
There's also the fact that with NAT nobody outside knows for sure there's more than the single machine connected.
It is generally trivial to find out whether a traffic pattern is coming from one or several machines, whether they are behind NAT or not. The only thing you can't find out easily is which private addresses are in use. Not really a problem, there are only 4 billion IPv4 addresses, just try them all.
There were other considerations during the reinvention. In particular, IPV6 routing requires much less cpu power.
"Much" is debatable. All you get at the individual packet level is that the router doesn't have to fragment packets. That's practically a nonproblem anyway, since 90%+ of routing is done between interfaces where fragmentation can't happen, and even in the cases where fragmentation can happen, it doesn't for 99%+ of the traffic.
If you have a route lookup table in hardware (like Cisco tends to do), IPv6 requires more space. Somewhat mitigated by the fact that there should be fewer routes overall, since deaggregation should hopefully be almost non-existent. Either way, a current high-end Cisco router has 256,000 spots for IPv6 routes before it croaks, so Cisco gear is basically useless if IPv6 takes off... Anyway, IPv6 won't take off, so that isn't a problem.
It is probably impossible to find a person who has not done a thing considered "evil". Yet most people don't think of the whole population as "evil".
Reasons for doing evil things include being forced to choose between a lesser evil and a greater evil, or simply making mistakes.
hence the command: "DO NO EVIL!"
Google's motto is "Don't be evil". The difference is subtle but significant.
I can guarantee you right now that Europe would sell the Baltic states back to Russia if it came to push and shove.
We'd be right back to the cold war if that happened. No trade between EU/Nato and Russia. It would be a very cold war for Poland, come winter...
Having a bunch of unemployed rocket scientists roaming the world did not seem like an especially good idea at the time. We can just deorbit ISS if the cold war comes back in full force.
Now if the ISS was actually something important that the countries in the joint venture couldn't do without, you would have a point.
The land belongs to the people who live there.
If a country sends thousands of its citizens to settle in an occupied part of a different country, does that part then belong to the people who were sent there?
Funny, I actually liked XP.
Wait 5 years, and you'll see that exact quote. Just like when XP came out and a lot of people preferred 2000 or 98. Or when 95 came out and a lot of people preferred 3.11 (Yes, that one is pure madness).
People will get used to Vista, and drivers will get better. Meanwhile I'll stick to Linux, of course.
The company I'm working for has bought several hundred WRT54GL in order to run OpenWRT. We're switching to Routerboards for most new deployments though (running RouterOS, not OpenWRT).
Both HP and Dell make a number of Linux systems and if foxconn have such an attitude towards linux support, it's likely their orders from hp/dell will decrease...
BIOS programming is the lowest programming job there is. It's where those people too dumb to handle a call center end up. HP BIOS's aren't any better.