Well, large amounts of heat (say, from power plants) can be transported reasonably well and are used for heating in many countries around the world. Small amounts of heat from domestic use can be stored and used when they are needed: in most places, you need heat during the night even if it is hot during the day, and you need hot water at any time.
Why would I want to sacrifice my limited outgoing bandwidth to serve someone else's content? And how would I ensure that my "peer group" actually remains on-line? Sounds like it would make my connection hard to use when I'm on-line and give me no guarantees when I'm off-line.
The real working business model is, well, web hosting: you pay someone to keep your content on-line. You get reasonably predictable uptime, bandwidth, and services (PHP, etc.). It's not very expensive, you know. You even get it for free if you accept advertising on your pages.
And the tools to support web hosting and migrate your data are already there: you can use "rsync" to keep your local site in sync with your web hosting service. For really high-end applications, you can replicate the data through a commercial service like Akamai.
That's nice, but it seems like a lot of effort for something that, in many cases, has a much simpler solution: use waste heat for heating. A lot of waste heat could be used for heating homes and water for domestic use, and this is largely untapped in the US. (A lot of low-level waste heat could also be avoided entirely if people gave up on their inefficient water heaters and insulated their pipes.)
It's nice when people come up with better technology, but the inefficient use of energy in the US right now is not a technological problem, it's a political problem. Let's hope that we'll eventually be doing well enough that it will really become a technological problem.
I think, it's better than to lose the ability of binding to pure C (or assembly, or whatever) code.
Well, that may be true if you have grand schemes for the scripting language. But I'd happily give up C compatibility and the C ABI standard for easier, more reliable bindings to native code. Existence of something with a really nice C++ interface and implementation wouldn't obsolete existing scripting languages.
Actually, I was talking about parsing, not readability. But well-written Lisp is very readable, just like well-written C or well-written Java.
LISP, on the other hand, is easily parseable only for those with strange brain defects that make them love spending their days counting parens with bleary eyes.
Lisp, like Python, relies on indentation for readability. People never count parentheses, they use editors that handle parentheses for them. Python programmers don't go blind counting spaces either, they use editors that handle indentation for them.
The primary reason for LISPs lack of success in the real world, IMHO,
Lisp is probably more widely used today than Python or Ruby. It may be unfamiliar, but it is really easy to learn. CommonLisp failed mostly for reasons unrelated to syntax.
the ultimate success of least common denominator languages like Java lies in their parseability to somebody with only general knowledge of the specifics of the applications
Come on: "&&", "?:", and lots of other operators? Lots of braces? Oddball precedence rules? Variable declaration syntax with type modifiers on the variables? Prefix conversion operators with postfix method selectors? Java syntax is pretty tricky and unintuitive; people only consider it simple if they know C.
I also object to your characterization of Java as a "lowest common denominator" language. Java is a very powerful language, hidden under a deceptively familiar syntax.
I like the Python programming language, but I don't particularly like its C implementation and interface. Reference counting in Python is a particular problem, frequently leading to obscure bugs in complex Python extension libraries. Don't even get me started on the Perl C implementation and interface.
Ruby looks a lot better in this regard, and that alone might be a reason to use it, even if otherwise it is roughly equivalent to Python.
Still, overall, it is disappointing to me that there is no Perl/Python/Ruby-like scripting language implemented in C++: using C++, the native code interface could be much simpler to use. Yes, there are various C++ wrappers for Python and probably the other languages, but they generally add a complex C++ layer around an already complex C interface.
3) Dependence on embedded QT license. There is some concern about paying QT for your applications, but on the Sharp forums Sharp says that they are working with QT for low-cost commercial QT licensing.
The concern isn't (just) with the license, it is with the lack of compatibility and interoperability. If you run Qt/Embedded, you can't share the screen with applications written in other toolkits or in raw X11.
Does that matter? I think it does. It places the Sharp outside the family of other Linux-based PDAs and embedded systems, meaning that code for other PDAs can't easily be ported to the Sharp. It also means that workstation applications are much harder to port--even if you change the UI to accomodate a smaller screen, much of the display logic can be shared between desktop and handheld applications.
A cheap Qt/Embedded developer's license just won't help. Sharp needs to provide X11. They can still run their applications using Qt/X11 on it.
You will have to use Qt/Embedded, and you will be using the commercial Lineo distribution. This may be good if you are looking for a slick Linux-based PDA to replace a Palm (although it won't be as small or mature as a Palm), but it isn't as good if you are looking to develop handheld applications for the Linux handheld market, or if you are converting existing Linux software to run on Linux handhelds.
I think an iPaq running Familiar is a better choice for developers and vertical applications (probably the primary market of Linux handhelds).
With the new bootloader, installing Linux on an iPaq should be a breeze, too (no more serial downloads). And you get a full, standard Linux/X11 environment. Compaq even set up some 200MHz ARMs boards as development servers on the web.
Both the military and the civilian parts of the US government design and implement lots of special-purpose gadgets and software, and they spend billions doing it. Often, the work is done by government employees, not contractors. That is entirely justified when there is no commercial vendor around. The decision is no different from whether any other big company outsources or does something in-house. If the FBI wants Magic Lantern, they can develop it in house; they don't need a vendor.
This is a slippery slope. The problem isn't that the government is using a virus, the problem is that they may be seeking accomodation from commercial software. If that thinking prevails, you may eventually not be permitted to run other security software, or you may be required to run an operating system with a back door.
So, the FBI can hack all they want. It is at specifially accomodating that hacking where we need to draw the line.
Networking changes all the time, so it doesn't make much sense to build VoIP or switches into the wall, in particular if they replace sockets that need to be replaced by powerstrips. Keep the power in the wall and VoIP and switches in separate little boxes.
It seems to me like that's the wrong solution. If dialogs are cluttering up the screen, the screen needs to get uncluttered and the dialogs need to get managed. Yes, Gimp dialog are awful.
For flipping images, I think doing that at the level of the windows is both confusing and wrong. What you need is a good image display widget that is widely used and allows such transformations.
OS X is not "PostScript" based; PostScript was tried for window systems 15 years ago and was a miserable failure. The key advantages of OS X graphics are that they use the PostScript/PDF imaging model. But that isn't so unique anymore. Java has roughly the same model (albeit through procedural drawing), and people have built equivalent functionality on top of X11 and GDI.
Transparency in user interfaces is a pretty old idea. The only thing that is "new" about it is that Windows now has it. Using pure transparency by itself can be a bit confusing. But there, too, people have thought of lots of useful additional visual cues: you can blur contents of the window behind the top window, you can desaturate it, and/or you can reduce its intensity range.
Some X11 environments have faked various forms of transparency. Now, X11 supports alpha channels, but I'm not sure whether it actually allows partially transparent windows (does anybody know?). In general, the feature seems to be more eye candy than useful. Transparency is primarily useful for 2D and 3D graphics within an application, not for windows and other user interface components.
No. They are already abundant down here.
on
Mining On The Moon
·
· Score: 1
Aluminum is the third most abundant element by weight in the earth's crust (after oxygen and silicon) and titanium is the 9th most abundant element, between potassium and hydrogen (e.g., here). We really don't need to go to the moon to get these elements.
What makes them costly is extracting and refining them, but that is unlikely to be any cheaper on the moon if it involves space travel and rockets.
It may be an interesting undertaking to resurrect a vertebrate species from DNA, but it isn't really about extinction or reversal of extinction.
It should be sobering to realize that in the time span that this species might be "brought back", many thousands species will likely be going extinct. We could probably save a few of them with the money and media attention expended on this project. Of course, we could save a few of them with the money and attention expended on Harry Potter or Britney Spears.
That's not to say that this project isn't worthwhile. It is scientifically interesting, and it's a challenge. But if we want to do anything about extinctions, we have to start elsewhere: with ecology and conservation. In fact, bringing back a species without bringing back their habitat is only half the job anyway.
I have used the system a little, and found it to be very functional. More than a decade ago, you could already get train and airline schedules, make reservations, buy tickets, go mail-order shopping, and do many other things. All that worked with pretty simple and cheap clients that you just turned on an they worked. I don't know what they did on the server side, but it worked as well. Most of the e-commerce and business ideas you see today on the web were already there (perhaps a good place to dig for prior art to challenge those annoying e-commerce patents).
Re:I need this like I need colonic irrigation
on
Galeon 1.0 Released
·
· Score: 1
Web standards are messy, but no messier than a lot of other standards. The real question is why the software that is rendering them is so extremely bloated.
As TeX shows, it does not take hundreds of megabytes to implement a messy scripting/macro language and some good layout.
What realistic choice do home users have? Microsoft is a monopoly and a monopolist.
In any case, I wonder whether this particular story isn't just a PR campaign. XP hasn't exactly received glowing reviews, and most people have little reason to "upgrade" (I'm writing this from an XP machine, which came with XP preinstalled).
Re:Why aren't there more rendering engines?
on
Galeon 1.0 Released
·
· Score: 1
Well, I'd be happy without those features--just a decent, complete HTML4 renderer.
Still, I don't think even adding JavaScript and DHTML should make the renderer all that big either.
Slashdot Mirror
Well, large amounts of heat (say, from power plants) can be transported reasonably well and are used for heating in many countries around the world. Small amounts of heat from domestic use can be stored and used when they are needed: in most places, you need heat during the night even if it is hot during the day, and you need hot water at any time.
The real working business model is, well, web hosting: you pay someone to keep your content on-line. You get reasonably predictable uptime, bandwidth, and services (PHP, etc.). It's not very expensive, you know. You even get it for free if you accept advertising on your pages.
And the tools to support web hosting and migrate your data are already there: you can use "rsync" to keep your local site in sync with your web hosting service. For really high-end applications, you can replicate the data through a commercial service like Akamai.
It's nice when people come up with better technology, but the inefficient use of energy in the US right now is not a technological problem, it's a political problem. Let's hope that we'll eventually be doing well enough that it will really become a technological problem.
Well, that may be true if you have grand schemes for the scripting language. But I'd happily give up C compatibility and the C ABI standard for easier, more reliable bindings to native code. Existence of something with a really nice C++ interface and implementation wouldn't obsolete existing scripting languages.
Actually, I was talking about parsing, not readability. But well-written Lisp is very readable, just like well-written C or well-written Java.
LISP, on the other hand, is easily parseable only for those with strange brain defects that make them love spending their days counting parens with bleary eyes.
Lisp, like Python, relies on indentation for readability. People never count parentheses, they use editors that handle parentheses for them. Python programmers don't go blind counting spaces either, they use editors that handle indentation for them.
The primary reason for LISPs lack of success in the real world, IMHO,
Lisp is probably more widely used today than Python or Ruby. It may be unfamiliar, but it is really easy to learn. CommonLisp failed mostly for reasons unrelated to syntax.
the ultimate success of least common denominator languages like Java lies in their parseability to somebody with only general knowledge of the specifics of the applications
Come on: "&&", "?:", and lots of other operators? Lots of braces? Oddball precedence rules? Variable declaration syntax with type modifiers on the variables? Prefix conversion operators with postfix method selectors? Java syntax is pretty tricky and unintuitive; people only consider it simple if they know C.
I also object to your characterization of Java as a "lowest common denominator" language. Java is a very powerful language, hidden under a deceptively familiar syntax.
Ruby looks a lot better in this regard, and that alone might be a reason to use it, even if otherwise it is roughly equivalent to Python.
Still, overall, it is disappointing to me that there is no Perl/Python/Ruby-like scripting language implemented in C++: using C++, the native code interface could be much simpler to use. Yes, there are various C++ wrappers for Python and probably the other languages, but they generally add a complex C++ layer around an already complex C interface.
It's hard to get syntax that is "cleaner" than Lisp syntax: Lisp syntax is very easy to parse, very easy to write, and completely unambiguous.
The concern isn't (just) with the license, it is with the lack of compatibility and interoperability. If you run Qt/Embedded, you can't share the screen with applications written in other toolkits or in raw X11.
Does that matter? I think it does. It places the Sharp outside the family of other Linux-based PDAs and embedded systems, meaning that code for other PDAs can't easily be ported to the Sharp. It also means that workstation applications are much harder to port--even if you change the UI to accomodate a smaller screen, much of the display logic can be shared between desktop and handheld applications.
A cheap Qt/Embedded developer's license just won't help. Sharp needs to provide X11. They can still run their applications using Qt/X11 on it.
I think an iPaq running Familiar is a better choice for developers and vertical applications (probably the primary market of Linux handhelds).
With the new bootloader, installing Linux on an iPaq should be a breeze, too (no more serial downloads). And you get a full, standard Linux/X11 environment. Compaq even set up some 200MHz ARMs boards as development servers on the web.
Both the military and the civilian parts of the US government design and implement lots of special-purpose gadgets and software, and they spend billions doing it. Often, the work is done by government employees, not contractors. That is entirely justified when there is no commercial vendor around. The decision is no different from whether any other big company outsources or does something in-house. If the FBI wants Magic Lantern, they can develop it in house; they don't need a vendor.
So, the FBI can hack all they want. It is at specifially accomodating that hacking where we need to draw the line.
I used to use it on my Windows machines and finally gave up on it--technical support was horrible and it caused all sorts of problems.
Networking changes all the time, so it doesn't make much sense to build VoIP or switches into the wall, in particular if they replace sockets that need to be replaced by powerstrips. Keep the power in the wall and VoIP and switches in separate little boxes.
For flipping images, I think doing that at the level of the windows is both confusing and wrong. What you need is a good image display widget that is widely used and allows such transformations.
OS X is not "PostScript" based; PostScript was tried for window systems 15 years ago and was a miserable failure. The key advantages of OS X graphics are that they use the PostScript/PDF imaging model. But that isn't so unique anymore. Java has roughly the same model (albeit through procedural drawing), and people have built equivalent functionality on top of X11 and GDI.
Some X11 environments have faked various forms of transparency. Now, X11 supports alpha channels, but I'm not sure whether it actually allows partially transparent windows (does anybody know?). In general, the feature seems to be more eye candy than useful. Transparency is primarily useful for 2D and 3D graphics within an application, not for windows and other user interface components.
What makes them costly is extracting and refining them, but that is unlikely to be any cheaper on the moon if it involves space travel and rockets.
It would seem like BT doesn't really have a leg to stand on. But we'll have to see how the US legal system views this...
If the Tasmanian tigers will be as healthy as the folks I know from Iceland, I don't think we have to worry about it.
Besides, once you are into the cloning business, you can introduce genetic variation and put in bits and pieces from other, related species.
I think that was among the least of Jurassic Park's problem, either from the point of view of biology or from the point of view of cinematography.
It should be sobering to realize that in the time span that this species might be "brought back", many thousands species will likely be going extinct. We could probably save a few of them with the money and media attention expended on this project. Of course, we could save a few of them with the money and attention expended on Harry Potter or Britney Spears.
That's not to say that this project isn't worthwhile. It is scientifically interesting, and it's a challenge. But if we want to do anything about extinctions, we have to start elsewhere: with ecology and conservation. In fact, bringing back a species without bringing back their habitat is only half the job anyway.
I have used the system a little, and found it to be very functional. More than a decade ago, you could already get train and airline schedules, make reservations, buy tickets, go mail-order shopping, and do many other things. All that worked with pretty simple and cheap clients that you just turned on an they worked. I don't know what they did on the server side, but it worked as well. Most of the e-commerce and business ideas you see today on the web were already there (perhaps a good place to dig for prior art to challenge those annoying e-commerce patents).
As TeX shows, it does not take hundreds of megabytes to implement a messy scripting/macro language and some good layout.
As for JWZ, I mean, they guy hates the design of his own brain. I'd like to see a system he doesn't dislike.
In any case, I wonder whether this particular story isn't just a PR campaign. XP hasn't exactly received glowing reviews, and most people have little reason to "upgrade" (I'm writing this from an XP machine, which came with XP preinstalled).
Still, I don't think even adding JavaScript and DHTML should make the renderer all that big either.