Let me know when there's a nice ipod-like device with 8-16GB of flash, a nice touch screen (with or without keyboard), sans-phone that runs Android, for about $250. Then I'll get excited about Android. In the meantime my ipodtouch is everything I've ever wanted in a PDA, except that the open source ecosystem is very stunted, thanks to Apple's controlling view of things, and also the so-called shareware scene that has always pervaded Macdom. Paying a buck for some stupid little app doesn't sit well with me, especially when I'd often write the app for myself for free based on OSS if I could, but I can't. I don't own a Mac that I can run Xcode 3.1 on, I don't want to pay apple for a provisioning key.
The moment I can get an equivalent device to the ipod touch that runs Android, I'm there.
But doesn't IPv6 actually make routing easier because much of the routing information can be ascertained from the IP address itself? One of the big points about IPv6 was that it was self-routing?
Or don't worry about it. SPF is overrated, and no one I know of uses it to actually drop mail. I have never set up SPF, and I send mail from a variety of servers for my domain. Incoming mail is handled by Google Apps. I've never had any problems with my mail ending up in/dev/null. SPF is a broken idea anyway, and doesn't prevent spam as spammers were some of the first to jump on board with SPF-compliance.
This is interesting as Apple didn't invent multi-touch by any means. I don't even think Microsoft did, although they demonstrated it well before the iPhone came along. Another example of how broken the patent system really is. Very unfortunate.
Very good points, although you are putting words in my mouth. And if you read what I said, I am actually saying the way Apple did it was an advantage, despite the fact that I dislike ObjC itself. With Cocoa on the iPhone I can use C or Python, or any language that has a bridge as you say. This is a *good* thing.
As for Python being a better solution for Apple, no I never said that. However I did say that for many developers, Python might be a better solution than ObjC, depending on the need. That is it.
I don't think Python is relevant to, or appropriate for the purpose for which Cocoa exists as an API on the iPhone. I don't think that having the core APIs based on Java is good either, for the simple reasons that lower-level access to the OS is restricted, eliminating any advantage that an underlying unix system provides, and that it's much much harder to tie a non-jvm language and runtime into it.
You misunderstand how Jython works. It's not a compiler. It's part interpreter, part JIT, targeting the JVM directly. From what I understand, Jython emits JVM bytecodes at runtime. So no, you can't just convert Jython programs to the new JVM, since they aren't java.class files. You have to port Jython to Android's JVM (which will happen, but it will take some time).
Why not? No it's not just an embedded device. It's a full computer. At least if you want an android device to be an iPhone killer. Have you ever actually used an iPhone? One that's jailbroken with apps and scripts written in various languages? I would guess you've never seen or used a jailbreaked iPhone with python, ruby, C, ObjC apps, all running quite comfortably. It is technically an "embedded device" but very ably hosted an entire range of languages and runtimes, ably bound to the core compiled APIs.
What you're basically implying is that Android is not scalable. This is indeed a worrisome thing, as it basically means Android as a platform isn't viable long-term for devices whose capabilities are continually increasing and infringing on traditional workstation territory. Apple took the position that it is stupid to have a special custom platform (API, languages, etc) for the iPhone. Since there are already cocoa bindings for a number of languages, they instantly support every language that can be used with Cocoa in the desktop. With very little overhead too. Thus they took what already worked well, and scaled it down, quite nicely. Some day I'd expect a complete merger of OS X for desktops vs OS X for the iPhone. Too bad the iPhone is turning out to be a great experiment (successful, I might add) in so-called "Trusted Computing." Does not bode well for the future.
If Google wants Android to have the widest range of developer appeal and device support, adding support for other languages is desirable. Of course as you say some devices are less capable than others. Obviously my low-end nokrapia phone wouldn't want to run anything but the most stripped down java applications under the smallest android footprint possible. But an application like a PDA or an iPod-like device, which is much more capable, should be able to easily accommodate this.
Android certainly has potential, but so far I see a number of things that prevent it from being an iPhone killer.
First off, it's entirely Java based. This is just plain silly. Why not have the APIs with bindings for Java? Google has completely cut off other languages. Furthermore, while speed normally isn't an issue with Java these days, there is overhead. Could one really build the X-Plane[1] simulator in Java like they did for the iPod? It's pretty CPU and i/o intensive (calculating force vectors and loading textures, building 3-d models etc, at 30 frames a second). While the iPhone's SDK is mainly objective-C (which I think is pretty silly too), there are a number of languages that you can use to develop with including Python, using an objC bridge. Currently this is not the case with Android. It's only Java. Part of what made the iPhone and Touch so cool early on was that they were little unix systems and one could install python or ruby or any other language and hack together neat scripts and things. Of course Apple has kind of put an end to much of that though, with their official SDK. While Python and probably Ruby can be used, the guts of the iPhone are once again off-limits. It may as well not even be a unix system anymore for all the good it does developers and users. Very sad. Android is open and happens to be able to run on a Linux core, but with core APIs all in Java, there's currently no way to interface from a shell script or to build ad-hoc applications. JPython isn't the solution either since Android's jvm is completely incompatible with Sun's and JPython emits bytecode directly.
Secondly, I have yet to see that Android really does support multi-touch operations. Demos I've seen so far look fairly conventional, using buttons to zoom, and so forth. I've also seen a fair number of pop-up menus in use in Android apps, which just don't work as well as the way that most iPhone apps typically do it. Perhaps this is mainly do to the poor way in which the UIs have been constructed in the Android apps that I've seen video demos of.
Of course this is all a useless exercise for the purposes for which Chrome would really be useful: running google apps. Without SSL support working in Wine, I can't even log in. Until SSL works, chrome under wine is a mere curiosity, and a wine technology demo as Codeweavers says.
ZFS does have issues with NFS though. In particular NFS writes can lock up the client. Hopefully this issue will be fixed soon. it's not really ZFS's fault; it's NFS's fault. Yet no other FS has this issue, so I'm sure a workaround could be done. In the meantime there are times when the NFS clients on our 12 TB ZFS (Solaris 10) system are unusable.
ZFS will never come to Linux while the license remains incompatible with the GPL. I predict that one day Sun will relicense it, but not before they've really tried and failed with OpenSolaris. I think the FUSE idea is viable though. Just that the developer who was doing it is now working for Sun and has no time/inclination to do more with it. In theory all file systems should be implemented with a FUSE-type of separation from the kernel. This hearkens back to the Mach days where file systems were envisioned to just be user-space servers. Now it just might work. NTFS-3g has really good performance, really, and it is fuse. And when it crashes, it won't take down the OS.
So far the community or lack of, surrounding OpenSolaris is pretty disappointing. I think Sun just thought it would magically happen. Long term, I'd rather see the best technologies of Linux and Solaris merge (Linux massive hardware support, scheduler, dtrace, zones, zfs), rather than continuing in separate directions.
Sorry, but that's a really bad analogy. To replace one bad analogy with another bad analogy, it's more like a company sells engines that use a special, patented, proprietary engine mount and transmission adapter. Sure I could buy the engine, machine the mounts myself and install the engine in my piece of crap car. But if I wanted to make a business selling cars with this engine in them, I'd be in violation of the patents to machine and sell the mount and the unit that mates it to the transmision. Now of course we're not talking about patents here. But that's probably the closed analogy to licenses in the real, physical world (which of course illustrates why EULAs are silly to begin with).
Well of course there's life out there, and there's a high probability of intelligent life out there too. Whether or not green little men regularly visit us is another story. Yes, this guy does come across sounding like a nut.
Reminds me of Douglas Adams' HHGTG where Ford Prefect hitched a ride to earth with a teaser. What is a teaser, you ask? Well it's basically a rich kid with too much time on his hands so he visits under-developed planets and finds unsuspecting folks and dresses up in a green suit and makes beep beep noises at them. Then flies off, knowing no one will ever believe this poor person.
Uh, no. I have no collector's item. If I really had a Psystar machine, then I really just end up with an overpriced intel box. That's not the point either. The point is, asking Psystar to recall it's PCs is pretty silly since Psystar doesn't own them anymore.
If I bought something, it's now mine (the hardware anyway). I doubt Pystar can actually repossess any of the boxes. The entire demand by Apple is pretty silly. Apple's copyright claims can't possibly cover the possession of physical hardware. Very bizarre. I think Apple only has a claim against Psystar itself over copyright infringement (the distribution of hacked Apple patches). Personal use of OS X in breach of Apple's license would have to be an issue that Apple would have to deal with on a per user basis, which I doubt they are willing to do.
Several areas in southern Alberta might be regretting that decision today. Yesterday a major storm did a number on several areas. I know wireless is knocked out in the community where my parents live. And likely will take a while to fix, since the building the transmitter on (the grain elevator... ha) was heavily damaged by the wind. Seeing as it's the only readily available tall building in the area, they will likely be without any internet at all for some time.
If you look at the overviews of their ideas, you can tell right away that this launch system would have several advantages over Aries. It does not require a modification of the boosters, which is one of the more significant design challenges that Aries, especially the crew lift system, is facing. Additionally they don't call for a significantly different vehicle to lift the crew. While they do propose a few different systems for lifting cargo vs lifting cargo and people, the base vehicle engineering is the same, unlike the Aries system. In short, it really looks like this Jupiter system is more flexible, maybe cheaper, and certainly easier than Aries is turning out to be. I also think that Jupiter could be built, tested, and launched quicker than Aries.
This group's ideas are not new though, they proposed them a few years back, but NASA seemed to be set on Aries from almost the very start for some odd reason.
If we had biodiesel, or any bio-fuel such as what this company claims to be in on, that could burn without producing any soot, then that would be an absolutely *great* thing. Of course combustion produces carbon dioxide when there are carbon molecules in the fuel being oxidized. But if that carbon came from the air to begin with (via plants) then it just doesn't matter. It's as if there was no carbon dioxide being emitted at all! That's the entire point of the biofuel industry. Once we can produce hydrocarbons from plans efficiently, then all we have to do is control particulate and NOx emissions and we finally do have a completely clean, environmentally-friendly, non-global-warming fuel. CO2 emissions, notwithstanding because the net CO2 emission would be zero. This is the ideal panacea. That's the reason claims like this company's claims can really excite people and investors, which is really unfortunate if the company is just trying to swindle people.
No the infrastructure is *not* there. If you calculate the amount of energy represented by all the cars running in the US at one time, it's staggering. There's no way the electrical grid could provide even a fraction of that, even if people were slow-charging their cars. Besides that, we don't have the generating capacity, which comes from coal and natural gas. That may or may not emit less carbon than we currently are. Even with long term expansion, the electric car just doesn't appear to be that viable.
Do you seriously think that GM is struggling because they are making products no one wants? On the contrary consumers are extremely resistant to change. Even alternative fuels are resisted because the rated MPG goes down (yes people are that stupid). GM builds and sells what consumers want. Period. Up until now very few hybrid cars have ever made money for the manufacture. A lot of that is definitely marketing. Toyota really markets it well and so hybrids are more popular now, but I don't think initially Toyota made much money there. They do now, though, so it did pay off. GM and Ford are more conservative, this is true. GM is getting into hybrids in a big way now that the market finally exists. People seem to blindly criticize GM and Ford while conveniently forgetting basic principles of economics. The same folks who criticize them in the auto magazines are the same ones that turn around and complain about their vehicles that do try to address their criticisms.
The fact is that the same things that are killing GM and Ford are going to eventually kill Toyota too, now that Toyota is one of the big 3 automakers and has moved into the manufacturing of vehicles here in the US. Health care costs and unions killed GM and Ford. Plain and simple. Toyota hasn't had this problem up until now because they were largely based overseas where unions and ideas about corporate-sponsored health care don't have the same traction.
What killed the electric car? Economics, plain and simple. There was no demand. Even now there isn't that great of demand for an electric car. It's one of those nice ideas that everyone talks about, but no one really seems to want, as witnessed by the continued sale of very large gasoline-powered vehicles. Furthermore, abandoning combustion engines is just silly. Except for onboard nukes, hydrocarbons are plain and simple the best way to package the most amount of energy into a fixed volume. Batteries just aren't likely to cut it. Internal combustion happens to be a very well-understood method of utilizing that energy. And it can be clean and totally green. The future is in trying to manufacture carbon-neutral fuels, while using technologies like hybrid cars and fuel cells to increase the overall efficiency of extracting energy. If some day we cover all our transportation energy needs with a carbon-neutral hydrocarbons, then even nuclear power would be kind of undesirable since it's fossil fuel too.
That's quite possibly one of the most *uninsightful* comments I've heard in a while. Economies of scale, both in money and fuel consumption are still valid. High fuel costs will make flying smaller planes less and less viable.
The market for big birds most certainly is not dead. Small Cesna's and even regional jets are quite inefficient compared to the heavies. Before the 767 and 777, the 747 was the most economical plane in the world, if you could fill it. The 787 will be the most economical plane in the world when it's released this year. It will fly large numbers of people at a time intercontinental and trans-oceanic.
If we all started flying our private planes, it'd be as bad as cars on our freeway now with few passengers and burning up a lot of fuel per person.
The 747's days are numbered, but that's mainly because of the 787 and, to a lesser degree, the A380.
I call BS. KDE uses the Qt toolkit to do all UI drawing. Qt is the most polished toolkit out there, in terms of look and feel and functionality, *on any platform*. While open source UI's in general are poor (layout, usability), the look and feel of individual widgets is certainly as good as on any platform. KDE 4.x will also be available on OS X as native apps! And they will look just like your Mac apps, thanks to Qt. I could drop a Qt application on your Mac right now, and it'd look almost indistinguishable from a native Cocoa app. Qt excels at looking great on any platform. Now with Qt 4.4, we're seeing an increase in vector graphics use throughout the toolkit. This means widgets and themes are going to look even better!
I can tell you have no significant experience in GUI design. *No one* does absolute position of widgets on any platform anymore, at least on a pixel level. Instead GUIs have to be more fluid and dynamic and respond reasonably to resizes of the window. Yes things have to line up. That's what alignment widgets are for and packing managers. Even OS X's Interface Builder is going to have to change now that Aqua is finally vector-based (it wasn't before Leopard), and can support very high resolution displays. Dropping widgets on a grid is silly. Nothing annoys me more than a dialog box that can't be resized because someone assumed I'm running at a certain DPI and with a certain font size.
235 MPG is impressive, and this concept car is *really* cool looking, which is a rare thing when it comes to super efficient, futuristic concept cars. While I really doubt will see cars like this on the road anytime soon, this car does bring to mind some things, though, particularly in the weight department. If we took our current engine technologies (not even hybrid) and put them in much lighter cars, we'd likely be able to have cars average close to 100 MPG without any special work.
Compared to light cars in the 1970s, our cars are much heavier (1000-2000 pounds heavier on average), but produce much, much more power from the same amount of gas than engines in the 70s did. Not to mention they are now better looking than the boxes of the 70s.
Basically all the extra efficiency our engines now have is pretty much wasted by the fact that we're hauling around so much extra weight. If we lighten our cars a bit and then stop this silly addiction to "power" (really acceleration), we'd be a long ways closer to practical cars that get 100 MPG right now. That'd pave the way for mass appeal of cars like this VW concept.
No question desert[1] is the best color scheme. Easy on the eyes, good contrast, good colors for different types of programming language components. It's a standard color scheme in Vim. On an xterm I for the colors to 256 and then use desert256[2].
I guess you need a bigger hint then. What you are talking about has nothing to do with what a "toll number" is. A hint: It's the opposite of a "toll-free number."
A toll number is a number where you a billed for the time you spend connected to it, above and beyond any normal minute rate your phone has. Although the most obvious examples are the infamous 1-900 numbers, a 1-800 number can also charge you for connecting to it if the company has set it up that way. Almost all tech support lines are toll numbers. Microsoft, etc. Some are really expensive, like $4 a minute. More information on this phenomenon can be found at http://en.wikipedia.org/wiki/900_number --including a little sentence that mentions that sometimes 1-800 numbers also charge tolls.
It's funny that so many posters are very confused on this issue. I guess this is slashdot and so no one here has ever had the (mis)fortune of having to call a tech company for support.
Slashdot Mirror
Let me know when there's a nice ipod-like device with 8-16GB of flash, a nice touch screen (with or without keyboard), sans-phone that runs Android, for about $250. Then I'll get excited about Android. In the meantime my ipodtouch is everything I've ever wanted in a PDA, except that the open source ecosystem is very stunted, thanks to Apple's controlling view of things, and also the so-called shareware scene that has always pervaded Macdom. Paying a buck for some stupid little app doesn't sit well with me, especially when I'd often write the app for myself for free based on OSS if I could, but I can't. I don't own a Mac that I can run Xcode 3.1 on, I don't want to pay apple for a provisioning key.
The moment I can get an equivalent device to the ipod touch that runs Android, I'm there.
But doesn't IPv6 actually make routing easier because much of the routing information can be ascertained from the IP address itself? One of the big points about IPv6 was that it was self-routing?
Or don't worry about it. SPF is overrated, and no one I know of uses it to actually drop mail. I have never set up SPF, and I send mail from a variety of servers for my domain. Incoming mail is handled by Google Apps. I've never had any problems with my mail ending up in /dev/null. SPF is a broken idea anyway, and doesn't prevent spam as spammers were some of the first to jump on board with SPF-compliance.
This is interesting as Apple didn't invent multi-touch by any means. I don't even think Microsoft did, although they demonstrated it well before the iPhone came along. Another example of how broken the patent system really is. Very unfortunate.
Very good points, although you are putting words in my mouth. And if you read what I said, I am actually saying the way Apple did it was an advantage, despite the fact that I dislike ObjC itself. With Cocoa on the iPhone I can use C or Python, or any language that has a bridge as you say. This is a *good* thing.
As for Python being a better solution for Apple, no I never said that. However I did say that for many developers, Python might be a better solution than ObjC, depending on the need. That is it.
I don't think Python is relevant to, or appropriate for the purpose for which Cocoa exists as an API on the iPhone. I don't think that having the core APIs based on Java is good either, for the simple reasons that lower-level access to the OS is restricted, eliminating any advantage that an underlying unix system provides, and that it's much much harder to tie a non-jvm language and runtime into it.
You misunderstand how Jython works. It's not a compiler. It's part interpreter, part JIT, targeting the JVM directly. From what I understand, Jython emits JVM bytecodes at runtime. So no, you can't just convert Jython programs to the new JVM, since they aren't java .class files. You have to port Jython to Android's JVM (which will happen, but it will take some time).
Why not? No it's not just an embedded device. It's a full computer. At least if you want an android device to be an iPhone killer. Have you ever actually used an iPhone? One that's jailbroken with apps and scripts written in various languages? I would guess you've never seen or used a jailbreaked iPhone with python, ruby, C, ObjC apps, all running quite comfortably. It is technically an "embedded device" but very ably hosted an entire range of languages and runtimes, ably bound to the core compiled APIs.
What you're basically implying is that Android is not scalable. This is indeed a worrisome thing, as it basically means Android as a platform isn't viable long-term for devices whose capabilities are continually increasing and infringing on traditional workstation territory. Apple took the position that it is stupid to have a special custom platform (API, languages, etc) for the iPhone. Since there are already cocoa bindings for a number of languages, they instantly support every language that can be used with Cocoa in the desktop. With very little overhead too. Thus they took what already worked well, and scaled it down, quite nicely. Some day I'd expect a complete merger of OS X for desktops vs OS X for the iPhone. Too bad the iPhone is turning out to be a great experiment (successful, I might add) in so-called "Trusted Computing." Does not bode well for the future.
If Google wants Android to have the widest range of developer appeal and device support, adding support for other languages is desirable. Of course as you say some devices are less capable than others. Obviously my low-end nokrapia phone wouldn't want to run anything but the most stripped down java applications under the smallest android footprint possible. But an application like a PDA or an iPod-like device, which is much more capable, should be able to easily accommodate this.
Android certainly has potential, but so far I see a number of things that prevent it from being an iPhone killer.
First off, it's entirely Java based. This is just plain silly. Why not have the APIs with bindings for Java? Google has completely cut off other languages. Furthermore, while speed normally isn't an issue with Java these days, there is overhead. Could one really build the X-Plane[1] simulator in Java like they did for the iPod? It's pretty CPU and i/o intensive (calculating force vectors and loading textures, building 3-d models etc, at 30 frames a second). While the iPhone's SDK is mainly objective-C (which I think is pretty silly too), there are a number of languages that you can use to develop with including Python, using an objC bridge. Currently this is not the case with Android. It's only Java. Part of what made the iPhone and Touch so cool early on was that they were little unix systems and one could install python or ruby or any other language and hack together neat scripts and things. Of course Apple has kind of put an end to much of that though, with their official SDK. While Python and probably Ruby can be used, the guts of the iPhone are once again off-limits. It may as well not even be a unix system anymore for all the good it does developers and users. Very sad. Android is open and happens to be able to run on a Linux core, but with core APIs all in Java, there's currently no way to interface from a shell script or to build ad-hoc applications. JPython isn't the solution either since Android's jvm is completely incompatible with Sun's and JPython emits bytecode directly.
Secondly, I have yet to see that Android really does support multi-touch operations. Demos I've seen so far look fairly conventional, using buttons to zoom, and so forth. I've also seen a fair number of pop-up menus in use in Android apps, which just don't work as well as the way that most iPhone apps typically do it. Perhaps this is mainly do to the poor way in which the UIs have been constructed in the Android apps that I've seen video demos of.
[1] http://www.x-plane.com/iPhone.html
This pretty much blows my mind:
http://www.sorn.net/media/photos/blog/cobol-gtk-sharp.png
The compiler here is called Wildcat, and it's a .NET compiler (runs on the CLR).
Of course this is all a useless exercise for the purposes for which Chrome would really be useful: running google apps. Without SSL support working in Wine, I can't even log in. Until SSL works, chrome under wine is a mere curiosity, and a wine technology demo as Codeweavers says.
ZFS does have issues with NFS though. In particular NFS writes can lock up the client. Hopefully this issue will be fixed soon. it's not really ZFS's fault; it's NFS's fault. Yet no other FS has this issue, so I'm sure a workaround could be done. In the meantime there are times when the NFS clients on our 12 TB ZFS (Solaris 10) system are unusable.
ZFS will never come to Linux while the license remains incompatible with the GPL. I predict that one day Sun will relicense it, but not before they've really tried and failed with OpenSolaris. I think the FUSE idea is viable though. Just that the developer who was doing it is now working for Sun and has no time/inclination to do more with it. In theory all file systems should be implemented with a FUSE-type of separation from the kernel. This hearkens back to the Mach days where file systems were envisioned to just be user-space servers. Now it just might work. NTFS-3g has really good performance, really, and it is fuse. And when it crashes, it won't take down the OS.
So far the community or lack of, surrounding OpenSolaris is pretty disappointing. I think Sun just thought it would magically happen. Long term, I'd rather see the best technologies of Linux and Solaris merge (Linux massive hardware support, scheduler, dtrace, zones, zfs), rather than continuing in separate directions.
Sorry, but that's a really bad analogy. To replace one bad analogy with another bad analogy, it's more like a company sells engines that use a special, patented, proprietary engine mount and transmission adapter. Sure I could buy the engine, machine the mounts myself and install the engine in my piece of crap car. But if I wanted to make a business selling cars with this engine in them, I'd be in violation of the patents to machine and sell the mount and the unit that mates it to the transmision. Now of course we're not talking about patents here. But that's probably the closed analogy to licenses in the real, physical world (which of course illustrates why EULAs are silly to begin with).
Well of course there's life out there, and there's a high probability of intelligent life out there too. Whether or not green little men regularly visit us is another story. Yes, this guy does come across sounding like a nut.
Reminds me of Douglas Adams' HHGTG where Ford Prefect hitched a ride to earth with a teaser. What is a teaser, you ask? Well it's basically a rich kid with too much time on his hands so he visits under-developed planets and finds unsuspecting folks and dresses up in a green suit and makes beep beep noises at them. Then flies off, knowing no one will ever believe this poor person.
Uh, no. I have no collector's item. If I really had a Psystar machine, then I really just end up with an overpriced intel box. That's not the point either. The point is, asking Psystar to recall it's PCs is pretty silly since Psystar doesn't own them anymore.
If I bought something, it's now mine (the hardware anyway). I doubt Pystar can actually repossess any of the boxes. The entire demand by Apple is pretty silly. Apple's copyright claims can't possibly cover the possession of physical hardware. Very bizarre. I think Apple only has a claim against Psystar itself over copyright infringement (the distribution of hacked Apple patches). Personal use of OS X in breach of Apple's license would have to be an issue that Apple would have to deal with on a per user basis, which I doubt they are willing to do.
Several areas in southern Alberta might be regretting that decision today. Yesterday a major storm did a number on several areas. I know wireless is knocked out in the community where my parents live. And likely will take a while to fix, since the building the transmitter on (the grain elevator... ha) was heavily damaged by the wind. Seeing as it's the only readily available tall building in the area, they will likely be without any internet at all for some time.
If you look at the overviews of their ideas, you can tell right away that this launch system would have several advantages over Aries. It does not require a modification of the boosters, which is one of the more significant design challenges that Aries, especially the crew lift system, is facing. Additionally they don't call for a significantly different vehicle to lift the crew. While they do propose a few different systems for lifting cargo vs lifting cargo and people, the base vehicle engineering is the same, unlike the Aries system. In short, it really looks like this Jupiter system is more flexible, maybe cheaper, and certainly easier than Aries is turning out to be. I also think that Jupiter could be built, tested, and launched quicker than Aries.
This group's ideas are not new though, they proposed them a few years back, but NASA seemed to be set on Aries from almost the very start for some odd reason.
If we had biodiesel, or any bio-fuel such as what this company claims to be in on, that could burn without producing any soot, then that would be an absolutely *great* thing. Of course combustion produces carbon dioxide when there are carbon molecules in the fuel being oxidized. But if that carbon came from the air to begin with (via plants) then it just doesn't matter. It's as if there was no carbon dioxide being emitted at all! That's the entire point of the biofuel industry. Once we can produce hydrocarbons from plans efficiently, then all we have to do is control particulate and NOx emissions and we finally do have a completely clean, environmentally-friendly, non-global-warming fuel. CO2 emissions, notwithstanding because the net CO2 emission would be zero. This is the ideal panacea. That's the reason claims like this company's claims can really excite people and investors, which is really unfortunate if the company is just trying to swindle people.
No the infrastructure is *not* there. If you calculate the amount of energy represented by all the cars running in the US at one time, it's staggering. There's no way the electrical grid could provide even a fraction of that, even if people were slow-charging their cars. Besides that, we don't have the generating capacity, which comes from coal and natural gas. That may or may not emit less carbon than we currently are. Even with long term expansion, the electric car just doesn't appear to be that viable.
Do you seriously think that GM is struggling because they are making products no one wants? On the contrary consumers are extremely resistant to change. Even alternative fuels are resisted because the rated MPG goes down (yes people are that stupid). GM builds and sells what consumers want. Period. Up until now very few hybrid cars have ever made money for the manufacture. A lot of that is definitely marketing. Toyota really markets it well and so hybrids are more popular now, but I don't think initially Toyota made much money there. They do now, though, so it did pay off. GM and Ford are more conservative, this is true. GM is getting into hybrids in a big way now that the market finally exists. People seem to blindly criticize GM and Ford while conveniently forgetting basic principles of economics. The same folks who criticize them in the auto magazines are the same ones that turn around and complain about their vehicles that do try to address their criticisms.
The fact is that the same things that are killing GM and Ford are going to eventually kill Toyota too, now that Toyota is one of the big 3 automakers and has moved into the manufacturing of vehicles here in the US. Health care costs and unions killed GM and Ford. Plain and simple. Toyota hasn't had this problem up until now because they were largely based overseas where unions and ideas about corporate-sponsored health care don't have the same traction.
What killed the electric car? Economics, plain and simple. There was no demand. Even now there isn't that great of demand for an electric car. It's one of those nice ideas that everyone talks about, but no one really seems to want, as witnessed by the continued sale of very large gasoline-powered vehicles. Furthermore, abandoning combustion engines is just silly. Except for onboard nukes, hydrocarbons are plain and simple the best way to package the most amount of energy into a fixed volume. Batteries just aren't likely to cut it. Internal combustion happens to be a very well-understood method of utilizing that energy. And it can be clean and totally green. The future is in trying to manufacture carbon-neutral fuels, while using technologies like hybrid cars and fuel cells to increase the overall efficiency of extracting energy. If some day we cover all our transportation energy needs with a carbon-neutral hydrocarbons, then even nuclear power would be kind of undesirable since it's fossil fuel too.
That's quite possibly one of the most *uninsightful* comments I've heard in a while. Economies of scale, both in money and fuel consumption are still valid. High fuel costs will make flying smaller planes less and less viable.
The market for big birds most certainly is not dead. Small Cesna's and even regional jets are quite inefficient compared to the heavies. Before the 767 and 777, the 747 was the most economical plane in the world, if you could fill it. The 787 will be the most economical plane in the world when it's released this year. It will fly large numbers of people at a time intercontinental and trans-oceanic.
If we all started flying our private planes, it'd be as bad as cars on our freeway now with few passengers and burning up a lot of fuel per person.
The 747's days are numbered, but that's mainly because of the 787 and, to a lesser degree, the A380.
I call BS. KDE uses the Qt toolkit to do all UI drawing. Qt is the most polished toolkit out there, in terms of look and feel and functionality, *on any platform*. While open source UI's in general are poor (layout, usability), the look and feel of individual widgets is certainly as good as on any platform. KDE 4.x will also be available on OS X as native apps! And they will look just like your Mac apps, thanks to Qt. I could drop a Qt application on your Mac right now, and it'd look almost indistinguishable from a native Cocoa app. Qt excels at looking great on any platform. Now with Qt 4.4, we're seeing an increase in vector graphics use throughout the toolkit. This means widgets and themes are going to look even better!
I can tell you have no significant experience in GUI design. *No one* does absolute position of widgets on any platform anymore, at least on a pixel level. Instead GUIs have to be more fluid and dynamic and respond reasonably to resizes of the window. Yes things have to line up. That's what alignment widgets are for and packing managers. Even OS X's Interface Builder is going to have to change now that Aqua is finally vector-based (it wasn't before Leopard), and can support very high resolution displays. Dropping widgets on a grid is silly. Nothing annoys me more than a dialog box that can't be resized because someone assumed I'm running at a certain DPI and with a certain font size.
235 MPG is impressive, and this concept car is *really* cool looking, which is a rare thing when it comes to super efficient, futuristic concept cars. While I really doubt will see cars like this on the road anytime soon, this car does bring to mind some things, though, particularly in the weight department. If we took our current engine technologies (not even hybrid) and put them in much lighter cars, we'd likely be able to have cars average close to 100 MPG without any special work.
Compared to light cars in the 1970s, our cars are much heavier (1000-2000 pounds heavier on average), but produce much, much more power from the same amount of gas than engines in the 70s did. Not to mention they are now better looking than the boxes of the 70s.
Basically all the extra efficiency our engines now have is pretty much wasted by the fact that we're hauling around so much extra weight. If we lighten our cars a bit and then stop this silly addiction to "power" (really acceleration), we'd be a long ways closer to practical cars that get 100 MPG right now. That'd pave the way for mass appeal of cars like this VW concept.
No question desert[1] is the best color scheme. Easy on the eyes, good contrast, good colors for different types of programming language components. It's a standard color scheme in Vim. On an xterm I for the colors to 256 and then use desert256[2].
[1] http://www.vim.org/scripts/script.php?script_id=105
[2] http://www.vim.org/scripts/script.php?script_id=1243
I guess you need a bigger hint then. What you are talking about has nothing to do with what a "toll number" is. A hint: It's the opposite of a "toll-free number."
A toll number is a number where you a billed for the time you spend connected to it, above and beyond any normal minute rate your phone has. Although the most obvious examples are the infamous 1-900 numbers, a 1-800 number can also charge you for connecting to it if the company has set it up that way. Almost all tech support lines are toll numbers. Microsoft, etc. Some are really expensive, like $4 a minute. More information on this phenomenon can be found at http://en.wikipedia.org/wiki/900_number --including a little sentence that mentions that sometimes 1-800 numbers also charge tolls.
It's funny that so many posters are very confused on this issue. I guess this is slashdot and so no one here has ever had the (mis)fortune of having to call a tech company for support.