I believe that if you call bash with the name sh (as all the system scripts will) it runs in sh-compatibility mode. I don't think that changes a lot, and I don't know if it removes features that are strictly a superset of sh's features, but it does make some difference.
GGI isn't actually a hardware interface. It's a userspace library that abstracts the hardware some (similar to Xlib in some ways). It can run ontop of several different actual display devices -- KGI (primarily Linux -- though I heard that FreeBSD was considering using it more mainstream), X, or framebuffer.
I think you use a different library -- dynamically linked -- depending on what the display is, so that GGI should be fairly lightweight when most of its features exist on the target display, i.e., it reduces GGI calls to Xlib calls when as possible, and with KGI it passes as much on to the graphics card as possible. I guess this is similar to Open GL.
The framebuffer doesn't do this sort of optimization much, and I don't think it can do much of it because it has an interface that is more primitive than the actual device (graphics card) that it displays on. At least, this is what I understand. GGI on the framebuffer is very slow -- but probably just like GTK on the framebuffer will be fairly slow.
it doesn't work because focus doesn't seem to shift after the second keystroke
I've noticed the same problems all over the place in Gnome -- the shortcuts are useless when focus wanders from place to place in unpredictable and usually unhelpful ways. And then shortcuts work only when focus is in the right place. It's very frustrating, and seems like it shouldn't be such a big deal to do right.
There are a ton of languages that are better than Python in every way a language can be. It's a shame, really -- so many good ideas, so little actual success. Python just made the right compromises, and managed to stay in existance for those first painful years of seemingly pointless development. Dylan was a research effort, and like many research efforts the implementors didn't really have the will to make it succede.
Now that Python exists, it may be hard for even those with will -- Ruby and Rebol, for example -- to succede. There was a niche for Python to fill, something that Perl and Tcl didn't quite cover. Tcl is gone, is there enough of a gap in what Perl and Python achieve that there's room enough for another language? I'm not sure. No new language is going to supplant an old language -- at least, not until it has gained a significant following on its own.
How do you come to this conclusion? A BSD license seems nearly certain to me, which is more or less what Python has always had except for some minor (though not insignificant) provisions that Guido's employer added (Center for National Research Initiatives...?) It seems like it's only a question of managing some politics at this point, which seems fairly certain to work out.
This is from Smalltalk, which predates Eiffel by a long long time. I think Smalltalk like we know it today is from the period of 1976-78 or so, distilled more formally around 1980. I believe in Smalltalk it looks like 5 timesRepeat: [do this], the for loop looks like 1 to: 10 do: [:i | block] which seems similar to Ruby as well. I think some of the idea of simple closures instead of functions as objects came from Logo. I.e., you don't pass functions around, you pass closures -- Smalltalk has no concept of functions, only methods, so this was the solution. Logo did it this way just because it was most intuitive.
Python isn't formally defined, but it isn't defined by its implementation. There are multiple implementations that seem to keep in sync fairly well. The default implementation (CPython) is also widely available, and it's easy to make portable programs based on it. Also, enhancements to the language are taken quite seriously. The PEP process (writing formal descriptions of all proposed changes) keeps the advancement of the language both more conservative and formal. Standardization is mostly for cases when proprietary implementors want to make their implementations interoperate (e.g., ANSI C, Common Lisp, JavaScript/ECMAScript, etc). Standardization has little to offer Python.
As far as new versions breaking old programs, I haven't seen the problem. Python v2 adds a number of things, but hasn't really broken anything. There are plans to deprecate old features, but these are mostly in cases where old features were found to encourage or enable bad programming practices or the behavior is unintuitive, and where it's not hard to fix the program. Even so, there are plans to put in warning features and ways to run the interpreter in backwards-compatible modes. These should come to fruition before serious backwards-incompatible changes are made.
Well, what I like about Python is that it is both simple, but also explicit. So, for instance, when you want to factor your program into modules, you just put the respective function definitions in the various files and import them. When you import a file, all the definitions in that file are available. There's no real way to hide things (though, by convention, you shouldn't access variables that start with _), there's nothing you need to declare at the beginning of the module, so there's no overhead to factoring correctly. Creating classes is also similarly simple, encouraging good factoring.
I also like the fact that you can look at a small bit of Python code out of context and figure a lot out about it. There are seldom hidden side effects (not necessarily by language design, but mostly by accepted convention and style). You can trace all the functions -- there are a handfull of top-level builtin functions, and everything else is modules or methods. Because Python encourages being explicit about modules (e.g., using string.join, where join comes from the string module), it's easy to figure out where everything is defined.
Those are a couple of the things that I think make Python easy to read and easy to maintain.
But most of all, I like Python because I can do what I want to consistently and efficiently. There aren't any surprises. I feel like Perl has an emphasis on being a language that can do eclectic things. But I don't want my language to do eclectic things, I want to do eclectic things with my language. A language should be a reliable and predictable way to express my intention. If I understand the language fairly completely (and it doesn't have horrible deficiencies, like Tcl for instance), I can do what I want. I could never understand Perl enough to work with it without surprises.
Without ever hacking on Python internals, I feel like I understand the language pretty completely.
I must admit that I too have not found Zope to be as good as I would have hoped. The documentation seems to have improved considerably since I last seriously worked with it (about a year ago) -- at that time the documentation was poor, incomplete, and often inaccurate. That's a huge problem for something like Zope, which is a piece of infrastructure. It's fine if AbiWord, for instance, doesn't have good documentation -- a little experimentation will expose everything you need to know -- but that doesn't work with something like Zope. That said, the documentation seems to have improved considerably.
However, I still don't like Zope much, even though I really want to like Zope. It doesn't have the things I so love about Python -- simplicity, consistency, and a small set of orthogonal features which interact well together. DTML and Zope in general seem to have some sort of funny dynamic scoping to them, and the mapping from URL to object database to the python object model isn't intuitive to me. When you do something new in Zope, there's a very good chance it won't work the first time. That's not true of Python, in my experience.
For these reasons, I've been looking more closely at Webware, which seems to have a much less ambitious goal, and thus much more chance of success.
People have been talking about how Zope will be a killer application for a while now. Maybe it will happen, I very possibly may be converted myself, but I don't think it will necessarily happen. It would be very easy for Digital Creations to lose sight of the goal by incrementally adding features they need without rethinking what they've already done. Down that path leads Perl, and I know I sure don't want to go there.
This is exactly the sort of thing that is done in Computer Science research. You usually wouldn't study a particular OS but you'd certainly study the design and theory of OS's.
Study and research are very different things. Study is what you do as a student, not as a researcher. It's like in a physics class when you do experiments confirming Newtons equations. That's study, but it sure isn't research.
Pure physics and chemistry not empirical at all.
Quite the contrary. If it's connected to reality, it's empirical. Theories that have nothing to do with reality have no part in physics or chemistry. That's math. Would a chemist -- even a "pure" chemist -- care about something without a connection to reality? They postulate lots of things that are new and novel -- but only novel insofar as they describe the world in a different way. They are never really interested in postulating about imaginary worlds. Mathematicians, on the other hand, love to do that. Heck, that's practically all they do anymore.
Computer scientists are somewhere in the middle, I suppose. They imagine alternate worlds and novel systems, but then they make that concerete through implementation. Then they study some of how those implementations work. But there's very little to study that simple exists as is the case with the empirical sciences.
We apply the principles, but don't discover them, in general.
Computer scientists don't really discover principles either, because computer science isn't a science -- it's more of a philosophy, like mathematics.
No one explores an operating system, looking for the intrinsic principles which dictate its behavior. They don't create systems to describe the way computer chips work. And when they are done, they don't formulate ways to confirm their hypothesis through experimentation.
They already know how the operating system works, and why -- because someone made it work that way, just like the hardware. It isn't physics or chemistry, it is not an empirical science and has little relation to those fields.
Computer scientists try to work out how we should do things, not how things are. That's exactly the same sorts of decisions that any thoughtful programmer is doing every day on the job. The programmer just has a narrower focus.
Re:Interesting you should mention PRT
on
Fiddler on the RUF
·
· Score: 2
But RUF has none of the beautiful minimalism that PRT has. PRT (done right) is all about making things as small and efficient as possible. The cars are as simple as possible, as small as is socially appropriate, and as light as possible. They don't have to worry about being away from a power source, they don't have to worry about shocks or poor road conditions, they don't have to worry about maintenence (which would be centralized and very consistent)... all of this means that PRT vehicles can be expected to act very consistently and you don't have to allow for the tremendous amount of error that would be present in a dual-mode system.
The biggest reasons to like PRT are lost on something like RUF. Efficiency, price, and consistency are too important and central to PRT for it to work without. PRT would be great when there's a station less than a half mile from anywhere I want to go. You could never do that with RUF. It would be an elevated rail you could ride your car on. Elevated rails suck (at least from my experience), and they are horribly expensive.
MacOS has the most consistent way of doing things (specifically for downloaded files), but they all handle it.
Maybe MacOS has been fixed since I last used it seriously, but as I remember it was really awful at this. It didn't really understand the idea of an abstract type, only types directly attached to applications. When you passed an file that was of a normal type (like HTML or Postscript or something), it would try to open it with whatever created the document. Often this application didn't exist on the computer, though there was an application that could handle the filetype. I had to go in with regedit or whatever it was and fix several files because of this.
Maybe since then Mac has figured out MIME types (or a functional equivalent) and the concept that data is often (should generally be) seperate from the application that created it. It's more decentralized as Mac did it -- any application is entirely free to create new types as it wishes, and it is implicitly registered to handle the type -- but I like centralization sometimes. And application/x-whatever works fine anyway.
Batteries have come a long, long way in the last while
My impression has been that they haven't come very far in the realm of high-capacity batteries like a car would need, though perhaps I've missed recent changes. Batteries are already a significant part of the cost of an electric car, and that's using batteries like normal car batteries, I thought.
Other forms of batteries tend to be considerably more expensive, aren't they? I'm very reluctant to say that things should be more expensive because it's good for the environment -- when you take in the larger picture, it's often not true. If those batteries are quite expensive -- as all the better batteries seem to be -- it's very probably because there's a lot of resources going into their creation. A lot of water used, mining required, etc. None of those things are good for the environment.
I think the transportation problem really needs to be looked at as an infrastructure problem, not a car problem. The best solution will not only be good and environmentally sound, but cheap too. And I don't even think it needs to be high-tech.
The fact is, there will be LESS polution generated at the power plants. Besides being more efficient at converting fuels to power, not every power plant is poluting.
There's a lot of inefficiencies that electric cars have to deal with -- transporting electricity, and the very difficult matter of storing electricity. Transporting and storing energy stored in petroleum is much easier and more efficient than electricity.
But even with that aside, electric cars themselves create quite a lot of polution. Electric cars are filled with batteries which contain highly toxic and dangerous pollutants (heavy metals). These batteries have to be replaced every 2-3 years, and are also prone to leak (significant even for small leaks). My understanding is that the single battery in current cars causes significant pollution already.
I would be very interested to see an impartial and complete rundown of the environmental impact of electric vs. gasoline cars. (Combined with stats on buses, trains, hybrids, bicycles, and other transportations would be even more interesting) Mostly I've just seen highly partial statistics, and statistics in regards to pollution seem particularly easily manipulated. Very possibly electric cars could be the most environmentally safe, but I'm not convinced of that yet.
So it seems a bit ironic that Derek's xpdf is getting slammed for making the design decision to honor the author's copy and print restrictions
I don't think anyone has been slamming xpdf -- a few people have just asked themselves whether Derek's design decisions reflect the priorities of Debian, and if Debian should change that decision for its own version of the software.
If software is running on remote servers, then even if it is covered by an open
source licence, in many cases, the people running the severs will not be distributing
binaries, so won?t be required to provided source code for any changes they make.
Capacity - These personal rail car concepts tend to fail when it comes to extremely
dense corridors. As you can imagine, heavy rail can push many more people through a
single rail corridor than this sort of technology. Right now you can push about 2K
cars/lane/hour, compared to densities of nearly 10K for heavy rail systems. With this
technology, you could decrease headways and maybe squeeze another few K through
I think the heavy corridors are more a symptom of the what's wrong with current transportation infrastructures, not a good representation of how people move about the city.
Right now people drive ten minutes to get to the highway, ten minutes to get off of it. And there's these giant corridors that get bigger and bigger, the merging gets more complicated, the roads up the the highways get bigger.
I think a more decentralized system is much more efficient. If population grows and spreads out, it's not so much of a problem if the transportation system similarly spreads. There would be a hundred ways to get from one place to another, and the system wouldn't have the scalability problems that highways have -- extra lanes aren't worth much.
Now, there's a problem with this -- this is how most transportations systems work inside cities. And it's slow. Because there's another scaling problem -- all those smaller roads intersect with each other, and you spend all your time waiting for lights. This is where an automated system could be so much more efficient than roads. Every intersection is simply a merge.
Heavy rail isn't so great either. If the stops aren't close to each other, few people will be able to walk to a rail stop. So you still have all the road problems, you've just replaced the heaviest corridor with a rail. If the stops are close to each other, the rail is very slow.
Right now there's a project in Chicago to replace some 9 miles of elevated rail for $350 million. That's insane. It's stupid. Part of it is because they can't actually shut anything down because there's no redundancy in the system. And the train will still be slow when they are finished.
RUF seems rather awkward, and I'm not sure what it would provide. But the basic idea of automated individual vehicles seems quite practical to me (PRT being a much more practical implementation).
They want hotmail, MSN
Messenger and AOL/Time Warner telling them what to watch and read.
You do normal people a disservice. Many of them are parents and grandparents who want to keep in contact with far-flung children, or kids passing gossip, or conspiracy-theorist wannabes, insomiacs, perverts, expatriots, illicit lovers, closeted lovers, social awkard lovers, game addicts, and sometimes even totally well-adjusted individuals who sometimes want to know something.
People who believe the masses are all idiots are judging with very narrow criteria, and don't seem to appreciate that people in fact spend a good deal of their lives living their lives. Unlike us, some of them even have lives. They deserve some credit for it.
Sure, there's the risk of squatting, but IMO, the internet should stay a free,
wild environment, rather than becoming another corporate sponsored and controlled
media outlet.
Unfortunately free and wild isn't so hot either. There's a ton of registered domains that aren't in use -- bought up in order to keep someone else from using the domain. Like, say, georgebushsucks.com, which is bizzarly a live name that points to the Bush site. That's a waste of a perfectly good -- an entirely legitimate -- name.
There's a power struggle. When everything is wild, the masses have a certain power in numbers. But the corporations have great monetary resources, if not creativity, and they manipulate the system too. Moving to law (like trademarks) certainly gives them an advantage, because they can be more effective thugs. But thugs exist in a wild system too. They don't exist in a just system, and that's what we haven't quite achieved (though, heck, it could be a lot worse).
It depends on the efficiency of the devices. A lightbulb isn't designed to radiate infrared
energy, its designed to radiate energy in the visible light spectrum.
This isn't really accurate. It does matter that a BTU of electric energy is more expensive than, say, natural gas. However, this wasn't your objection.
Creating heat is the one place where efficiency doesn't matter much at all. Second law of thermodynamics -- energy is neither created nor destroyed. The energy in light ultimately ends up as heat -- the light rays bounce off of surfaces, each time becoming dimmer and slightly heating the surfaces.
There might be a certain inefficiency to this -- maybe the surfaces aren't what needs to be heated, and while some of the heat of the walls goes to the air, some goes through the wall and outside. But I doubt that really matters much.
If you are burning fuel, efficiency does matter. You have to burn the fuel completely, and you want to lose as little heat as possible through exaust. But for electricity it's not really an issue -- all those efficiency issues have been taken care of at the power plant, and the electical energy is pretty much guaranteed to become heat in the end.
First, the whole point of censorware is that you can't get around it.
Not entirely. Part of the point is to keep people from accidentally going somewhere they didn't want to. There are a considerable number of pornographic sites which portray themselves as something else (through spam, misspellings, etc).
Apart from the
philosophical absurdity, censorware can never work on an open-source operating system
without stringent physical controls as well.
Of course it can -- it's terribly easy, really. All you have to do is put the censorware on the firewall. Sure, the firewall has to be physically secured, but that was already true.
If you want to make up a blacklist of sites which don't want to be blacklisted, you have a
fight on your hands.
There is potentially someplace inbetween -- making a blacklist of sites that people didn't want to go to, but found themselves at anyway. When I was supervising a very small lab with junior high kids, every so often someone would end up at a porn site or something otherwise inappropriate. The kids didn't want to go there -- at least not in a public lab. If it was easy to block that site at that time, the sites that were actually problematic would get added.
Every obscure pornographic site doesn't have to be included -- just the ones that matter. I think we could take a lot of the winds out of the sails of pro-censorship people if just the fraudulent sites could be blocked. Sure, if someone wanted to see porn they still could, because a large portion of the porn wouldn't be blocked. They get what they asked for, and I don't think that's a big deal.
Some human being has to categorize them, or you'll be no more
accurate than the existing closed-source blacklists
This is a significant problem. Right now there are fundamentalist who deface library books because they are opposed to the books. It would be easy to abuse a volunteer-based system similarly.
Part of what would help, I think, is the openness of the system. It should be just as easy to submit a complaint about a blocked website as it is to block a website, and it should be easy to figure out where your website stands without participating in any blocking yourself. If this was combined with a reputation system for the sugggesting moderators, then the worse abusers could be isolated.
First, Hong Kong isn't a country. Second, both Singaport and Japan have been extremely protectionist, with significant government influence in the economy.
Slashdot Mirror
I believe that if you call bash with the name sh (as all the system scripts will) it runs in sh-compatibility mode. I don't think that changes a lot, and I don't know if it removes features that are strictly a superset of sh's features, but it does make some difference.
I think you use a different library -- dynamically linked -- depending on what the display is, so that GGI should be fairly lightweight when most of its features exist on the target display, i.e., it reduces GGI calls to Xlib calls when as possible, and with KGI it passes as much on to the graphics card as possible. I guess this is similar to Open GL.
The framebuffer doesn't do this sort of optimization much, and I don't think it can do much of it because it has an interface that is more primitive than the actual device (graphics card) that it displays on. At least, this is what I understand. GGI on the framebuffer is very slow -- but probably just like GTK on the framebuffer will be fairly slow.
Now that Python exists, it may be hard for even those with will -- Ruby and Rebol, for example -- to succede. There was a niche for Python to fill, something that Perl and Tcl didn't quite cover. Tcl is gone, is there enough of a gap in what Perl and Python achieve that there's room enough for another language? I'm not sure. No new language is going to supplant an old language -- at least, not until it has gained a significant following on its own.
How do you come to this conclusion? A BSD license seems nearly certain to me, which is more or less what Python has always had except for some minor (though not insignificant) provisions that Guido's employer added (Center for National Research Initiatives...?) It seems like it's only a question of managing some politics at this point, which seems fairly certain to work out.
This is from Smalltalk, which predates Eiffel by a long long time. I think Smalltalk like we know it today is from the period of 1976-78 or so, distilled more formally around 1980. I believe in Smalltalk it looks like 5 timesRepeat: [do this], the for loop looks like 1 to: 10 do: [ :i | block] which seems similar to Ruby as well. I think some of the idea of simple closures instead of functions as objects came from Logo. I.e., you don't pass functions around, you pass closures -- Smalltalk has no concept of functions, only methods, so this was the solution. Logo did it this way just because it was most intuitive.
As far as new versions breaking old programs, I haven't seen the problem. Python v2 adds a number of things, but hasn't really broken anything. There are plans to deprecate old features, but these are mostly in cases where old features were found to encourage or enable bad programming practices or the behavior is unintuitive, and where it's not hard to fix the program. Even so, there are plans to put in warning features and ways to run the interpreter in backwards-compatible modes. These should come to fruition before serious backwards-incompatible changes are made.
I also like the fact that you can look at a small bit of Python code out of context and figure a lot out about it. There are seldom hidden side effects (not necessarily by language design, but mostly by accepted convention and style). You can trace all the functions -- there are a handfull of top-level builtin functions, and everything else is modules or methods. Because Python encourages being explicit about modules (e.g., using string.join, where join comes from the string module), it's easy to figure out where everything is defined.
Those are a couple of the things that I think make Python easy to read and easy to maintain.
But most of all, I like Python because I can do what I want to consistently and efficiently. There aren't any surprises. I feel like Perl has an emphasis on being a language that can do eclectic things. But I don't want my language to do eclectic things, I want to do eclectic things with my language. A language should be a reliable and predictable way to express my intention. If I understand the language fairly completely (and it doesn't have horrible deficiencies, like Tcl for instance), I can do what I want. I could never understand Perl enough to work with it without surprises. Without ever hacking on Python internals, I feel like I understand the language pretty completely.
However, I still don't like Zope much, even though I really want to like Zope. It doesn't have the things I so love about Python -- simplicity, consistency, and a small set of orthogonal features which interact well together. DTML and Zope in general seem to have some sort of funny dynamic scoping to them, and the mapping from URL to object database to the python object model isn't intuitive to me. When you do something new in Zope, there's a very good chance it won't work the first time. That's not true of Python, in my experience.
For these reasons, I've been looking more closely at Webware, which seems to have a much less ambitious goal, and thus much more chance of success.
People have been talking about how Zope will be a killer application for a while now. Maybe it will happen, I very possibly may be converted myself, but I don't think it will necessarily happen. It would be very easy for Digital Creations to lose sight of the goal by incrementally adding features they need without rethinking what they've already done. Down that path leads Perl, and I know I sure don't want to go there.
Computer scientists are somewhere in the middle, I suppose. They imagine alternate worlds and novel systems, but then they make that concerete through implementation. Then they study some of how those implementations work. But there's very little to study that simple exists as is the case with the empirical sciences.
No one explores an operating system, looking for the intrinsic principles which dictate its behavior. They don't create systems to describe the way computer chips work. And when they are done, they don't formulate ways to confirm their hypothesis through experimentation.
They already know how the operating system works, and why -- because someone made it work that way, just like the hardware. It isn't physics or chemistry, it is not an empirical science and has little relation to those fields.
Computer scientists try to work out how we should do things, not how things are. That's exactly the same sorts of decisions that any thoughtful programmer is doing every day on the job. The programmer just has a narrower focus.
The biggest reasons to like PRT are lost on something like RUF. Efficiency, price, and consistency are too important and central to PRT for it to work without. PRT would be great when there's a station less than a half mile from anywhere I want to go. You could never do that with RUF. It would be an elevated rail you could ride your car on. Elevated rails suck (at least from my experience), and they are horribly expensive.
Maybe since then Mac has figured out MIME types (or a functional equivalent) and the concept that data is often (should generally be) seperate from the application that created it. It's more decentralized as Mac did it -- any application is entirely free to create new types as it wishes, and it is implicitly registered to handle the type -- but I like centralization sometimes. And application/x-whatever works fine anyway.
Other forms of batteries tend to be considerably more expensive, aren't they? I'm very reluctant to say that things should be more expensive because it's good for the environment -- when you take in the larger picture, it's often not true. If those batteries are quite expensive -- as all the better batteries seem to be -- it's very probably because there's a lot of resources going into their creation. A lot of water used, mining required, etc. None of those things are good for the environment.
I think the transportation problem really needs to be looked at as an infrastructure problem, not a car problem. The best solution will not only be good and environmentally sound, but cheap too. And I don't even think it needs to be high-tech.
But even with that aside, electric cars themselves create quite a lot of polution. Electric cars are filled with batteries which contain highly toxic and dangerous pollutants (heavy metals). These batteries have to be replaced every 2-3 years, and are also prone to leak (significant even for small leaks). My understanding is that the single battery in current cars causes significant pollution already.
I would be very interested to see an impartial and complete rundown of the environmental impact of electric vs. gasoline cars. (Combined with stats on buses, trains, hybrids, bicycles, and other transportations would be even more interesting) Mostly I've just seen highly partial statistics, and statistics in regards to pollution seem particularly easily manipulated. Very possibly electric cars could be the most environmentally safe, but I'm not convinced of that yet.
So it seems a bit ironic that Derek's xpdf is getting slammed for making the design decision to honor the author's copy and print restrictions I don't think anyone has been slamming xpdf -- a few people have just asked themselves whether Derek's design decisions reflect the priorities of Debian, and if Debian should change that decision for its own version of the software.
Right now people drive ten minutes to get to the highway, ten minutes to get off of it. And there's these giant corridors that get bigger and bigger, the merging gets more complicated, the roads up the the highways get bigger.
I think a more decentralized system is much more efficient. If population grows and spreads out, it's not so much of a problem if the transportation system similarly spreads. There would be a hundred ways to get from one place to another, and the system wouldn't have the scalability problems that highways have -- extra lanes aren't worth much.
Now, there's a problem with this -- this is how most transportations systems work inside cities. And it's slow. Because there's another scaling problem -- all those smaller roads intersect with each other, and you spend all your time waiting for lights. This is where an automated system could be so much more efficient than roads. Every intersection is simply a merge.
Heavy rail isn't so great either. If the stops aren't close to each other, few people will be able to walk to a rail stop. So you still have all the road problems, you've just replaced the heaviest corridor with a rail. If the stops are close to each other, the rail is very slow.
Right now there's a project in Chicago to replace some 9 miles of elevated rail for $350 million. That's insane. It's stupid. Part of it is because they can't actually shut anything down because there's no redundancy in the system. And the train will still be slow when they are finished.
RUF seems rather awkward, and I'm not sure what it would provide. But the basic idea of automated individual vehicles seems quite practical to me (PRT being a much more practical implementation).
People who believe the masses are all idiots are judging with very narrow criteria, and don't seem to appreciate that people in fact spend a good deal of their lives living their lives. Unlike us, some of them even have lives. They deserve some credit for it.
There's a power struggle. When everything is wild, the masses have a certain power in numbers. But the corporations have great monetary resources, if not creativity, and they manipulate the system too. Moving to law (like trademarks) certainly gives them an advantage, because they can be more effective thugs. But thugs exist in a wild system too. They don't exist in a just system, and that's what we haven't quite achieved (though, heck, it could be a lot worse).
Creating heat is the one place where efficiency doesn't matter much at all. Second law of thermodynamics -- energy is neither created nor destroyed. The energy in light ultimately ends up as heat -- the light rays bounce off of surfaces, each time becoming dimmer and slightly heating the surfaces.
There might be a certain inefficiency to this -- maybe the surfaces aren't what needs to be heated, and while some of the heat of the walls goes to the air, some goes through the wall and outside. But I doubt that really matters much.
If you are burning fuel, efficiency does matter. You have to burn the fuel completely, and you want to lose as little heat as possible through exaust. But for electricity it's not really an issue -- all those efficiency issues have been taken care of at the power plant, and the electical energy is pretty much guaranteed to become heat in the end.
How odd.
Every obscure pornographic site doesn't have to be included -- just the ones that matter. I think we could take a lot of the winds out of the sails of pro-censorship people if just the fraudulent sites could be blocked. Sure, if someone wanted to see porn they still could, because a large portion of the porn wouldn't be blocked. They get what they asked for, and I don't think that's a big deal.
This is a significant problem. Right now there are fundamentalist who deface library books because they are opposed to the books. It would be easy to abuse a volunteer-based system similarly.Part of what would help, I think, is the openness of the system. It should be just as easy to submit a complaint about a blocked website as it is to block a website, and it should be easy to figure out where your website stands without participating in any blocking yourself. If this was combined with a reputation system for the sugggesting moderators, then the worse abusers could be isolated.
Let's hear it for the new colors, people! I hope Fox News covers this important new development in foot-related fashion.
First, Hong Kong isn't a country. Second, both Singaport and Japan have been extremely protectionist, with significant government influence in the economy.