and its own ballot colour. That is what we do in Denmark. Of course wandering between rooms could get tedious, so it would probably not work for more than 4 or 5 elections. Is that common?
DC doesn't lose more than AC; in fact just the opposite. However, 12V does of course lose more than 110V. 12V is probably not enough for a useful circuit through the house; anything more than say 20A breakers would be too dangerous and that only gives you 240W. 24V or 48V would probably be better -- you could use cheap and efficient DC-DC "transformers" to get 4/6/9/12V according to what each appliance needs.
The amount of packets that can be routed in backbone routers these days is really huge. The Juniper T640 is specced for 770Mpps. Forwarding rate is not really a problem. Particularly because each packet forwarded can be billed. Multicast on the other hand just slows your routers down whether you actually get to forward packets or not -- and there is no easy way to bill that cost to anyone. So no, there is little interest in decreasing the amount of bandwidth used. Bandwidth is cheap and plentiful.
Anyway, if you want to send 5Mbps streams to someone, you have basically lost before you start. Almost noone has that kind of download bandwidth. And those who do generally have a shared bottleneck on the ISP side of the connection. Streaming video will work fine (with multicast) as long as you can get all the subscribers to agree on which stream they want to watch...
In the end, I bet that at the time when 10Mbps download bandwidth becomes common, decent upload bandwidth will be common as well. We are 5 years away from that point, at least.
I don't see the inefficiency. I have no problems imagining a working real-time video streaming P2P application. Skype seems to work just fine, although that is admittedly only sound so far. You need decent upload bandwidth from the hosts, and that may be a problem. However upgrading the last mile to 512kbps upload seems a lot simpler to me than upgrading the core routers to handle 100 million multicast groups -- particularly because I have no idea how you would build hardware to handle that. Core routers are already strained by the few hundred thousand unicast prefixes. Multicast would require magnitudes of performance improvement.
Show me a router which can handle, say, 100 million multicast groups, and I'll agree that the problem with multicast is merely political. I'll be impressed if you can. Peer to peer is the solution -- it puts the complexity in the hosts, not in the routers.
Printer drivers are fundamentally hard. Printers are complicated devices. They connect using a gazillion interfaces. The same model comes in many varieties. They can be configured with many paper types and sizes, and they are rarely able to tell the computer how they are configured.
They should, of course, just pop up and work. Everyone realizes that. The current interface is not an attempt to be nasty to the user, and it is not the result of ignorance. It is simply a reflection of the fact that printing is hard.
Now that it has been decided how applications should get printer capabilities (by looking at PPDs), the user experience should get better. In combination with automatic printer detection and IPP, you can expect things to be much better in a year. Basically the missing link is upgrading all applications to use the new interfaces.
The big problem is that SQL is much like COBOL. COBOL can do everything that other imperative langauges can do, and some things are even easy (printing fixed-length fields, for one). However, that does not mean that COBOL is a particularly good language. Fortunately, any decent programmer can make a good attempt at a new imperative language, including making a compiler or interpreter for it. Therefore we got further than COBOL.
The same decent programmer would be hard pressed to implement a database system with a new query language. This is simply not something you whip up in your spare time. So we are stuck with a million dialects of SQL.
Recursing through a classic SQL tree with parent-"pointers" is ghastly slow. It gets slightly less slow if you use a stored procedure, but if you do that you have confined yourself to one database vendor. (So much for SQL being a standard.)
With "modified preorder tree traversal" you can do the whole recursive query, whether up or down, in one non-recursive SQL statement. Very neat, but it is a pain to implement and you better be careful about the atomicity of updates. So far I have not found a way to avoid locking the whole table for writes for some operations, even with databases which do proper transactions. The same algorithm could be implemented cheaply and with more fine-grained locking in the database itself.
There is no national or continental weather service in Europe
This must definitely depend on which nation in Europe you talk about. In Denmark, DMI provides specialized weather reports and forecasts for aviation, shipping, and farming. DMI is a national institution and many of its services are free.
It would be pretty hard to save people stuck above the breaking point. Not impossible maybe, but pretty hard. Either way, concern about a remote possibility of damage to shipping seems rather silly when current methods of getting people into space kill so (relatively) many.
When you save in non-native formats you lose a little formatting and some structure information. It's not that bad, but it can be annoying. It's better to keep the OpenOffice.org file around for later editing, if possible.
Some years ago there was an article about how gates in new dykes in the Netherlands were fully automated, since it was calculated that the risk of human error was about a thousand time higher than the risk of computer malfunction. So no emergency override.
Power electronics have pretty much solved the fluctuation problem. Ten years ago the light would blink a little when windmills started, but that practically doesn't happen anymore. Also, the power electronics which are necessary for wind farms can be used to provide reactive power when the wind farm isn't at full load. Lack of reactive power was a contributor to the last major blackout in the US.
Cheap IDE drives and massive oversubscription. Backing up to tape is so last millenium, anyway. By the way, you can probably give each server quad 250GB IDE for the price of just the fibre channel controller. SAN has to be massively easier to administer (or massively faster, good luck with that) in order to make sense.
First is the obvious that if you can never emulate something the same speed that it would be if it was native. It will always be at least a hair slower.
This is not necessarily true. HP has a dynamic HPPA interpreter which runs about 20% faster than native on most programs tested. Of course it has the advantage of being able to cheaply fall back to native code when the JIT isn't having much luck. The technology is now being used to move programs made for HPPA to Itanium, ideally running them at the same or better speed compared to recompiled programs.
Re:Dismally Realistic Science
on
Out of Gas
·
· Score: 1
Even the cheapest solar cells are vastly more efficient at producing useful (to industry) energy than plants. The problem is that they are vastly more expensive than plants. If we can get solar cells with 5% efficiency produced as cheaply as farming the same area, all talk about bioethanol or biodiesel will stop.
Re:Personal Transport on the Grid
on
Out of Gas
·
· Score: 1
I suppose one thing you could do is energize the freeways and major thouroughfares, and then let the cars rely on internal batteries for the last mile or so...
The RUF is a city car that can run on electric monorail at high speeds. Its primary advantage is traffic density -- cars can run bumper-to-bumper at 100MPH+ on a track small enough to fit in the center of most highways -- but the ability to run on electrical power provided by the rail is pretty neat too. The downside is the initial investment in the rail.
The fact that you haven't heard of it doesn't imply that it doesn't exist. Seasonal blends of gas do exist. In the summer you want a blend that evaporates less. In winter you can add lighter stuff like ethanol without getting too much evaporation.
Petroleum does not have to be a "fossil fuel", in the sense of coming from fossils. It can be synthesized. A fact that we will probably be grateful for eventually.
You are wrong about Northern Europe and even Scandinavia. In Denmark all mileage is reported in km/l. I really can't see any reason to switch to the reciprocal times 100. Why 100? And why pick something that gets you worse mileage with larger numbers?
Slashdot Mirror
and its own ballot colour. That is what we do in Denmark. Of course wandering between rooms could get tedious, so it would probably not work for more than 4 or 5 elections. Is that common?
DC doesn't lose more than AC; in fact just the opposite. However, 12V does of course lose more than 110V. 12V is probably not enough for a useful circuit through the house; anything more than say 20A breakers would be too dangerous and that only gives you 240W. 24V or 48V would probably be better -- you could use cheap and efficient DC-DC "transformers" to get 4/6/9/12V according to what each appliance needs.
Anyway, if you want to send 5Mbps streams to someone, you have basically lost before you start. Almost noone has that kind of download bandwidth. And those who do generally have a shared bottleneck on the ISP side of the connection. Streaming video will work fine (with multicast) as long as you can get all the subscribers to agree on which stream they want to watch...
In the end, I bet that at the time when 10Mbps download bandwidth becomes common, decent upload bandwidth will be common as well. We are 5 years away from that point, at least.
I don't see the inefficiency. I have no problems imagining a working real-time video streaming P2P application. Skype seems to work just fine, although that is admittedly only sound so far. You need decent upload bandwidth from the hosts, and that may be a problem. However upgrading the last mile to 512kbps upload seems a lot simpler to me than upgrading the core routers to handle 100 million multicast groups -- particularly because I have no idea how you would build hardware to handle that. Core routers are already strained by the few hundred thousand unicast prefixes. Multicast would require magnitudes of performance improvement.
Show me a router which can handle, say, 100 million multicast groups, and I'll agree that the problem with multicast is merely political. I'll be impressed if you can. Peer to peer is the solution -- it puts the complexity in the hosts, not in the routers.
They should, of course, just pop up and work. Everyone realizes that. The current interface is not an attempt to be nasty to the user, and it is not the result of ignorance. It is simply a reflection of the fact that printing is hard.
Now that it has been decided how applications should get printer capabilities (by looking at PPDs), the user experience should get better. In combination with automatic printer detection and IPP, you can expect things to be much better in a year. Basically the missing link is upgrading all applications to use the new interfaces.
The same decent programmer would be hard pressed to implement a database system with a new query language. This is simply not something you whip up in your spare time. So we are stuck with a million dialects of SQL.
With "modified preorder tree traversal" you can do the whole recursive query, whether up or down, in one non-recursive SQL statement. Very neat, but it is a pain to implement and you better be careful about the atomicity of updates. So far I have not found a way to avoid locking the whole table for writes for some operations, even with databases which do proper transactions. The same algorithm could be implemented cheaply and with more fine-grained locking in the database itself.
This must definitely depend on which nation in Europe you talk about. In Denmark, DMI provides specialized weather reports and forecasts for aviation, shipping, and farming. DMI is a national institution and many of its services are free.
It would be pretty hard to save people stuck above the breaking point. Not impossible maybe, but pretty hard. Either way, concern about a remote possibility of damage to shipping seems rather silly when current methods of getting people into space kill so (relatively) many.
When you save in non-native formats you lose a little formatting and some structure information. It's not that bad, but it can be annoying. It's better to keep the OpenOffice.org file around for later editing, if possible.
Ok, the cable broke, killing everyone on board the elevator climbers. And you're worried that a ship might lose a propeller. Right.
LCDs don't refresh. 10Hz would be a fine refresh for them, except graphics wouldn't move smoothly.
Some years ago there was an article about how gates in new dykes in the Netherlands were fully automated, since it was calculated that the risk of human error was about a thousand time higher than the risk of computer malfunction. So no emergency override.
Power electronics have pretty much solved the fluctuation problem. Ten years ago the light would blink a little when windmills started, but that practically doesn't happen anymore. Also, the power electronics which are necessary for wind farms can be used to provide reactive power when the wind farm isn't at full load. Lack of reactive power was a contributor to the last major blackout in the US.
Cheap IDE drives and massive oversubscription. Backing up to tape is so last millenium, anyway. By the way, you can probably give each server quad 250GB IDE for the price of just the fibre channel controller. SAN has to be massively easier to administer (or massively faster, good luck with that) in order to make sense.
This is not necessarily true. HP has a dynamic HPPA interpreter which runs about 20% faster than native on most programs tested. Of course it has the advantage of being able to cheaply fall back to native code when the JIT isn't having much luck. The technology is now being used to move programs made for HPPA to Itanium, ideally running them at the same or better speed compared to recompiled programs.
Even the cheapest solar cells are vastly more efficient at producing useful (to industry) energy than plants. The problem is that they are vastly more expensive than plants. If we can get solar cells with 5% efficiency produced as cheaply as farming the same area, all talk about bioethanol or biodiesel will stop.
The RUF is a city car that can run on electric monorail at high speeds. Its primary advantage is traffic density -- cars can run bumper-to-bumper at 100MPH+ on a track small enough to fit in the center of most highways -- but the ability to run on electrical power provided by the rail is pretty neat too. The downside is the initial investment in the rail.
Adding ethanol in small amounts is actually very beneficial. Ethanol raises octane without the nasty environmental impact of additives like MTBE.
The fact that you haven't heard of it doesn't imply that it doesn't exist. Seasonal blends of gas do exist. In the summer you want a blend that evaporates less. In winter you can add lighter stuff like ethanol without getting too much evaporation.
Petroleum does not have to be a "fossil fuel", in the sense of coming from fossils. It can be synthesized. A fact that we will probably be grateful for eventually.
Toyota Yaris, last time I had a mileage counter. It could do mpg as well.
In general I don't have to do it in my head, I just go to the menu and switch the appropriate setting.
You are wrong about Northern Europe and even Scandinavia. In Denmark all mileage is reported in km/l. I really can't see any reason to switch to the reciprocal times 100. Why 100? And why pick something that gets you worse mileage with larger numbers?