WinXP x86_64 shipped in the spring of 2005 and Vista followed about a year and a half later in Jan 2007.
Itanium 64-bit edition of WinXP shipped in 2003 but was later turned into abandonware - this version didn't run on EMT64 or AMD64 platforms so it saw minimal usage.
Re:Mirrors are still unavailable
on
Fedora 10 Released
·
· Score: 2, Informative
Portland State seems to be working. I'm just about done downloading a minimal set of packages.
Nothing could be further from the truth. There's an awful lot of cities and suburbs between Tokyo and Nagoya and Osaka where these lines will go first.
Not to mention mountains everywhere - the railroads and highways run through plenty of tunnels along this same stretch. Those tunnels had to be built, painfully, and one-by-one over the past several decades.
The right of way for rail is pretty small - there are business and residences on both sides of the track usually located very close.
The existing rail service has to keep going during construction which means a new right of way for the maglev lines. This isn't going to be easy or cheap and there will be plenty residents who fight to keep their land.
There will be a major fight between Yamanashi and Shizuoka prefectures over the line. Shizuoka has the Shinkansen line now and has benefited economically. Yamanashi has the test track (20km) already installed (thanks to Shin Kanemaru) but may not have the political power to take advantage of the test track and get the line to run through Koufu.
Building through a suburb in the US would be very easy by comparison. But nobody would ride it until gas hits 5$ or more and car maintenance costs go up to a level consistent with Japan or Europe.
These future use/8 blocks would be good to use but would require patches as many systems won't accept these or allow them to be used (hard coded in the TCP/IP stack).
I think this is one thing that will happen as the available pool shrinks. But this will cause problems on the systems that can't be upgraded because they have been end of life'ed.
If they had incentive, which they don't, then maybe they could renumber in a year as part of a crash program.
Stanford completed their IP renumbering in two years and returned a class A block. That block would last about 25 days at the current consumption rate.
So we spend a year and a lot of labor gaining back a year? How is this progress? Would't that time and energy better be spent on dual stacking everything in sight?
Red Hat needs to offer more info before you can make a solid judgement about this.
If the attacker gained access to the actual system where signing takes place then Red Hat needs to change the key.
But from the announcement wording - they are suggesting that the attacker was able to submit packages to be signed but the actual signing server was not compromised.
They should not have been so vague about this because it is a crucial distinction to make for their customer to make a security judgement.
As a customer I'm not happy with the vague details on what was compromised. I'm sure they did it because they have concerns about describing their package signing systems in detail but they need to open the kimono and give us the detail we need to make a decision about reloading our systems.
Merely saying, "trust us - anything that came from the official channel is safe" doesn't fly. You let an attacker gain unauthorized access - you need to re-earn trust at this point by giving us some detailed info.
I've been through several internal network renumbering projects to go from globally routable to rfc1918 and also from one 1918 space to another in the case of merger and acquisition.
I would definitely use IPv6 router renumbering to help automate the process but it doesn't mean I don't need to understand the network flows either way.
Router renumbering lets you perform an add prefix operation to get both prefixs in use. Then you update DNS and wait for sessions to restart naturally or you help that process along with some targeted restarts. After you monitor your network to ensure that the old prefix is no longer in use you can use a delete prefix operation to clean up the old stuff.
The process is pretty much the same doing it manually or using router renumbering. The advantage is that you can use IPv6 renumbering abilities to help the grunt work on the routers.
I don't think you understand IPv6 router renumbering.
You do do an add operation, update DNS, let sessions come up on the new prefix and then delete the old prefix once you are sure all the old sessions are gone.
IPv4 renumbering does take place even for RFC1918 networks, during mergers or acquisition. When this happens - you end up doing a manual version of the IPv6 process and you still have to manage ending sessions.
BGP - While it was a stated goal to try to force hierarchical routing tables in IPV6 - this is not a requirement of IPv6 BGP. You can multi-home in exactly the same way than you can in IPv4 BGP. In both cases upstream ASNs are working to try to minimize routing table growth.
This ICMPv6 rant makes no sense at all. MTU discovery is optional - as an adminstrator - you can decide not to use it. As a firewall administrator - you must know that any rules that allows based on IP type or port number is subject to tunneling abuse. If you want to prevent that you need to use application proxies and not a packet filter.
While the origin of EC2 in 2006 is certainly related to peak capacity requirements at Amazon, it is certainly way beyond that point now.
Two Christmas seasons have come and gone without major capacity problems on EC2.
The reality is that EC2 has grown far beyond its roots as a way for Amazon to amortize their peak capacity by reselling it and it has turned into a small but growing profit center and publicity success for Amazon.
The supreme court ordered that the trial could proceed during President Clinton's term since it was a private suit and not related to his official duties as the President.
Slashdot Mirror
I don't know about several years.
WinXP x86_64 shipped in the spring of 2005 and Vista followed about a year and a half later in Jan 2007.
Itanium 64-bit edition of WinXP shipped in 2003 but was later turned into abandonware - this version didn't run on EMT64 or AMD64 platforms so it saw minimal usage.
Portland State seems to be working. I'm just about done downloading a minimal set of packages.
Mythvideo can be a frontend to Xine/Mplayer.
It has _always_ been that way.
The built-in "Internal" video player is default but it is completely optional. It appeared a couple of releases ago.
Nothing could be further from the truth. There's an awful lot of cities and suburbs between Tokyo and Nagoya and Osaka where these lines will go first.
Not to mention mountains everywhere - the railroads and highways run through plenty of tunnels along this same stretch. Those tunnels had to be built, painfully, and one-by-one over the past several decades.
The right of way for rail is pretty small - there are business and residences on both sides of the track usually located very close.
The existing rail service has to keep going during construction which means a new right of way for the maglev lines. This isn't going to be easy or cheap and there will be plenty residents who fight to keep their land.
There will be a major fight between Yamanashi and Shizuoka prefectures over the line. Shizuoka has the Shinkansen line now and has benefited economically. Yamanashi has the test track (20km) already installed (thanks to Shin Kanemaru) but may not have the political power to take advantage of the test track and get the line to run through Koufu.
Building through a suburb in the US would be very easy by comparison. But nobody would ride it until gas hits 5$ or more and car maintenance costs go up to a level consistent with Japan or Europe.
I've got a mythbox sitting in Yamanashi. I think I'll find something to do with this upstream....
They already do.
These future use /8 blocks would be good to use but would require patches as many systems won't accept these or allow them to be used (hard coded in the TCP/IP stack).
I think this is one thing that will happen as the available pool shrinks. But this will cause problems on the systems that can't be upgraded because they have been end of life'ed.
I can't believe this got modded up. Please turn in your geek credentials at the door.
You do know that a single IP PAT can only handle 65K connections simultaneously, right?
And that a single web application or web site may require multiple connections simultaneously.
And that if they used the 10.0.0.0/8 space they would only have 16 million IP addresses for use inside the country?
China already has internet connections that are on a NAT behind another NAT. This is exactly the kind of crap the internet doesn't need any more of.
If they had incentive, which they don't, then maybe they could renumber in a year as part of a crash program.
Stanford completed their IP renumbering in two years and returned a class A block. That block would last about 25 days at the current consumption rate.
So we spend a year and a lot of labor gaining back a year? How is this progress? Would't that time and energy better be spent on dual stacking everything in sight?
http://www.google.com/support/chrome/bin/answer.py?answer=95282&query=java&topic=&type=
You currently have to install JRE6 update 10 which is still a release candidate to get this working.
Flash just worked for me - not sure on that one
Red Hat needs to offer more info before you can make a solid judgement about this.
If the attacker gained access to the actual system where signing takes place then Red Hat needs to change the key.
But from the announcement wording - they are suggesting that the attacker was able to submit packages to be signed but the actual signing server was not compromised.
They should not have been so vague about this because it is a crucial distinction to make for their customer to make a security judgement.
As a customer I'm not happy with the vague details on what was compromised. I'm sure they did it because they have concerns about describing their package signing systems in detail but they need to open the kimono and give us the detail we need to make a decision about reloading our systems.
Merely saying, "trust us - anything that came from the official channel is safe" doesn't fly. You let an attacker gain unauthorized access - you need to re-earn trust at this point by giving us some detailed info.
Unless you are bought out, in which case you often have to renumber to fit into the new company scheme.
Isn't this a problem with IPv4 renumbering also?
I've been through several internal network renumbering projects to go from globally routable to rfc1918 and also from one 1918 space to another in the case of merger and acquisition.
I would definitely use IPv6 router renumbering to help automate the process but it doesn't mean I don't need to understand the network flows either way.
Router renumbering lets you perform an add prefix operation to get both prefixs in use. Then you update DNS and wait for sessions to restart naturally or you help that process along with some targeted restarts. After you monitor your network to ensure that the old prefix is no longer in use you can use a delete prefix operation to clean up the old stuff.
The process is pretty much the same doing it manually or using router renumbering. The advantage is that you can use IPv6 renumbering abilities to help the grunt work on the routers.
This is FUD
I don't think you understand IPv6 router renumbering.
You do do an add operation, update DNS, let sessions come up on the new prefix and then delete the old prefix once you are sure all the old sessions are gone.
IPv4 renumbering does take place even for RFC1918 networks, during mergers or acquisition. When this happens - you end up doing a manual version of the IPv6 process and you still have to manage ending sessions.
BGP - While it was a stated goal to try to force hierarchical routing tables in IPV6 - this is not a requirement of IPv6 BGP. You can multi-home in exactly the same way than you can in IPv4 BGP. In both cases upstream ASNs are working to try to minimize routing table growth.
This ICMPv6 rant makes no sense at all. MTU discovery is optional - as an adminstrator - you can decide not to use it. As a firewall administrator - you must know that any rules that allows based on IP type or port number is subject to tunneling abuse. If you want to prevent that you need to use application proxies and not a packet filter.
You can assign yourself an IPv6 address you know. You don't have to use autoconfiguration.
IPv6 has a feature that allows an admin to renumber an entire network quickly an easily.
See RFC2894
Back to my Mac uses IPv6 via 6to4 tunnel.
His blog was unavailable for a while but it came back online several days ago.
http://aseigo.blogspot.com/
While the origin of EC2 in 2006 is certainly related to peak capacity requirements at Amazon, it is certainly way beyond that point now.
Two Christmas seasons have come and gone without major capacity problems on EC2.
The reality is that EC2 has grown far beyond its roots as a way for Amazon to amortize their peak capacity by reselling it and it has turned into a small but growing profit center and publicity success for Amazon.
The supreme court ordered that the trial could proceed during President Clinton's term since it was a private suit and not related to his official duties as the President.
Impeachment is a political process. A US president can be impeached and convicted of anything if the house and senate votes are there.
Man this whole clinton thing is so overdone but here goes
http://www.washingtonpost.com/wp-dyn/articles/A13173-2005Mar7.html
This might have been an interesting question to ask about 7-8 years ago but now it just seems like Bruce is running out of topics.
People like to post and read from their keitai - simple sites work best.
This is the site where the Densha Otoko saga played out.