Your statement is not entirely true, it should be corrected to
In theory, any country with it's own fiat currency and debts largely denominated in it's own currency could erase it's debts overnight.
The euro is a fiat currency but it's at the fiat of the EU not the fiat of the individual countries so individual countries can't print their way out of debt.
Iceland had it's own country but it's failing banks owed huge amounts of foreign currency to investors. IIRC in the end Iceland decided that refusing to honour it's banking gaurantees was better than a full scale default but it still did huge damage to the country economically.
Still afaict the US has so far been smart enough to retain the ability to print itself out of debt. IF the US starts to take out loans denominated in other currencies that is when you should REALLY worry.
for one, the implementation would have to diverge to take advantage of the features of each language
One of the things I find really noticeable about Java is it pushes you heavily towards certain types of structure. Want a simple array of identical records? sorry you can't have it! you either have to run multiple parallel arrays (which is bad for locality of reference and also bad for code readability) or have an array of objects (which means every array element has all the overhead of an object). Want to pass parameters by reference? sorry the language simply won't let you so you have to work-around it (which is likely to mean creating yet more objects).
The pieces of your program which really need that speed should be in C or asm
C++ is pretty much (excepting a few corner cases) a superset of C and like C compilers many C++ compailer allow inline assembler. Pretty much everything you can do in C you can do in C++ and there is no reason it shouldn't run just as fast yet you can also use higher level constructs where appropriate.
Mixing languages adds complexity to the code, the build process and the debugging process and this needs to be balanced against the benefits of doing it. Java seems a particularly painful language to mix with others and this makes it a bad option for many apps.
1: C++ makes it easy to mix different levels of code, you can write your app mostly in OOP using the STL (or even your own templates if you feel really adventurous) but you can also do pointer arithmetic and other low level stuff when it's the best fit for your problem. 2: C++ is probablly second only to C in platform penetration, while your UI may need to be rewritten your core logic can be the same across a huge number of platforms. 3: C++ lets you (or a library author) create your own types that are efficient and pleasant to work with (e.g. for complex numbers, vectors etc). for any mathematical code this is a huge advantage. 4: C++ performs well (java can be made to perform well but afaict doing so often requires fighting the language due to lack of simple things like arrays of structs) 5: C++ makes it really easy to access the platform's standard libraries (compared to a language like Java that lives in it's own world and makes it very painful to leave that world)
IIRC the military still insist on physical destruction (IIRC something like grinding the magnetic material off the platters and disolving it in acid) for the important stuff. The secure wipes are only for the low level stuff.
The problem with wiping drives is the risk that something (e.g. bad sector remapping or a drive misalignment) will mean you don't get to all the data. IIRC there are some extended commands to allow lower level access but can you garantee that your secure wiper will use them and that they will do what they are supposed to?
IIRC even if the US does invade canda and the south amercan oil produces or otherwise forces them to sell all their oil at below market prices they would still have to either import oil from the world market or dramatically reduce consumption.
It sounds like you are relying on accepting incoming connections to a ssh (or any other) server on a home connection. Initially your ISP will probably let you keep a public v4 IP for some token extra cost (or even free on request) but over time expect that cost to gradually ratchet up as the market value of v4 IPs increases. Or your ISP may decide to be nasty and say that to get a public v4 IP you have to upgrade to a significantly more expensive "buisness" connection.
If this service is important to you then you should be making enquiries with your ISP and/or making contingency plans sooner rather than later. It's always better to have plans for dealing with a problem than to have it thrust on you with no warning.
It won't use existing tracks, as high speed rail requires specialized tracks.
Obviously the actual track will need to be new and laid to a higher standard to support the high speed trains. I suspect like western europe* it would be standard gauge and the trains would have the ability to transfer to/from slower lines.
The question is will it be a case of replacing existing track with track that supports higher speeds but keeping the current ownership and priorities or will it be a case of completely new track where there was none before?
Perhaps the only exception is France's system which can travel on conventional rail at several transfer points, but only at conventional speeds
While you talked about france it seems all of western europe went for the system of standard gauge with trains available to move between normal and high speed lines and the eurocrats are busy trying to remove the gaps in the high speed network and expand it outwards (currently there seem to be two main clusters of really high speed rail in europe, one in spain and one centered in france and expanding out to belgium, the netherlands and to a lesser extent western germany).
Japan uses standard gauge for their high speed rail and narrow gauge for their other lines but afaict that is mainly because Japan's old network was narrow gauge and high speed rail isn't practical on narrow gauge. Taiwan seems to be a similar case to japan.
Afaict china and korea both use standard guage for both normal and high speed lines but I don't know if they move trains between them.
I think that pretty much covers all the high speed rail in the world (depeding a bit on your definition of high speed).
What is likely to happen is that unless you pay extra that one public IP is likely to be replaced by a private IP behind an ISP level nat. IF the ISP has IPs to spare they may run a NAT that is friendly to traversal techniques but as the IP crunch really bites they may choose to run a NAT that is unfriendly to traversal techniques to get a larger number of customers behind one NAT (or they may run a NAT like that simply because it is what they happen to have).
If you only use traditional client server protocols then don't worry about it. If you use anything that requires nat traversal techniques and/or requires incoming connections you should be trying to determine your ISPs plans and/or making contingency plans ASAP.
The impression I got is the ISPs supply the routers and preconfigure them with the users details but beyond they they just ignore them until/unless the user calls up for tech support. Some of the big ISPS may have a way to push out updates remotely but I bet many don't.
Afiact the real issue is that the freight companies own the lines and consider amtrak low priority. There are two ways to fix this, either move passenger traffic to it's own high speed lines or force a radical shakeup of the frieght companies operating priorities (I very much doubt they would do it voluntarily)
So it depends, will these be new lines (possibly parallel to existing lines) or will they be speed limit increases on existing lines?
Traditional landline phones require a LOT more infrastructure than cell towers. Yeah the towers need to be connected up somehow (which is usually a land based link but IIRC in some areas that is done with point to point microwave links using high gain antennas) but if call density is low one tower can serve a pretty large area (a quick google search says 35km radius is the limit). Covering an area with traditional landlines means running cable down virtually every road.
Mass of the object does not determine terminal velocity Mass of the object is a key factor in terminal velocity
Terminal velocity is the velocity at which the air resistance and the force due to gravity balance. If two objects are the same size and shape but the mass is different then the heavier object will have a higher force on it due to gravity and therefore a higher terminal velocity.
a = (mg-D)/g
m is the objects mass D is the drag (air resistance) g is the gravity
Terminal velocity is the velocity at which mg = D and therefore a=0.
D is primeraly dependent on area perpendicular to the direction of fall. and speed. It increases in a nonlinear manner with velocity.
Terminal velocity is when mg=D and therefore a=0. Increasing mass increases the ammount of drag needed to achive this balance and hence increases the terminal velocity.
Ever dropped a bowling ball and tennis ball from the same height at the same time?
If D is small compared to mg then a ~= g . That is why many pairs of objects appear to fall at the same speed when dropped over fairly short distances.
Most people have insurance against that. Does anyone even offer insurance against your DRM scheme going belly up? (I can't really see how they could given the massive systemic risk)
they can grow fungus, get scratched.
Some of us take care of our possesions. Ok scratches may be an issue for a few of the most frequently used discs but they shouldn't be a threat to your entire collection in the way a DRM scheme going belly up is.
But in the long run, it just takes looking at the digital music market to predict what will happen in the long term. These DRMs will eventually be depreciated, stores like iTunes will continue to support old DRMs but only sell DRM free content. It will take a few years, though, because it wont happen until movie digital sales are as commonplace as digital music sales were a couple years ago.
I hope you are right but fear you are wrong. Afaict the music industry only relented on DRM because they were fed up with apple having a two product lockin (you couldn't use your ipod with DRM music purchased from anywhere other than itunes and you couldn't easilly use your itunes music on a non-apple portable player).
The movie industry OTOH seems to be all for tightening up on protection. Afaict movies have never been sold in the west in any significant numbers (there was videocd but I have never seen a legit videocd for sale) in an unprotected digital format. Yes the DVD protection is thoughrougly cracked but they are still using it to bring the legal hammer on anyone who sells DVD copying software commercially and they really stepped up the protection for blu-ray.
no way in hell am I going to spend hours playing an RPG hunched over mobile, dependent on batteries or a clumsy charging cable, when I can sit comfortably on the couch mmm, nintendo sold a device that could be used to play your GB, GBC and GBA games on your gamecube (and before that they sold one that let you play your original gameboy games on your SNES) but they haven't made anything similar for DS games (and the touchscreen would make it rather difficult for them to do so).
Indeed, the big question that should be scaring all traditional game dev houses and publishers will people continue to be prepared to pay for "big budget" games or will they preffer to spend their money on a greater number of lower budget games and/or old games.
Bargin bins, shovelware publishers and independent developers have always existed but the rise of the internet, particually direct download services like steam, D2D and GOG and direct person to person trading like ebay and amazon marketplaces has made it far easier to buy the old and indie games you want (as opposed to whatever happens to be in the bargin bin that day).
Yeah bugs that pop up every so often to end users (and are common enough or reported by trusted enough users that they can't just by dismissed as coming from liers/trolls) but only pop up sporadically and/or only pop up on certain systems are a big problem for developers. With no reliable way to reproduce a bug it is almost impossible to fix it.
Even more irritating are the bugs that dissapear as soon as you try to use a debugger.
The firefox memory and CPU usage issues are good examples of this. Way too many users reported them to dismiss them as a lie or fluke but there was no set of steps to reproduce. Every so often one cause was found and squashed but they kept coming up for years and may still be doing so (I still see firefox crash for no apparent reason and it wouldn't surprise me if the cause is running out of address space).
Which is what Intel is requiring them to do. On what do you base this statement?
According to TFA (unfortunately the intel site linked from TFA seems to be down at the moment so I can't follow things back to the source) intel said "PC system configurations that are not impacted by the design issue". That is a bit of a vauge statement, does it mean systems that aren't impacted by the issue if kept as sold? or does it mean systems that can't become impacted by the issue through user upgrades?
I suspect and hope it means the latter but I can't seem to find any confirmation either way
One question is how will they define "broadband". ADSL is a marvel of modern engineering but high speeds only work over relatively short lines. Cable only tends to be available in urban areas. Afaict there are only three ways to get higher speeds to everyone, none of them cheap.
1: shorten the phone lines/reduce the number of users on one cable segment (most likely through some sort of FTTC/FTTP setup). 2: move to a totally different technology (e.g. FTTH) 3: bond multiple lines (this isn't a bad idea if you want to give one customer faster service but afaict in most areas there are simply not enough lines for it to be practical on a large scale.
The ipad and similar tablets are big enough to comfortably read web pages, watch video, read ebooks etc on while being small light and robust and of a suitable form factor to hold in one hand and operate in the other. Laptops are fine if you can sit down at a table to use them but that isn't always practical.
If you're going to drop Alpha, why not drop m68k? They already did.
There comes a point where the slow march of software "bloat" gets too much for older hardware and/or there is no longer sufficiant porters to keep the port in what debian considers a releasable state. It's sad but that is the way things go in a project like debian.
Arm was a special case because they kept support for the majority of arm devices but did so through a new port due to some serious deficiancies in the old arm linux port. It was always planned that offering two different arm ports in the same release was a transitional state that would only last one release.
Slashdot Mirror
Your statement is not entirely true, it should be corrected to
In theory, any country with it's own fiat currency and debts largely denominated in it's own currency could erase it's debts overnight.
The euro is a fiat currency but it's at the fiat of the EU not the fiat of the individual countries so individual countries can't print their way out of debt.
Iceland had it's own country but it's failing banks owed huge amounts of foreign currency to investors. IIRC in the end Iceland decided that refusing to honour it's banking gaurantees was better than a full scale default but it still did huge damage to the country economically.
Still afaict the US has so far been smart enough to retain the ability to print itself out of debt. IF the US starts to take out loans denominated in other currencies that is when you should REALLY worry.
I suspect that the most likely explanation is that those machines have suffered from dpkg database corruption.
for one, the implementation would have to diverge to take advantage of the features of each language
One of the things I find really noticeable about Java is it pushes you heavily towards certain types of structure. Want a simple array of identical records? sorry you can't have it! you either have to run multiple parallel arrays (which is bad for locality of reference and also bad for code readability) or have an array of objects (which means every array element has all the overhead of an object). Want to pass parameters by reference? sorry the language simply won't let you so you have to work-around it (which is likely to mean creating yet more objects).
The pieces of your program which really need that speed should be in C or asm
C++ is pretty much (excepting a few corner cases) a superset of C and like C compilers many C++ compailer allow inline assembler. Pretty much everything you can do in C you can do in C++ and there is no reason it shouldn't run just as fast yet you can also use higher level constructs where appropriate.
Mixing languages adds complexity to the code, the build process and the debugging process and this needs to be balanced against the benefits of doing it. Java seems a particularly painful language to mix with others and this makes it a bad option for many apps.
Why are so many programs still written in C++?
A few reasons I think
1: C++ makes it easy to mix different levels of code, you can write your app mostly in OOP using the STL (or even your own templates if you feel really adventurous) but you can also do pointer arithmetic and other low level stuff when it's the best fit for your problem.
2: C++ is probablly second only to C in platform penetration, while your UI may need to be rewritten your core logic can be the same across a huge number of platforms.
3: C++ lets you (or a library author) create your own types that are efficient and pleasant to work with (e.g. for complex numbers, vectors etc). for any mathematical code this is a huge advantage.
4: C++ performs well (java can be made to perform well but afaict doing so often requires fighting the language due to lack of simple things like arrays of structs)
5: C++ makes it really easy to access the platform's standard libraries (compared to a language like Java that lives in it's own world and makes it very painful to leave that world)
IIRC the military still insist on physical destruction (IIRC something like grinding the magnetic material off the platters and disolving it in acid) for the important stuff. The secure wipes are only for the low level stuff.
The problem with wiping drives is the risk that something (e.g. bad sector remapping or a drive misalignment) will mean you don't get to all the data. IIRC there are some extended commands to allow lower level access but can you garantee that your secure wiper will use them and that they will do what they are supposed to?
IIRC even if the US does invade canda and the south amercan oil produces or otherwise forces them to sell all their oil at below market prices they would still have to either import oil from the world market or dramatically reduce consumption.
It sounds like you are relying on accepting incoming connections to a ssh (or any other) server on a home connection. Initially your ISP will probably let you keep a public v4 IP for some token extra cost (or even free on request) but over time expect that cost to gradually ratchet up as the market value of v4 IPs increases. Or your ISP may decide to be nasty and say that to get a public v4 IP you have to upgrade to a significantly more expensive "buisness" connection.
If this service is important to you then you should be making enquiries with your ISP and/or making contingency plans sooner rather than later. It's always better to have plans for dealing with a problem than to have it thrust on you with no warning.
It won't use existing tracks, as high speed rail requires specialized tracks.
Obviously the actual track will need to be new and laid to a higher standard to support the high speed trains. I suspect like western europe* it would be standard gauge and the trains would have the ability to transfer to/from slower lines.
The question is will it be a case of replacing existing track with track that supports higher speeds but keeping the current ownership and priorities or will it be a case of completely new track where there was none before?
Perhaps the only exception is France's system which can travel on conventional rail at several transfer points, but only at conventional speeds
While you talked about france it seems all of western europe went for the system of standard gauge with trains available to move between normal and high speed lines and the eurocrats are busy trying to remove the gaps in the high speed network and expand it outwards (currently there seem to be two main clusters of really high speed rail in europe, one in spain and one centered in france and expanding out to belgium, the netherlands and to a lesser extent western germany).
Japan uses standard gauge for their high speed rail and narrow gauge for their other lines but afaict that is mainly because Japan's old network was narrow gauge and high speed rail isn't practical on narrow gauge. Taiwan seems to be a similar case to japan.
Afaict china and korea both use standard guage for both normal and high speed lines but I don't know if they move trains between them.
I think that pretty much covers all the high speed rail in the world (depeding a bit on your definition of high speed).
What is likely to happen is that unless you pay extra that one public IP is likely to be replaced by a private IP behind an ISP level nat. IF the ISP has IPs to spare they may run a NAT that is friendly to traversal techniques but as the IP crunch really bites they may choose to run a NAT that is unfriendly to traversal techniques to get a larger number of customers behind one NAT (or they may run a NAT like that simply because it is what they happen to have).
If you only use traditional client server protocols then don't worry about it. If you use anything that requires nat traversal techniques and/or requires incoming connections you should be trying to determine your ISPs plans and/or making contingency plans ASAP.
The impression I got is the ISPs supply the routers and preconfigure them with the users details but beyond they they just ignore them until/unless the user calls up for tech support. Some of the big ISPS may have a way to push out updates remotely but I bet many don't.
Afiact the real issue is that the freight companies own the lines and consider amtrak low priority. There are two ways to fix this, either move passenger traffic to it's own high speed lines or force a radical shakeup of the frieght companies operating priorities (I very much doubt they would do it voluntarily)
So it depends, will these be new lines (possibly parallel to existing lines) or will they be speed limit increases on existing lines?
Traditional landline phones require a LOT more infrastructure than cell towers. Yeah the towers need to be connected up somehow (which is usually a land based link but IIRC in some areas that is done with point to point microwave links using high gain antennas) but if call density is low one tower can serve a pretty large area (a quick google search says 35km radius is the limit). Covering an area with traditional landlines means running cable down virtually every road.
Mass of the object does not determine terminal velocity
Mass of the object is a key factor in terminal velocity
Terminal velocity is the velocity at which the air resistance and the force due to gravity balance. If two objects are the same size and shape but the mass is different then the heavier object will have a higher force on it due to gravity and therefore a higher terminal velocity.
a = (mg-D)/g
m is the objects mass
D is the drag (air resistance)
g is the gravity
Terminal velocity is the velocity at which mg = D and therefore a=0.
D is primeraly dependent on area perpendicular to the direction of fall. and speed. It increases in a nonlinear manner with velocity.
Terminal velocity is when mg=D and therefore a=0. Increasing mass increases the ammount of drag needed to achive this balance and hence increases the terminal velocity.
Ever dropped a bowling ball and tennis ball from the same height at the same time?
If D is small compared to mg then a ~= g . That is why many pairs of objects appear to fall at the same speed when dropped over fairly short distances.
My DVDs can burn in a fire
Most people have insurance against that. Does anyone even offer insurance against your DRM scheme going belly up? (I can't really see how they could given the massive systemic risk)
they can grow fungus, get scratched.
Some of us take care of our possesions. Ok scratches may be an issue for a few of the most frequently used discs but they shouldn't be a threat to your entire collection in the way a DRM scheme going belly up is.
But in the long run, it just takes looking at the digital music market to predict what will happen in the long term. These DRMs will eventually be depreciated, stores like iTunes will continue to support old DRMs but only sell DRM free content. It will take a few years, though, because it wont happen until movie digital sales are as commonplace as digital music sales were a couple years ago.
I hope you are right but fear you are wrong. Afaict the music industry only relented on DRM because they were fed up with apple having a two product lockin (you couldn't use your ipod with DRM music purchased from anywhere other than itunes and you couldn't easilly use your itunes music on a non-apple portable player).
The movie industry OTOH seems to be all for tightening up on protection. Afaict movies have never been sold in the west in any significant numbers (there was videocd but I have never seen a legit videocd for sale) in an unprotected digital format. Yes the DVD protection is thoughrougly cracked but they are still using it to bring the legal hammer on anyone who sells DVD copying software commercially and they really stepped up the protection for blu-ray.
no way in hell am I going to spend hours playing an RPG hunched over mobile, dependent on batteries or a clumsy charging cable, when I can sit comfortably on the couch
mmm, nintendo sold a device that could be used to play your GB, GBC and GBA games on your gamecube (and before that they sold one that let you play your original gameboy games on your SNES) but they haven't made anything similar for DS games (and the touchscreen would make it rather difficult for them to do so).
Indeed, the big question that should be scaring all traditional game dev houses and publishers will people continue to be prepared to pay for "big budget" games or will they preffer to spend their money on a greater number of lower budget games and/or old games.
Bargin bins, shovelware publishers and independent developers have always existed but the rise of the internet, particually direct download services like steam, D2D and GOG and direct person to person trading like ebay and amazon marketplaces has made it far easier to buy the old and indie games you want (as opposed to whatever happens to be in the bargin bin that day).
That bug from 2000 reports an issue in the parsing code but doesn't appear to be a DOS like the one under discussion here.
Yeah bugs that pop up every so often to end users (and are common enough or reported by trusted enough users that they can't just by dismissed as coming from liers/trolls) but only pop up sporadically and/or only pop up on certain systems are a big problem for developers. With no reliable way to reproduce a bug it is almost impossible to fix it.
Even more irritating are the bugs that dissapear as soon as you try to use a debugger.
The firefox memory and CPU usage issues are good examples of this. Way too many users reported them to dismiss them as a lie or fluke but there was no set of steps to reproduce. Every so often one cause was found and squashed but they kept coming up for years and may still be doing so (I still see firefox crash for no apparent reason and it wouldn't surprise me if the cause is running out of address space).
Which is what Intel is requiring them to do.
On what do you base this statement?
According to TFA (unfortunately the intel site linked from TFA seems to be down at the moment so I can't follow things back to the source) intel said "PC system configurations that are not impacted by the design issue". That is a bit of a vauge statement, does it mean systems that aren't impacted by the issue if kept as sold? or does it mean systems that can't become impacted by the issue through user upgrades?
I suspect and hope it means the latter but I can't seem to find any confirmation either way
Virtually all laptops, excluding on a few high end workstation/gamer beasts, are 1HDD and (still common; but getting rarer) 1 optical drive.
A lot of current laptops have a hard drive, an optical drive and an eSATA port which takes things up to 3.
My guess would be that what they really mean is they will insist that motherboard vendors don't connect any ports to the bad controller.
If the ports don't exist you can't use them.
One question is how will they define "broadband". ADSL is a marvel of modern engineering but high speeds only work over relatively short lines. Cable only tends to be available in urban areas. Afaict there are only three ways to get higher speeds to everyone, none of them cheap.
1: shorten the phone lines/reduce the number of users on one cable segment (most likely through some sort of FTTC/FTTP setup).
2: move to a totally different technology (e.g. FTTH)
3: bond multiple lines (this isn't a bad idea if you want to give one customer faster service but afaict in most areas there are simply not enough lines for it to be practical on a large scale.
The ipad and similar tablets are big enough to comfortably read web pages, watch video, read ebooks etc on while being small light and robust and of a suitable form factor to hold in one hand and operate in the other. Laptops are fine if you can sit down at a table to use them but that isn't always practical.
Is this not one of the fastest Debian release cycles?
Looking at the list of debian releases this cycle was actually the second-longest.
If you're going to drop Alpha, why not drop m68k?
They already did.
There comes a point where the slow march of software "bloat" gets too much for older hardware and/or there is no longer sufficiant porters to keep the port in what debian considers a releasable state. It's sad but that is the way things go in a project like debian.
Arm was a special case because they kept support for the majority of arm devices but did so through a new port due to some serious deficiancies in the old arm linux port. It was always planned that offering two different arm ports in the same release was a transitional state that would only last one release.