Even odder? I don't have enough IDE channels for 7 HDDs and 1 DVD multidrive You do know you can get controllers for pretty much every type of drive interface you could want on a PCI or PCIe card right?
At a time when cutting-edge distros were all moving to Linux 2.6 and conservative distributions and ones that hadn't been updated lately were still using 2.4.x, the Debian installer was asking users if they wanted to try the "new" 2.2 kernel, which might not be totally ready for prime time yet, or stick with the tried and true 2.0 kernel. You exagerate. When 2.6 first came out the current version of debian stable was woody which offered either 2.2 or 2.4.
Still I agree that debians longest release cycle ever came at about the worst possible time.
Some stuff does get testsuited at build time and rebuild tests are done at least once per release but desktop applications are difficult to testsuite unless they were designed for it from the start and hardware dependent stuff is also difficult to deal with in a test environment because you would need so damn much test hardware.
Also even when testsuites do reveal problems there is the question of what to do about them. Fixing the underlying problems often isn't easy, especially if upstream is uncooperative. Again this is an area where debians long freezes help, it gives time for bugs to be investigated and upstream to be liased with. Sometimes (especialy in ubuntu but sometimes in debian too) build time test suites get either disabled or get thier "expected failures" list changed because they consider a test failre with no known real world impact (or where the known real world impacts are considered minor) a lesser evil than a package stuck in an unbuildable state.
Not really, the trouble with internal combustion engines is they are inefficiant (about 30% iirc). Add that to the ineficiancies of generating and the inefficiancies (you'll never eliminate them all) in your electricty to hydrocarbons process and you'll get a REALLY lousy system efficiancy.
It may be feasible if we can get over our fear of reprocessing and build some really big nuke plants such that the majority of electricity comes at a very low carbon footprint but unless that happens. I'd think your process would have to be very efficiant for "coal power plant"+"your process" to work out better than fischer troph.
I fear a big increase in CO2 emisions over the next few decades as the easy oil gets ever scarcer and we turn more and more to tar sands, fischer troph, oil with a high energy cost to extract and so on to keep the petrol/diesel/kerosene that our transportation infrastructure relies on flowing. Oil releases from underwater gushers and similar will probablly increase too as ever more inaccessible oil is produced.
Debian code names don't really have much structure to them other than all being toy story characters and it seems recently getting into the more obscure ones.
With the exception of some very early releases (horay and warty) ubuntu codenames have going in alphabetical order breezy->dapper->edgy->feisty->gutsy->hardy->intrepid->jaunty->karmic->lucid->maverick
With windows apps are still supporting XP and often even 2K and 9x. Hardware vendors are also still providing drivers for XP as long as you buy machines from thier buisness ranges. This along with microsoft's security update policies means that you can run the same version of windows for a long time (several PCs worth of time) while updating application software as desired.
With linux on the other hand if you want to upgrade your application software you pretty much have to either.
1: upgrade to the latest stable release (which may well not get on with your hardware in which case you are SOL) and hope someone has made a baackport (sometimes they will more often they won't). Even if you don't want new software you have to upgrade every couple of years (at least on the non-enterprise distros) to keep getting security updates. 2: run a testing release (what most debian desktop users resort to doing), more chance of breakage but also more chance of getting it fixed before it gets frozen in stable for the next couple of years. 3: try and build the software from source which is sometimes easy but frequently frought with problems.
actually, it's three way, Intel, AMD and Via. IIRC there are a few manufacturers making 486 clones (there can't be many patents left on stuff that old can there?) for the embedded market as well.
Still it remains that for high end desktop PCs there is only one choice and for ordinary desktops/laptops there are only two reasonable choices. Via only really have chips in the netbook/nettop range afaict. I do wonder how long AMD will be able to hang on now intel have got their act together, being forced to sell your top end chip at the same price as your competitors upper-midrange stuff must really hurt those margins, especially when you get to spread your fixed costs over fewer units.
Most of the time when ubuntu needs to update a package they first check if debian has an updated version, and most of the time it has. That's probablly true for the more minor stuff but the big name stuff like glibc, gnome, kde etc is often newer in ubuntu's development version than in debian unstable and sometimes newer than even experimental.
as you have to specifically specify that you want stuff from experimental when you install or update a package You can pin the whole of experimental at the same level as unstable and therefore cause apt to install stuff from it automatically (you can even pin it higher but thats a bad idea because often older versions get left in experimental after unstable is updated). I've done it in a chroot but never tried it on an independent system.
Well the first announced freeze date for squeeze was part of an unpopular plan to sync up with ubuntu by having a very short release cycle. That was abandoned pretty quickly (unfortunately after that)
Asside from that there afaict are a couple of reasons to delay the freeze.
A big reason is what are referred to as transitions. A transition is a group of package updates (usually a new major version of a library and the various updates and rebuilds associated with it) that need to move from unstable to testing at the same time to leave testing in a consistent state (unstable is allowed to be in an inconsistant state, testing isn't). The release planners will have a set of transitions that they really want to get in for a given release, transitions can easilly get held up by build failures and other rc bugs and they don't want to do too many at the same time because then they become intertangled leaving the release team with one big transition which is even harder to make migrate.
Also they want to pick a good time to freeze. Freezing the application level stuff while there are still big issues to fix in core package won't affect the release date much while it will mean releasing with older versions of the application level stuff (which is the stuff that is most visible to users and often the stuff that needs the most security updates).
While ubuntu is derived from debian that doesn't stop them from packaging newer stuff than in debian. The big name stuff is often newer in ubuntu's development versions than in sid. More obscure stuff will generally be either at the same versions or newer in sid than in ubuntus development version.
Debian and ubuntu have very different release cycles. Ubuntu makes a release every 6 months and releases are prepared one at a time. This fast turnaround means more up to date software at relase time but also means little time for things to settle and bugs to get rooted out. Ubuntu won't delay a release unless there is a cripping issue with a package they consider particulally important.
Debian's release cycles on the other hand are generally on the order of two years these days and they tend to spend a large amount of time at the end of that release letting things stabilise and working on the bug count.
Things got particularlly bad a few years back. The sarge development cycle was debians longest ever and it came at a time when linux in general was improving a lot for the desktop but it still gets annoying near the end of a cycle.
The driver is a challange but I don't think it's the most important one. IMO for a really practical flying car you really need the following.
1: able to drive along the roads (nessacery because there will be some places you can't really fly) and fit into normal car sized spaces. 2: able to take off and land in a small space (if you have to drive to a runway to take off you are going to lose a lot of the benifit) with minimal infrastructure. 3: able to fly safely and at tolerable fuel economy 4: able to carry a decent number of passengers in comfort
The trouble is while there are plenty of craft that can satisfy these individually all the craft i'm aware of fall down on at least one of them.
Winged craft need a lot of space to take off and the wing doesn't tend to fit fit in a car sized footprint. The footprint problem can be got arround to some extent by using a folding wing or a fabric wing but they still tend to end up making the passenger part very small to make the sums work out.
Helicopters can take off and land in a small space but they are already very expensive even before you start trying to figure out how to make them run on the road as well. Plus you would probablly be limited to a two-blade rotor so you could align it front to back while on the road.
Jet lifted cars drink huge ammounts of fuel and are intrinsically unsafe (lose your lift and drop like a rock).
mmm though i've noticed that on some optiplexes now they use a micro-fit rather than a mini fit JR for the main connector. I think the pinout is the same but i'm not sure.
I seem to remember recapatcha claiming that if they think they are being screwed with they switch to sending two known words rather than one known and one unknown
It makes no sense for an ISP to actively worsen the service it provides it's customers Consider the case of a "triple play" provider. They sell you a bundle that includes basic phone service, basic TV service and internet service.
Now suppose you want a premium TV channel, or some ondemand movies or an international phone service. If you have a good internet connection you can either buy them from your "triple play" provider or you can buy them from an internet based provider.
If you buy it from your triple play provider they most likely get a cut of the revenue. If you buy it from an internet based provider your "triple play" provider doesn't get a cut and may even have to pay to get the data to/from the internet based provider.
OTOH if your internet connection is relatively poor your options are to either buy the extras from your "triple play" provider or switch everything (which is a massive PITA even where it is possible).
Sometimes people suggest stuff like extending an auction by 5 minutes if someone bids in the last 5 mins, but I fail to see what this would achieve On a site like ebay where the site automatically increases the price up to a bidders entered maximum it is very easy to a competing bidder to get drawn into an emotional battle where they keep thinking "just a little more" until they end up paying significantly more than they originally intended.
It's in the sellers interest to encourage such emotional battles and it's in a rational bidders interest to discourage them. The current ebay setup allows rational bidders to discourage such behaviour by not bidding until the last minuite. An auto extending format would not allow this.
Not at all. You bid what you're willing to pay. If somebody else wins the bid for one cent more, you're happy that they overpaid for it. Why would I be happy about that?
However, sniping is clearly a more effective strategy to get items for good prices. Agreed which is why I do it (I don't bother with sniping tools though, I just snipe manually)
Plus, most people don't actually bid their max, so by sniping you end up with less competition Also other bidders aren't always rational. Ebays method of handling bidding seems designed to encourage people to think "just a little more" until they are spending way more than they originally planned to. When that happens the only real winner is the seller.
The problem with trying to catch anything in space is that it is likely to be moving in a different direction to you and since its in orbit it will be going very fast. So the combined speed in any collision between your object and a peice of space junk is likely to be extremely high (afaict orbital velocities make bullets look slow). The space junk would most likely just punch a hole straight through your net.
That is why space debris is such a hazard in the first place.
Unfortunately there seems to be a massive loophole in the requirement. Other than a requirement that they mustn't break the spec deliberately to cripple performance there are no restrictions on the performance of the interface. So by my reading of the requirements they could supply a single x1 channel and be within the rules.
really? whats competative at the $300 point with AMD Phenom II X6 1090T from Intel? No really, http://www.newegg.com/Product/Product.aspx?Item=N82E16819115225 [newegg.com] is probably the best at stock speeds and it's only a 2.8ghz quad core And yet the i7-920 (which is only a 2.66GHz quad-core) seems to hold it's own quite well against the Phenom II X6. http://www.anandtech.com/bench/Product/146?vs=47 . It seems the amd is generally winning in video encoding while the intel is winning in most other stuff (unfortunately anandtechs charts are hard to read because some tests are lower is better and others are higher is better:( )
and uses more expensive motherboards than the AMD. If you are trying to build a cheap system the i7-8xx series is probablly a better bet than the i7-9xx series It tends to give more performance per dollar and runs on cheaper motherboards. The downside is you get less PCIe and less memory slots.
Other than, of course, the fact that an intel GPU comes on the die of every intel CPU sold, atoms excepted(for now). BULLSHIT. Intel do seem to be planning to go down that road but right now the only intel chips with a GPU on the cpu are the dual core i series chips and the pine trail atoms.
The quad-core and 6-core nahelm chips don't have any support for shared memory graphics at all afaict so you have to combine them with a graphics card/chip that has it's own memory (which most likely for a desktop means a nvidia or ATI card).
The older core 2 stuff uses a conventional FSB setup with any shared memory graphics being up to the chipset.
Sandy bridge will apparently be brining in on-die graphics to all intels mainstream chips.
It depends on what values you consider constant. If you consider mass as a constant then moment of inertia is proportional to the square of the radius but if you consider density and thickness to be constants then moment of inertia is proportional to the fourth power of the radius.
IMO when talking about platters considering thickness and density as constants is more sensible than considering mass as a constant.
Slashdot Mirror
Even odder? I don't have enough IDE channels for 7 HDDs and 1 DVD multidrive
You do know you can get controllers for pretty much every type of drive interface you could want on a PCI or PCIe card right?
At a time when cutting-edge distros were all moving to Linux 2.6 and conservative distributions and ones that hadn't been updated lately were still using 2.4.x, the Debian installer was asking users if they wanted to try the "new" 2.2 kernel, which might not be totally ready for prime time yet, or stick with the tried and true 2.0 kernel.
You exagerate. When 2.6 first came out the current version of debian stable was woody which offered either 2.2 or 2.4.
Still I agree that debians longest release cycle ever came at about the worst possible time.
Some stuff does get testsuited at build time and rebuild tests are done at least once per release but desktop applications are difficult to testsuite unless they were designed for it from the start and hardware dependent stuff is also difficult to deal with in a test environment because you would need so damn much test hardware.
Also even when testsuites do reveal problems there is the question of what to do about them. Fixing the underlying problems often isn't easy, especially if upstream is uncooperative. Again this is an area where debians long freezes help, it gives time for bugs to be investigated and upstream to be liased with. Sometimes (especialy in ubuntu but sometimes in debian too) build time test suites get either disabled or get thier "expected failures" list changed because they consider a test failre with no known real world impact (or where the known real world impacts are considered minor) a lesser evil than a package stuck in an unbuildable state.
Not really, the trouble with internal combustion engines is they are inefficiant (about 30% iirc). Add that to the ineficiancies of generating and the inefficiancies (you'll never eliminate them all) in your electricty to hydrocarbons process and you'll get a REALLY lousy system efficiancy.
It may be feasible if we can get over our fear of reprocessing and build some really big nuke plants such that the majority of electricity comes at a very low carbon footprint but unless that happens. I'd think your process would have to be very efficiant for "coal power plant"+"your process" to work out better than fischer troph.
I fear a big increase in CO2 emisions over the next few decades as the easy oil gets ever scarcer and we turn more and more to tar sands, fischer troph, oil with a high energy cost to extract and so on to keep the petrol/diesel/kerosene that our transportation infrastructure relies on flowing. Oil releases from underwater gushers and similar will probablly increase too as ever more inaccessible oil is produced.
Debian code names don't really have much structure to them other than all being toy story characters and it seems recently getting into the more obscure ones.
With the exception of some very early releases (horay and warty) ubuntu codenames have going in alphabetical order breezy->dapper->edgy->feisty->gutsy->hardy->intrepid->jaunty->karmic->lucid->maverick
With windows apps are still supporting XP and often even 2K and 9x. Hardware vendors are also still providing drivers for XP as long as you buy machines from thier buisness ranges. This along with microsoft's security update policies means that you can run the same version of windows for a long time (several PCs worth of time) while updating application software as desired.
With linux on the other hand if you want to upgrade your application software you pretty much have to either.
1: upgrade to the latest stable release (which may well not get on with your hardware in which case you are SOL) and hope someone has made a baackport (sometimes they will more often they won't). Even if you don't want new software you have to upgrade every couple of years (at least on the non-enterprise distros) to keep getting security updates.
2: run a testing release (what most debian desktop users resort to doing), more chance of breakage but also more chance of getting it fixed before it gets frozen in stable for the next couple of years.
3: try and build the software from source which is sometimes easy but frequently frought with problems.
actually, it's three way, Intel, AMD and Via.
IIRC there are a few manufacturers making 486 clones (there can't be many patents left on stuff that old can there?) for the embedded market as well.
Still it remains that for high end desktop PCs there is only one choice and for ordinary desktops/laptops there are only two reasonable choices. Via only really have chips in the netbook/nettop range afaict. I do wonder how long AMD will be able to hang on now intel have got their act together, being forced to sell your top end chip at the same price as your competitors upper-midrange stuff must really hurt those margins, especially when you get to spread your fixed costs over fewer units.
How cool can it get the CPU though? Afaict the CPU usually runs quite a bit hotter than the surrounding air.
Also I wonder how the rest of the PC would survive those temperatures.
(unfortunately after that)
That should have said unfortunately after it had been announced publically.
Most of the time when ubuntu needs to update a package they first check if debian has an updated version, and most of the time it has.
That's probablly true for the more minor stuff but the big name stuff like glibc, gnome, kde etc is often newer in ubuntu's development version than in debian unstable and sometimes newer than even experimental.
as you have to specifically specify that you want stuff from experimental when you install or update a package
You can pin the whole of experimental at the same level as unstable and therefore cause apt to install stuff from it automatically (you can even pin it higher but thats a bad idea because often older versions get left in experimental after unstable is updated). I've done it in a chroot but never tried it on an independent system.
Well the first announced freeze date for squeeze was part of an unpopular plan to sync up with ubuntu by having a very short release cycle. That was abandoned pretty quickly (unfortunately after that)
Asside from that there afaict are a couple of reasons to delay the freeze.
A big reason is what are referred to as transitions. A transition is a group of package updates (usually a new major version of a library and the various updates and rebuilds associated with it) that need to move from unstable to testing at the same time to leave testing in a consistent state (unstable is allowed to be in an inconsistant state, testing isn't). The release planners will have a set of transitions that they really want to get in for a given release, transitions can easilly get held up by build failures and other rc bugs and they don't want to do too many at the same time because then they become intertangled leaving the release team with one big transition which is even harder to make migrate.
Also they want to pick a good time to freeze. Freezing the application level stuff while there are still big issues to fix in core package won't affect the release date much while it will mean releasing with older versions of the application level stuff (which is the stuff that is most visible to users and often the stuff that needs the most security updates).
While ubuntu is derived from debian that doesn't stop them from packaging newer stuff than in debian. The big name stuff is often newer in ubuntu's development versions than in sid. More obscure stuff will generally be either at the same versions or newer in sid than in ubuntus development version.
Debian and ubuntu have very different release cycles. Ubuntu makes a release every 6 months and releases are prepared one at a time. This fast turnaround means more up to date software at relase time but also means little time for things to settle and bugs to get rooted out. Ubuntu won't delay a release unless there is a cripping issue with a package they consider particulally important.
Debian's release cycles on the other hand are generally on the order of two years these days and they tend to spend a large amount of time at the end of that release letting things stabilise and working on the bug count.
Things got particularlly bad a few years back. The sarge development cycle was debians longest ever and it came at a time when linux in general was improving a lot for the desktop but it still gets annoying near the end of a cycle.
The risk for the governemnt is that wikileaks will decide that releasing the documents unredacted is better than not releasing them at all.
The driver is a challange but I don't think it's the most important one. IMO for a really practical flying car you really need the following.
1: able to drive along the roads (nessacery because there will be some places you can't really fly) and fit into normal car sized spaces.
2: able to take off and land in a small space (if you have to drive to a runway to take off you are going to lose a lot of the benifit) with minimal infrastructure.
3: able to fly safely and at tolerable fuel economy
4: able to carry a decent number of passengers in comfort
The trouble is while there are plenty of craft that can satisfy these individually all the craft i'm aware of fall down on at least one of them.
Winged craft need a lot of space to take off and the wing doesn't tend to fit fit in a car sized footprint. The footprint problem can be got arround to some extent by using a folding wing or a fabric wing but they still tend to end up making the passenger part very small to make the sums work out.
Helicopters can take off and land in a small space but they are already very expensive even before you start trying to figure out how to make them run on the road as well. Plus you would probablly be limited to a two-blade rotor so you could align it front to back while on the road.
Jet lifted cars drink huge ammounts of fuel and are intrinsically unsafe (lose your lift and drop like a rock).
mmm though i've noticed that on some optiplexes now they use a micro-fit rather than a mini fit JR for the main connector. I think the pinout is the same but i'm not sure.
I seem to remember recapatcha claiming that if they think they are being screwed with they switch to sending two known words rather than one known and one unknown
It makes no sense for an ISP to actively worsen the service it provides it's customers
Consider the case of a "triple play" provider. They sell you a bundle that includes basic phone service, basic TV service and internet service.
Now suppose you want a premium TV channel, or some ondemand movies or an international phone service. If you have a good internet connection you can either buy them from your "triple play" provider or you can buy them from an internet based provider.
If you buy it from your triple play provider they most likely get a cut of the revenue. If you buy it from an internet based provider your "triple play" provider doesn't get a cut and may even have to pay to get the data to/from the internet based provider.
OTOH if your internet connection is relatively poor your options are to either buy the extras from your "triple play" provider or switch everything (which is a massive PITA even where it is possible).
Surely it's possible to write helper programs that print out the steps as well as the answer.
Sometimes people suggest stuff like extending an auction by 5 minutes if someone bids in the last 5 mins, but I fail to see what this would achieve
On a site like ebay where the site automatically increases the price up to a bidders entered maximum it is very easy to a competing bidder to get drawn into an emotional battle where they keep thinking "just a little more" until they end up paying significantly more than they originally intended.
It's in the sellers interest to encourage such emotional battles and it's in a rational bidders interest to discourage them. The current ebay setup allows rational bidders to discourage such behaviour by not bidding until the last minuite. An auto extending format would not allow this.
Not at all. You bid what you're willing to pay. If somebody else wins the bid for one cent more, you're happy that they overpaid for it.
Why would I be happy about that?
However, sniping is clearly a more effective strategy to get items for good prices.
Agreed which is why I do it (I don't bother with sniping tools though, I just snipe manually)
Plus, most people don't actually bid their max, so by sniping you end up with less competition
Also other bidders aren't always rational. Ebays method of handling bidding seems designed to encourage people to think "just a little more" until they are spending way more than they originally planned to. When that happens the only real winner is the seller.
The problem with trying to catch anything in space is that it is likely to be moving in a different direction to you and since its in orbit it will be going very fast. So the combined speed in any collision between your object and a peice of space junk is likely to be extremely high (afaict orbital velocities make bullets look slow). The space junk would most likely just punch a hole straight through your net.
That is why space debris is such a hazard in the first place.
Unfortunately there seems to be a massive loophole in the requirement. Other than a requirement that they mustn't break the spec deliberately to cripple performance there are no restrictions on the performance of the interface. So by my reading of the requirements they could supply a single x1 channel and be within the rules.
really? whats competative at the $300 point with AMD Phenom II X6 1090T from Intel? No really, http://www.newegg.com/Product/Product.aspx?Item=N82E16819115225 [newegg.com] is probably the best at stock speeds and it's only a 2.8ghz quad core :( )
And yet the i7-920 (which is only a 2.66GHz quad-core) seems to hold it's own quite well against the Phenom II X6. http://www.anandtech.com/bench/Product/146?vs=47 . It seems the amd is generally winning in video encoding while the intel is winning in most other stuff (unfortunately anandtechs charts are hard to read because some tests are lower is better and others are higher is better
and uses more expensive motherboards than the AMD.
If you are trying to build a cheap system the i7-8xx series is probablly a better bet than the i7-9xx series It tends to give more performance per dollar and runs on cheaper motherboards. The downside is you get less PCIe and less memory slots.
Other than, of course, the fact that an intel GPU comes on the die of every intel CPU sold, atoms excepted(for now).
BULLSHIT. Intel do seem to be planning to go down that road but right now the only intel chips with a GPU on the cpu are the dual core i series chips and the pine trail atoms.
The quad-core and 6-core nahelm chips don't have any support for shared memory graphics at all afaict so you have to combine them with a graphics card/chip that has it's own memory (which most likely for a desktop means a nvidia or ATI card).
The older core 2 stuff uses a conventional FSB setup with any shared memory graphics being up to the chipset.
Sandy bridge will apparently be brining in on-die graphics to all intels mainstream chips.
http://hyperphysics.phy-astr.gsu.edu/hbase/icyl.html#icyl2
It depends on what values you consider constant. If you consider mass as a constant then moment of inertia is proportional to the square of the radius but if you consider density and thickness to be constants then moment of inertia is proportional to the fourth power of the radius.
IMO when talking about platters considering thickness and density as constants is more sensible than considering mass as a constant.