Red shift and the properties of visible light travelling means that you indeed see "false colour" images, but there are no "real" colours to speak of on the other hand. If you would park your space ship a few million miles then the picture would look entirely different, not just in the colours.
False colour in this case is about visualizing non-visible frequencies of light.
Second, it's worthless for getting stuff into orbit. The reason is simple - the reason a rocket costs so darn much has nothing to do with fuel. It has to do with complexity - it's very expensive to make something as complicated as a rocket work under all the stresses of a launch. A scramjet just worsens the problem. It's not the fuel or the size of the tankage that makes the rockets that SpaceX builds cost so much. It has to do with building the rocket well enough that it makes it and doesn't fail (again). A scramjet engine is evidently incredibly complex to make work, and is just another pork barrel project of the air force.
The reason a rocket costs so darn much has everything to do with fuel. According to Richard A. Mueller's book I've read recently, the mass of fuel used is usually 25-50 times larger than the payload it helps to put into orbit. For the space shuttle, it's 68 tons of payload vs. 1931 tons for the boosters and fuel weight.
For useful orbits the most important thing is to reach a high enough speed to stay in orbit. The required speed for practical orbiting is about 5 miles per second, so about mach 18.
You see airplanes are a lot more efficient than rockets for two reasons: first, they don't have to carry any oxidizer (air is available) and second: they are pushing against air itself, not against their own exhaust. Now, we can't reach mach 18 yet, so a purely aircraft driven approach to reach orbital velocities is not yet possible. However, it is possible to use a hybrid approach: use an aircraft to lift up the rocket to as high and as fast as technology allows and launch the rocket from there. This approach is currently commercially done by Orbital Sciences Corporation and they have already launched over 30 satellites this way.
The better scramjet designs become, the less expensive it becomes to put something in orbit, so scramjet tech is not worthless, on the contrary. It is possibly the cheapest way to put something in orbit barring a space elevator, but the good thing about the approach that this allows incremental improvements to the technology. A space elevator either works (but then it works very well) or it doesn't.
It's in libraries. It would be impractical to do so, since to display HTML, one needs to parse the HTML and based on that generate more requests for things to download.
Note that the thread you linked to compared schedulers based on per process CPU "usage" levels (90-95% vs 100%). Those numbers are not accurate representations of anything close for evaluating scheduling algorithms. There are many reasons for that, but let me just say that the number given there depends upon sampling and can be wildly inaccurate.
If they really wanted to test CPU gains from scheduling efficiency, they should have tested the difference in time between a specific work unit when using different schedulers, eliminating the need to rely on an indirect and inaccurate sampling method and measuring what's important: work done in a given amount of time.
A browser should implement HTML4/5, various XHTML versions, Javascript, support various multimedia protocols and that's it. Everything else can be integrated as a plugin.
The Unix philosophy would demand separation of the code that implements all of this from the actual UI.
I really hope European carriers will carry the N900, because I'm planning on getting one. It looks really sweet for basic phone + capable mobile computing device with apt-get usage that I'd like to use it for.
The sad news is that we won't be running out of fuel any time soon. The output from fossil fuel sources will slowly decline over time though. However, there is a fairly little known thing called Fischer-Tropsch process which is a way of converting coal into synthetic petroleum. This process works as long as you're willing to pay $50 USD / barrel for producing it. Since using coal releases about 20x more CO2 than fossil fuels and will not run out for hundreds of years even assuming increasing demand, this is bad news for stopping the use of fossil fuels based on economic reasons.
We have the capacity to keep using fossil fuels for a couple of centuries still, so if we care about the massive self inflicted damage that would cause, we have to stop using dirty fuel sources for that reason, not because it makes economical sense to do so. It doesn't hurt to have cheap available solar cells though.
Except that the passion for learning needs a base to build on, which means parental support and inborn natural curiosity.
The level of knowledge we're talking about in homeschooling isn't a good avenue for autodidactism anyway, as it should be about basic, general knowledge. Kids are learning too little in primary/high school in the first place.
It's more the case of hedging characteristics against each other.
1. SSDs handle random I/O extremely well compared to traditional harddisks.
2. Braidwood is essentially a small, cheap, 8-16GB flash based cache.
3. If Braidwood is transparent to the OS, it will have a hard time guessing what to put in the cache, because a lot of the I/O on a desktop/laptop is random, but the issue with caching the non-random part is that most OSs do caching themselves for frequently accessed parts of the disk. This means that for a transparent caching solution like that it is very hard to tell the difference between a frequently accessed piece of executable data and random I/O, since in both cases, it only gets accessed once per startup/shutdown cycle, for frequently accessed stuff it is already cached in memory, for random I/O, it is simply never requested again for a long time. So to make this caching work the flash thing either needs OS level support or very sophisticated statistics collection specifically tuned for keeping track of patterns across reboots and providing a caching solution for startup basically.
Not really. I don't doubt that Braidwood would increase performance since I/O be it memory or disk is not entirely random - there are parts of the memory and disk more frequently accessed therefor cacheable. Oh btw, by cacheable I mean "non-marginal" performance benefit for using the cache. Even with random I/O, having a cache can increase performance a bit, but only very slightly.
Memory is usually cacheable a lot better than information on the disk however. Caching the operating system related files and executables on something like Braidwood would speed up things a lot, but it would be useless for any other area where high performance is needed, like gaming or working with larger files in general.
The article is bullshit! Random I/O is essentially uncacheable. I don't think the onboard cache will be 128-256GB in size, so tyvm but I'll stick to using a ssd.
The important performance aspects of the SSD is: random read, random write, sequential read, sequential write in this order.
I am fairly confident that at the very least, they expected a breatheable atmosphere at their destination.
I knew a 16th century sailor once. He often engaged in long metaphysical discussions about exasolar planets and the physical and socialogical equations governing long term terraforming processes. Alas, that was his hobby. Times were hard back then so oftentimes sailors such as him, preferred to keep themselves occupied with such trivial and mundane thoughts.
I don't know about that. I routinely get 3MB/s http downloads for overseas sites and bittorrent traffic is very rare not to max out my maximum available speed for a download.
However, I'm using linux and it has a lot better long fat network support than windows, that's a fact.
In Hungary, T-online has announced today that they're rolling out 80mbit FTTH to 180-200k subscribers by the end of the year. (This is a country of 10M).
They've also changed the minimum package from 2 to 5mbit, bumped up the non-fibre/vdsl package to 15mbit and drastically increased the minimum guaranteed bandwidth to 1mbit for the 5mbit connection and to 5mbit for the 15mbit connection.
Personally, I pay 50 EUR / mo for IPTV and 33mbit VDSL. I do not consider anything below 8mbit "broadband" these days.
Last year, SpaceX, along with a rival in the private launch-vehicle business, Orbital Sciences, received a $3.5 billion NASA cargo resupply contract to provide payload deliveries to the International Space Station after the Shuttle fleet is grounding for good next year (and before NASA's own Orion is operational). SpaceX's share will be $1.6 billion for 12 launches of it Falcon 9 vehicle (numbers which could easily increase).
Most of the article is about Tesla anyway. Interesting, but I'd prefer to read about SpaceX in a NASA related/. story.
This reminds me of the old joke some former ex-communist block countries have.
So Lenin is working in his study and suddently he realises there are kids playing football outside his window. He opens the window and shouts: "Get the fuck out of here stupid spastic kids!"
This proves conclusively what a good man Lenin was, he has to be applauded as such. He after all could have ordered the kids to be shot dead, no?
If you're using Microsoft software or doing business with Microsoft, you are at risk, you might be sued for IP violations! Do not forget to pay your $699 GNU license fee you Windows using faggots!
(No, I'm not serious but man! It feels good to throw a piece of FUD right back at the sender and remember some old/. troll in the process...)
The second problem is that SSDs rely on volatile write caches in order to achieve their stated write performance, which is just plain not acceptable for enterprise applications where honoring fsync is important, like all database ones. You end up with disk corruption if there's a crash, and as you can see in that article once everything was switched to only relying on non-volatile cache the performance of the SSD wasn't that much better than the RAID 10 system under test. The write IOPS claims of Intel's SSD products are garbage if you care about honoring write guarantees, which means it's not that hard to keep with them after all on the write side in a serious application.
Most enterprise level SSDs have BBWC already for exactly that reason. On those systems fsync is a noop. I for one am looking forward to SSDs in enterprise level applications, we could easily consolidate current database servers that are IOPS bottlenecked, with very low levels of CPU and non-caching memory utilization. BBWC solves the "oh, but we need to honour fsync" kind of problems. We're looking at a performance increase of 10-20x (IOPS) easily if >500G enterprise level SSDs become available for database servers. Even if prices/GB stay way above SAN prices, it's still more than worth it to switch.
Slashdot Mirror
Red shift and the properties of visible light travelling means that you indeed see "false colour" images, but there are no "real" colours to speak of on the other hand. If you would park your space ship a few million miles then the picture would look entirely different, not just in the colours.
False colour in this case is about visualizing non-visible frequencies of light.
See!
-- Anonymous Coward
The reason a rocket costs so darn much has everything to do with fuel. According to Richard A. Mueller's book I've read recently, the mass of fuel used is usually 25-50 times larger than the payload it helps to put into orbit. For the space shuttle, it's 68 tons of payload vs. 1931 tons for the boosters and fuel weight.
For useful orbits the most important thing is to reach a high enough speed to stay in orbit. The required speed for practical orbiting is about 5 miles per second, so about mach 18.
You see airplanes are a lot more efficient than rockets for two reasons: first, they don't have to carry any oxidizer (air is available) and second: they are pushing against air itself, not against their own exhaust. Now, we can't reach mach 18 yet, so a purely aircraft driven approach to reach orbital velocities is not yet possible. However, it is possible to use a hybrid approach: use an aircraft to lift up the rocket to as high and as fast as technology allows and launch the rocket from there. This approach is currently commercially done by Orbital Sciences Corporation and they have already launched over 30 satellites this way.
The better scramjet designs become, the less expensive it becomes to put something in orbit, so scramjet tech is not worthless, on the contrary. It is possibly the cheapest way to put something in orbit barring a space elevator, but the good thing about the approach that this allows incremental improvements to the technology. A space elevator either works (but then it works very well) or it doesn't.
I live in Hungary. ;-)
I wouldn't say the idea is "ridiculous", but it would definitely raise some eyebrows.
It's in libraries. It would be impractical to do so, since to display HTML, one needs to parse the HTML and based on that generate more requests for things to download.
Note that the thread you linked to compared schedulers based on per process CPU "usage" levels (90-95% vs 100%). Those numbers are not accurate representations of anything close for evaluating scheduling algorithms. There are many reasons for that, but let me just say that the number given there depends upon sampling and can be wildly inaccurate.
If they really wanted to test CPU gains from scheduling efficiency, they should have tested the difference in time between a specific work unit when using different schedulers, eliminating the need to rely on an indirect and inaccurate sampling method and measuring what's important: work done in a given amount of time.
You are thinking on the wrong abstraction level.
A browser should implement HTML4/5, various XHTML versions, Javascript, support various multimedia protocols and that's it. Everything else can be integrated as a plugin.
The Unix philosophy would demand separation of the code that implements all of this from the actual UI.
Yeah he sounded really weird. Almost as if he wouldn't like this phone to sell at all. Why would anyone trying to sell a phone do that?
I really hope European carriers will carry the N900, because I'm planning on getting one. It looks really sweet for basic phone + capable mobile computing device with apt-get usage that I'd like to use it for.
Should have clarified it with "liquid".
The sad news is that we won't be running out of fuel any time soon. The output from fossil fuel sources will slowly decline over time though. However, there is a fairly little known thing called Fischer-Tropsch process which is a way of converting coal into synthetic petroleum. This process works as long as you're willing to pay $50 USD / barrel for producing it. Since using coal releases about 20x more CO2 than fossil fuels and will not run out for hundreds of years even assuming increasing demand, this is bad news for stopping the use of fossil fuels based on economic reasons.
We have the capacity to keep using fossil fuels for a couple of centuries still, so if we care about the massive self inflicted damage that would cause, we have to stop using dirty fuel sources for that reason, not because it makes economical sense to do so. It doesn't hurt to have cheap available solar cells though.
Except that the passion for learning needs a base to build on, which means parental support and inborn natural curiosity.
The level of knowledge we're talking about in homeschooling isn't a good avenue for autodidactism anyway, as it should be about basic, general knowledge. Kids are learning too little in primary/high school in the first place.
Random I/O. The first is called non-sequential I/O.
It's more the case of hedging characteristics against each other.
1. SSDs handle random I/O extremely well compared to traditional harddisks.
2. Braidwood is essentially a small, cheap, 8-16GB flash based cache.
3. If Braidwood is transparent to the OS, it will have a hard time guessing what to put in the cache, because a lot of the I/O on a desktop/laptop is random, but the issue with caching the non-random part is that most OSs do caching themselves for frequently accessed parts of the disk. This means that for a transparent caching solution like that it is very hard to tell the difference between a frequently accessed piece of executable data and random I/O, since in both cases, it only gets accessed once per startup/shutdown cycle, for frequently accessed stuff it is already cached in memory, for random I/O, it is simply never requested again for a long time. So to make this caching work the flash thing either needs OS level support or very sophisticated statistics collection specifically tuned for keeping track of patterns across reboots and providing a caching solution for startup basically.
Not really. I don't doubt that Braidwood would increase performance since I/O be it memory or disk is not entirely random - there are parts of the memory and disk more frequently accessed therefor cacheable. Oh btw, by cacheable I mean "non-marginal" performance benefit for using the cache. Even with random I/O, having a cache can increase performance a bit, but only very slightly.
Memory is usually cacheable a lot better than information on the disk however. Caching the operating system related files and executables on something like Braidwood would speed up things a lot, but it would be useless for any other area where high performance is needed, like gaming or working with larger files in general.
The article is bullshit! Random I/O is essentially uncacheable. I don't think the onboard cache will be 128-256GB in size, so tyvm but I'll stick to using a ssd.
The important performance aspects of the SSD is: random read, random write, sequential read, sequential write in this order.
T-online is the biggest, almost monopoly ISP in Hungary. It is wholly owned by Deutche Telekom, the second largest telco company in Europe.
The setup that makes this work is virtual isps, regulation and increased state participation in planning infrastructure imo.
I knew a 16th century sailor once. He often engaged in long metaphysical discussions about exasolar planets and the physical and socialogical equations governing long term terraforming processes. Alas, that was his hobby. Times were hard back then so oftentimes sailors such as him, preferred to keep themselves occupied with such trivial and mundane thoughts.
I don't know about that. I routinely get 3MB/s http downloads for overseas sites and bittorrent traffic is very rare not to max out my maximum available speed for a download.
However, I'm using linux and it has a lot better long fat network support than windows, that's a fact.
In Hungary, T-online has announced today that they're rolling out 80mbit FTTH to 180-200k subscribers by the end of the year. (This is a country of 10M).
They've also changed the minimum package from 2 to 5mbit, bumped up the non-fibre/vdsl package to 15mbit and drastically increased the minimum guaranteed bandwidth to 1mbit for the 5mbit connection and to 5mbit for the 15mbit connection.
Personally, I pay 50 EUR / mo for IPTV and 33mbit VDSL. I do not consider anything below 8mbit "broadband" these days.
Most of the article is about Tesla anyway. Interesting, but I'd prefer to read about SpaceX in a NASA related /. story.
This reminds me of the old joke some former ex-communist block countries have.
So Lenin is working in his study and suddently he realises there are kids playing football outside his window. He opens the window and shouts: "Get the fuck out of here stupid spastic kids!"
This proves conclusively what a good man Lenin was, he has to be applauded as such. He after all could have ordered the kids to be shot dead, no?
If you're using Microsoft software or doing business with Microsoft, you are at risk, you might be sued for IP violations! Do not forget to pay your $699 GNU license fee you Windows using faggots!
/. troll in the process...)
(No, I'm not serious but man! It feels good to throw a piece of FUD right back at the sender and remember some old
Most enterprise level SSDs have BBWC already for exactly that reason. On those systems fsync is a noop. I for one am looking forward to SSDs in enterprise level applications, we could easily consolidate current database servers that are IOPS bottlenecked, with very low levels of CPU and non-caching memory utilization. BBWC solves the "oh, but we need to honour fsync" kind of problems. We're looking at a performance increase of 10-20x (IOPS) easily if >500G enterprise level SSDs become available for database servers. Even if prices/GB stay way above SAN prices, it's still more than worth it to switch.
As viral as any licence agreement that has any terms. You could argue that the GPL is a pretty mild one when setting terms, nothing unreasonable...