Hosting with cheap hosting companies probablly wouldn't bring what a provider like akamai needs which is high bandwidth, low (or zero) cost per traffic connections to end users. The cost for the rackspace is probablly negligable compared to the advantages (both to akamai and the company hosting the server) to getting the machines in the right place network wise.
IIRC who pays who with akamai servers varies, sometimes akamai will pay a provider to host a server and sometimes a provider will pay akamai to provide them with one (having an akamai server locally saves bandwidth costs).
And constantly re-scanning everything in existance every 10 years is not an option.:-( Probablly the best option at the moment is to keep the data live on servers. As servers become unreliable or uneconomical they get replaced with new ones that store more for a given cost and size. Hard drives are now big enough that this form shouldn't be cost prohibitive. If we assume a megabyte per page (which is way more than needed for most documents) and 1000 pages per book then that is still a couple of thousand books on a modern hard drive!
Formats becoming obsolete is a possible concern but pdf, png, jpeg etc have all been with us for over a decade and have multiple implementations in both closed and open source software so I don't see the ability to read them going away any time soon and if support does start to decline it should be a gradual process with plenty of warning to get the data converted.
That is partly because it was a construction before it's time and as such relied on some pretty specialised equipment. It was also an interactive system which is always more complex to handle than noninteractive stuff in standard formats.
Had it just relied on a BBC micro i'm sure the roms sites would have kept copies and got it running in emulators no problem. The real problem was the special laserdisk player that the system relied on.
That's a TV resolution, not a monitor resolution. That was the case a few years ago but while 1920x1200 is still available but the price is much higher (about 2x) and the selection much lower than at 1920x1080.
Of course there is a positive feedback loop here. 1920x1200 costs WAY more than 1920x1080 so fewer people will buy it so it will become even more expensive with even less selection.
This was the case a few years back (and may still be be for old stock). Looking at my favorite computer parts vendors (dabs.com) I see the following
4:3 resoloutions 1024x768: 2 models in stock with the lowest priced costing £306.66 1280x1024: 19 models in stock with the lowest price consistently reported* costing £99.99 1600x1200 1 model in stock costing £365.38
16:10 resolutions 1440x900: 3 models in stock starting at £117.48 1680x1050: 9 models in stock starting at £94.58 1920x1200: 3 models in stock starting at £270.23 2560x1600: 1 model in stock costing £1,132.85
16:9 resoloutions
1366x768: 8 models in stock starting at £75.20 1600x900: 3 models in stock starting from £120.19 1920x1080: 28 models in stock starting from £93.98
Looking through this the only economical option is 1920x1080, going lower means paying about the same price for less pixels. Going higher means a huge price premium.
* There is a slightly cheaper model listed but while the specs says 1280x1024 the description says 1280x3000?!
IIRC back in the days of CRTs I could run 1600x1200 on a reasonable 19 inch monitor.
Nowadays looking at my preffered computer parts supplier I see 1920x1200 monitors cost twice as much as 1920x1080 ones and 1600x1200 monitors cost three times as much as 1920x1080 ones. Further the 1920x1200 monitors are desk hogs, sure they don't have the depth of a CRT but a 24 inch 16:10 is going to be a LOT wider than a 19 inch 4:3.
It's easy to see why, most lusers don't understand pixels so marketing wants big screens damn. Similarlly many users have been convinced that widescreen is a good thing when in fact what it really means is that you get LESS screen area per inch of diagonal (and with 16:9 you get less screen area per inch than with 16:10)! Further 1920x1080 panels have large economies of scale than other resoloutions due to their use in "full HD" TVs.
Further afaict many low end PCs (at least the ones the uni buys) are now shipping with 1440x900 screens which have less vertical resoloution than the 1280x1024 screens which were the previous low end option.
So i'd say vertical resoloutions for affordable screens have in the best case stayed about constant and in some cases regressed.
Remember that fonts sizes are based off the size of your physical display, and have no relation to the number of pixels used to render them. No font sizes are based on the number of pixels and the "assumed DPI". Depending on your system the assumed DPI may or may not bear any resemblence to the real DPI and may or may not be sane to change away from it's default value.
Yeah with hospital equipment I can see it, as you say it's moved about a lot and it's generally pretty obvious whether it is in use or not.
With servers in the datacenter they tend to stay in one place and it's much harder to tell if they are in use for something unless records are kept religously. A server may only be used once a month yet have some crucial task when that time of the month comes up.
But there is no cure for SSL!. SSL requires a unique IP address for every domain. This is a hard limit that no networking trickery can avoid. Not exactly, there are two ways to host multiple SSL domains on one IP, unfortunately both have major downsides.
You can have one certificate that covers multiple domains. Afaict this is widely supported by clients but it's a PITA for server admins and requires a cooperative CA (this is particually likely to be an issue if the domains are owned by multiple entities).
You can also use an extention called server name indication. The trouble with this is that XPs built in ssl support doesn't support it so it's basically dead in the water until such time as IE/chrome/safari on XP (firefox uses it's own SSL stack) no longer represent a significant proportion of the browser market.
That is unless your ISP won't give you addresses.... Right now it's not really in an ISPs interests to restrict the addresses it gives each customer more than they are required to by the RIR (iirc they can give up to something like 8 addresses to a customer no questions asked and after that justification from the customer is required). The more IPs the ISP gets now the more they have to reuse later.
All that is likely to change once new allocations stop. Then ISPs are going to have to start figuring out how best to distribute that fixed size pool of IPs among thier customers. For home users that likely means nat will change from being something running on a box they control and can port forward through to being something run by the ISP.
You'd still need to upgrade all clients to understand long ips before you gave even one server a long ip, or some clients wouldn't be able to connect. True but I belive it would have been much easier to get client OSes and core internet infrastructure upgraded on a gradual basis than to try and run two complete parallel networks with separate administration, addressing etc.
Of course it's too late for any new protocol now and probablly too late for smooth deployment of IPv6. Pervasive ISP level nat seems like the only medium term solution much as many/.ers will hate it's affects.
Regardless, what you're proposing for the long ips is fairly similar to 6to4, i.e. it's an IPv4 packet with some extra data for an extended address, which is routed as IPv4 by legacy equipment but provides an IPv6 connection. It's one of the many transition mechanisms. It's not so different but the key difference is that 6to4 was both an afterthought and not amenable to running behind nat with the result it didn't take off.
Thinking about it a better way would be to make packets to/from long IPs look like UDP packets to legacy infrastructure. Done right this would mean that not just existing routers but also existing nats could be used by clients accessing long IP based infrastructure.
That way the only things that would need upgrading in existing deployments would have been end systems,core routers* and possiblly firewalls. Even with core routers long IP support could be phased in gradually by setting legacy routers to route all long IP traffic to one long IP capable router.
* defined as routers that import the internet routing table to decide which ISP to send traffic to.
the only competitive advantage is the ability to refine the ore economically with low environmental impact. Or the ability to refine it economically without giving a fuck about the environmental impact.
I think the problem with *-to-html converters is they are often trying to force html to be something it isn't. HTML is designed to create reflowable content for the web not pixel perfect fixed size (or scaled) documents.
Microsofts attempts to create "round trip support" by essentially encoding everything twice while understandable don't exactly make the code more readable either.
Just because trying to preserve exact layout in html is hard and messy and micosofts tools generate particulally shitty html doesn't mean generation of code for humans to read/edit is doomed to failure in general.
You do not want to learn shell scripting from generated code... IMO the generation process should be limited to taking the users input and "plugging it in" to a "template" command or short sequence of commands. If a process that is simple in the GUI is complex in the CLI then your system has a design fault.
It's not about teaching the user how to write complex scripts with lots of conditionals (manuals and tutorials are better for that). It's about teaching the users the command line equivalents of their GUI actions and hence creating a bridge between the "discoverability" of a GUI and the power and repeatability of a CLI.
So, what do I recommend to my family and friends? Should I continue to recommend quality CD's, DVD's, and correct storage procedures? Personally i'd avoid optical media, DVD-R seems a lot less reliable than CD-R and the low capacity per disc makes checking it a pita.
IMO the best setup depends on how much data you have but generally i'd try to keep the data active in multiple geographically seperated locations.
What do I do about changing file types? IMO the important thing is to get it into good stable formats at the time of archival. For photos jpeg, png or uncompressed tiff (you have to be careful with tiff because there are so many subformats with varying degrees of support) is probablly fine. For documents that probablly means keeping multiple copies, e.g. pdf to preserve exact layout and odf to preserve structure but possiblly at the cost of layout changing layter. For tabular data you want to get it into something like comma separated or tab separated. For video things are still rather unstable unfortunately but mpeg standards are likely to remain readable for a long time.
which very few systems make a straightforward task - sure, disk is okay, but have you ever tried to migrate, for example, NetBackup or Networker backup data from tape to tape? Why can't you just restore the data using the old system and then back it up again using the new one?
but eventually they will crash back down to reasonable levels when everyone realizes it is a sham. Take for example Cisco systems which made it up to a P/E of around 435 in 2000 but now sells for a P/E of 16.5. IMO assets trading way above their real value on the basis that some sucker will pay even more for them later are little different to a pyramid scheme.
Also, the apps never get "root-level access" unless you execute them with super user privileges. Installing a deb runs a number of scripts as root that can do whatever the hell the packager likes (either directly or if the packager wants to obfuscate what is going on by running binaries from the package).
Scaling down a large image in whatever format you get it in (which is usually JPEG at the moment since that is what most cameras output) and then compressing it for sending to a user seems like a pretty common usecase for an image compressor to me and a perfectly reasonable thing to compare them on.
It would be interesting to see them go head to head from a raw source. A JPEG source should be fine as long as it is at a much higher resoloution than the tests are encoded at. JPEG mostly throws away high frequency information and you throw that away when downsampling anyway.
IPv6 is not in demand, and will not BE in demand until there are new sites out there that don't have an IPv4 address because they can't get one I would expect it will be quite a long time after allocations run out at the RIRs (if ever) that buisness sites can't get IPV4 IPs. Prices will go up of course as people are competing over a limited pool of IPs but that doesn't mean they won't be able to get them.
Most IM file transfers have a fallback to server based transfer.
As for the other things many of them are things that ISPs would like to see the back of or at least charge you for a buisness account for.
As the GP says it's not a fun prospect but from the ISPs POV it will provide a way to keep providing the lusers with their facebook/im/email/youtube/etc while also providing another way to get more money out of the geeks. Win/win for the ISPs.
Slashdot Mirror
Hosting with cheap hosting companies probablly wouldn't bring what a provider like akamai needs which is high bandwidth, low (or zero) cost per traffic connections to end users. The cost for the rackspace is probablly negligable compared to the advantages (both to akamai and the company hosting the server) to getting the machines in the right place network wise.
IIRC who pays who with akamai servers varies, sometimes akamai will pay a provider to host a server and sometimes a provider will pay akamai to provide them with one (having an akamai server locally saves bandwidth costs).
And constantly re-scanning everything in existance every 10 years is not an option. :-(
Probablly the best option at the moment is to keep the data live on servers. As servers become unreliable or uneconomical they get replaced with new ones that store more for a given cost and size. Hard drives are now big enough that this form shouldn't be cost prohibitive. If we assume a megabyte per page (which is way more than needed for most documents) and 1000 pages per book then that is still a couple of thousand books on a modern hard drive!
Formats becoming obsolete is a possible concern but pdf, png, jpeg etc have all been with us for over a decade and have multiple implementations in both closed and open source software so I don't see the ability to read them going away any time soon and if support does start to decline it should be a gradual process with plenty of warning to get the data converted.
Heck, even the "Digital Doomsday book" lasted only 15 years instead of 1000! http://www.guardian.co.uk/uk/2002/mar/03/research.elearning [guardian.co.uk]
That is partly because it was a construction before it's time and as such relied on some pretty specialised equipment. It was also an interactive system which is always more complex to handle than noninteractive stuff in standard formats.
Had it just relied on a BBC micro i'm sure the roms sites would have kept copies and got it running in emulators no problem. The real problem was the special laserdisk player that the system relied on.
That's a TV resolution, not a monitor resolution.
That was the case a few years ago but while 1920x1200 is still available but the price is much higher (about 2x) and the selection much lower than at 1920x1080.
Of course there is a positive feedback loop here. 1920x1200 costs WAY more than 1920x1080 so fewer people will buy it so it will become even more expensive with even less selection.
This was the case a few years back (and may still be be for old stock). Looking at my favorite computer parts vendors (dabs.com) I see the following
4:3 resoloutions
1024x768: 2 models in stock with the lowest priced costing £306.66
1280x1024: 19 models in stock with the lowest price consistently reported* costing £99.99
1600x1200 1 model in stock costing £365.38
16:10 resolutions
1440x900: 3 models in stock starting at £117.48
1680x1050: 9 models in stock starting at £94.58
1920x1200: 3 models in stock starting at £270.23
2560x1600: 1 model in stock costing £1,132.85
16:9 resoloutions
1366x768: 8 models in stock starting at £75.20
1600x900: 3 models in stock starting from £120.19
1920x1080: 28 models in stock starting from £93.98
Looking through this the only economical option is 1920x1080, going lower means paying about the same price for less pixels. Going higher means a huge price premium.
* There is a slightly cheaper model listed but while the specs says 1280x1024 the description says 1280x3000?!
IIRC back in the days of CRTs I could run 1600x1200 on a reasonable 19 inch monitor.
Nowadays looking at my preffered computer parts supplier I see 1920x1200 monitors cost twice as much as 1920x1080 ones and 1600x1200 monitors cost three times as much as 1920x1080 ones. Further the 1920x1200 monitors are desk hogs, sure they don't have the depth of a CRT but a 24 inch 16:10 is going to be a LOT wider than a 19 inch 4:3.
It's easy to see why, most lusers don't understand pixels so marketing wants big screens damn. Similarlly many users have been convinced that widescreen is a good thing when in fact what it really means is that you get LESS screen area per inch of diagonal (and with 16:9 you get less screen area per inch than with 16:10)! Further 1920x1080 panels have large economies of scale than other resoloutions due to their use in "full HD" TVs.
Further afaict many low end PCs (at least the ones the uni buys) are now shipping with 1440x900 screens which have less vertical resoloution than the 1280x1024 screens which were the previous low end option.
So i'd say vertical resoloutions for affordable screens have in the best case stayed about constant and in some cases regressed.
Remember that fonts sizes are based off the size of your physical display, and have no relation to the number of pixels used to render them.
No font sizes are based on the number of pixels and the "assumed DPI". Depending on your system the assumed DPI may or may not bear any resemblence to the real DPI and may or may not be sane to change away from it's default value.
I thought for a given power IR lasers were more dangerous than visible because of the lack of a blink reflex.
Yeah with hospital equipment I can see it, as you say it's moved about a lot and it's generally pretty obvious whether it is in use or not.
With servers in the datacenter they tend to stay in one place and it's much harder to tell if they are in use for something unless records are kept religously. A server may only be used once a month yet have some crucial task when that time of the month comes up.
But there is no cure for SSL!. SSL requires a unique IP address for every domain. This is a hard limit that no networking trickery can avoid.
Not exactly, there are two ways to host multiple SSL domains on one IP, unfortunately both have major downsides.
You can have one certificate that covers multiple domains. Afaict this is widely supported by clients but it's a PITA for server admins and requires a cooperative CA (this is particually likely to be an issue if the domains are owned by multiple entities).
You can also use an extention called server name indication. The trouble with this is that XPs built in ssl support doesn't support it so it's basically dead in the water until such time as IE/chrome/safari on XP (firefox uses it's own SSL stack) no longer represent a significant proportion of the browser market.
That is unless your ISP won't give you addresses....
Right now it's not really in an ISPs interests to restrict the addresses it gives each customer more than they are required to by the RIR (iirc they can give up to something like 8 addresses to a customer no questions asked and after that justification from the customer is required). The more IPs the ISP gets now the more they have to reuse later.
All that is likely to change once new allocations stop. Then ISPs are going to have to start figuring out how best to distribute that fixed size pool of IPs among thier customers. For home users that likely means nat will change from being something running on a box they control and can port forward through to being something run by the ISP.
You'd still need to upgrade all clients to understand long ips before you gave even one server a long ip, or some clients wouldn't be able to connect.
True but I belive it would have been much easier to get client OSes and core internet infrastructure upgraded on a gradual basis than to try and run two complete parallel networks with separate administration, addressing etc.
Of course it's too late for any new protocol now and probablly too late for smooth deployment of IPv6. Pervasive ISP level nat seems like the only medium term solution much as many /.ers will hate it's affects.
Regardless, what you're proposing for the long ips is fairly similar to 6to4, i.e. it's an IPv4 packet with some extra data for an extended address, which is routed as IPv4 by legacy equipment but provides an IPv6 connection. It's one of the many transition mechanisms.
It's not so different but the key difference is that 6to4 was both an afterthought and not amenable to running behind nat with the result it didn't take off.
Thinking about it a better way would be to make packets to/from long IPs look like UDP packets to legacy infrastructure. Done right this would mean that not just existing routers but also existing nats could be used by clients accessing long IP based infrastructure.
That way the only things that would need upgrading in existing deployments would have been end systems ,core routers* and possiblly firewalls. Even with core routers long IP support could be phased in gradually by setting legacy routers to route all long IP traffic to one long IP capable router.
* defined as routers that import the internet routing table to decide which ISP to send traffic to.
the only competitive advantage is the ability to refine the ore economically with low environmental impact.
Or the ability to refine it economically without giving a fuck about the environmental impact.
I think the problem with *-to-html converters is they are often trying to force html to be something it isn't. HTML is designed to create reflowable content for the web not pixel perfect fixed size (or scaled) documents.
Microsofts attempts to create "round trip support" by essentially encoding everything twice while understandable don't exactly make the code more readable either.
Just because trying to preserve exact layout in html is hard and messy and micosofts tools generate particulally shitty html doesn't mean generation of code for humans to read/edit is doomed to failure in general.
Have you ever seen generated code?
Yes
You do not want to learn shell scripting from generated code...
IMO the generation process should be limited to taking the users input and "plugging it in" to a "template" command or short sequence of commands. If a process that is simple in the GUI is complex in the CLI then your system has a design fault.
It's not about teaching the user how to write complex scripts with lots of conditionals (manuals and tutorials are better for that). It's about teaching the users the command line equivalents of their GUI actions and hence creating a bridge between the "discoverability" of a GUI and the power and repeatability of a CLI.
Any app that wants to do so can pass them though and afaict many activation/license management systems do.
So, what do I recommend to my family and friends? Should I continue to recommend quality CD's, DVD's, and correct storage procedures?
Personally i'd avoid optical media, DVD-R seems a lot less reliable than CD-R and the low capacity per disc makes checking it a pita.
IMO the best setup depends on how much data you have but generally i'd try to keep the data active in multiple geographically seperated locations.
What do I do about changing file types?
IMO the important thing is to get it into good stable formats at the time of archival. For photos jpeg, png or uncompressed tiff (you have to be careful with tiff because there are so many subformats with varying degrees of support) is probablly fine. For documents that probablly means keeping multiple copies, e.g. pdf to preserve exact layout and odf to preserve structure but possiblly at the cost of layout changing layter. For tabular data you want to get it into something like comma separated or tab separated. For video things are still rather unstable unfortunately but mpeg standards are likely to remain readable for a long time.
which very few systems make a straightforward task - sure, disk is okay, but have you ever tried to migrate, for example, NetBackup or Networker backup data from tape to tape?
Why can't you just restore the data using the old system and then back it up again using the new one?
but eventually they will crash back down to reasonable levels when everyone realizes it is a sham. Take for example Cisco systems which made it up to a P/E of around 435 in 2000 but now sells for a P/E of 16.5.
IMO assets trading way above their real value on the basis that some sucker will pay even more for them later are little different to a pyramid scheme.
What I don't understand is why aren't all orders limit orders?!
Also, the apps never get "root-level access" unless you execute them with super user privileges.
Installing a deb runs a number of scripts as root that can do whatever the hell the packager likes (either directly or if the packager wants to obfuscate what is going on by running binaries from the package).
Don't install debs you don't trust!
Scaling down a large image in whatever format you get it in (which is usually JPEG at the moment since that is what most cameras output) and then compressing it for sending to a user seems like a pretty common usecase for an image compressor to me and a perfectly reasonable thing to compare them on.
It would be interesting to see them go head to head from a raw source.
A JPEG source should be fine as long as it is at a much higher resoloution than the tests are encoded at. JPEG mostly throws away high frequency information and you throw that away when downsampling anyway.
IPv6 is not in demand, and will not BE in demand until there are new sites out there that don't have an IPv4 address because they can't get one
I would expect it will be quite a long time after allocations run out at the RIRs (if ever) that buisness sites can't get IPV4 IPs. Prices will go up of course as people are competing over a limited pool of IPs but that doesn't mean they won't be able to get them.
Most IM file transfers have a fallback to server based transfer.
As for the other things many of them are things that ISPs would like to see the back of or at least charge you for a buisness account for.
As the GP says it's not a fun prospect but from the ISPs POV it will provide a way to keep providing the lusers with their facebook/im/email/youtube/etc while also providing another way to get more money out of the geeks. Win/win for the ISPs.