Using more RAM doesn't use more energy. Either your RAM is powered on, or it's not. And if it's powered on it maintains its contents, no matter whether the OS has actually written anything useful to it.
That is not entirely true. Although much of the power dissipation in DRAMs comes from driving the data bus at high speeds (and it happens always, no matter what portion of internal memory space is actually used), some of it comes from memory matrix of the chip. Each DRAM cell is built around tiny on-chip capacitor. The capacitor can be either charged or discharged, which represents two values bit can assume. As bit held in the memory cell toggles its state, the capacitor gets charged and discharged. Whenever the capacitor is charged, it receives a portion of energy from power supply. When it is discharged, that energy is thrown away. The faster the average bit toggle rate and greater the average number of bits toggled, the greater the power dissipation of DRAM. Also, since those capacitors are "leaky" (they discharge spontaneously over time measured in milliseconds), a mechanism is in place to refresh them from time to time. Therefore, if memory contains static data consisting predominantly of bit states which correspond to charged capacitors, it wastes more energy then if it contains predominantly bit states which correspond to empty capacitors.
What isn't clear is why would you want these batteries to power your car? I don't really see any discussion on whether these pack more power than a 50lb car battery would. From the description it sounds like they're just regular batteries which expire, but are tiny. So by my no-math-involved logic, 50lbs of these nano-batteries should pack about the same punch as a regular 50lb car battery.
It may be easier to unload and load 50lb of small batteries then single big one, provided you don't have to manually disconnect and connect all the little ones. The difference is like between stopping for gas and going to the repair shop.
I see nothing in those articles about these batteries being "mega efficient", as the title of this Slashdot post screams. The novelty seems to be the fact that they're grown using viruses and can be applied in thin films.
Oh, no, that is not complete story of what this bugs could do. Think about it for a moment:
1. those are big-molecule-sized particle batteries. 2. You can construct them in such a matter that their terminals can be accessed only trough specific shape of (molecular, e.g. an enzyme) connectors. 3. You can make each terminal incompatible with opposite polarity terminal, allowing for suspending those batteries in a liquid, or, if the batteries can bond with each other through (weak) hydrogen bonds, a large mass of them might already be in liquid form.
Now, what is that all together? An "electric fuel", something that might power electric cars, but refuel on pump stations in same time ICE cars refuel. Car would have nanobatteries' processing unit, which would allow parallel connection of great many such batteries, pumped from the "fresh" tank. Once discharged in processor, batteries would be would be pumped into "used" tank.
Bonus points for hypothetical clever battery design that would spoil terminals' shape if battery is empty as it would allow processor to be installed in "fresh" tank and just keep the tank stirred enough. Once processor squeezes out all the "juice", battery should fall off it, allowing connection with another, fresh battery to commence.
Natural gas turbines burn the fuel directly in a turbine. I'm not sure, but I suspect the reason you can't do this with coal is that the fuel powder particles will raise hell with the moving parts of the turbine.
You could avoid particle problem. You could gasify coal into syngas (Carbon monoxide and Hydrogen mixture) and use it in turbines, but low quality grade coal is rich in impurities (e.g. sulphur), so turbine would probably suffer from acid corrosion and vary in output power level as mixture varies in CO/H2 proportion and it would wear down quicker then natural gas turbine.
it can be subsurface, so as to have little or no long-term impact on the environment (obviously construction would temporarily beat up the habitat, though.)
If it is built underground, you may increase energy density as well: use the water injected into the ground as hydraulic fluid to raise the covering terrain, thus the energy is stored as gravitational potential energy of elevated earth (well, this has to be NIMBY, as it regularly produces small earthquakes as it works).
If local terrain geology allows it (parallel water-impervious layers) you can make a sort of reverse artesian well, without much investment into construction works.
Compression didn't make it much better. Almost any decent compression algorithm is fast when deconpressing, but slow when compressing. When handling a page fault in that context, you had to do both. Compress the page you want swapped out, and decompress the page you want swapped in. Not only that took time, but it was CPU time. Unlike IO time, which happens on DMA in an ideal world, and lets your CPU schedule some other task in that time.
Obviously, it begs for a hardware solution, simple coprocessor of sorts, which would seize the memory bus (while CPU grazes in its cache), perform the comdec algorithm and mem-to-mem DMA copying.
It could probably fit in an ASIC, FPGA, whatever, but it would be even better if it was integrated with MMU.
Compression could be done in advance, because of the selection criteria for page swap: the page in working memory which was least recently accessed is the most probable candidate for it.
Pages containing 'code' and 'text' segments shouldn't even bother the system to compress them, they should be just discarded (there is non-compressed copy in Flash, read access time is not so tragic).
And you're saying leave that to the programmer??? That's the biggest maintenance nightmare I have EVER heard of.
I just don't think it should be left to the whims of some dude in the back room that would never document his intent and execution properly.
If you do go ahead and write it,...
I can see you are very tempted with the idea of unlimited power but you struggle to keep your sanity (*my preciouss*)...
Yes, it IS a lot like putting all the eggs in one basket... it requires WATCHING OVER THAT BASKET LIKE A HAWK! Hopefully, it should be easier then watching all over wide area of baskets (whole project). With it, you could actually *take away* freedom to do many stupid things from your underling code monkeys.
The dangerous "freedom" is just theoretical. Flexibility may mean more freedom, but also less freedom, of for that matter, same amount of it as it is presently. First of all, the language would have to carry "standard set of rules definition" with it, but including them in your project would be optional and RECOMMENDED. Rule sets would not be designed by any programmer (like probably someone you regret to know, or whose code you regret to had to read), but by an expert (e.g. a CS PhD) who is capable of properly detecting problems and devising solutions.
It is near equivalent situation to C/C++ system API being moved from language definition into accompanying standard library: you *could* write your own library replacement, or even not use any at all (in small embedded systems development), but hardly ever anyone does anything like that. However, should it become absolutely necessary, it could be done. Of course, anyone could write their own rule sets, if they dared, but it will be considered dangerous and not recommended, just like messing with standard library. Someone more foolish, toying with programming for fun, or knowing very well what they do, could also do some stunts without safety gear, hopefully in some very thoroughly isolated and well documented performance-critical part of code.
Imagine integrating language contemporary best practices and recommendations, your own organization coding standards, your project specific safety (or style) rules, thus (by means of having each coworker #include-ing header file with their definition in each source file) instantly enforcing them project-wide, all in modular and layered manner? Over time accumulated experience will be possible to transfer onto new projects. I think it could be great collaboration (hmm, an one-way collaboration) tool.
Admittedly, saying about a project that it was written in such a language would not mean any hint of measure of its quality any more. Instead, one would say that certain well known and respectable set of rules was applied to the project, and then we would know that it was enforced by compiler, not left to whim of developers to "respect" and prone to bugs wiggling through the loopholes of manual code inspections.
Well, it is like a fence: it protects you from falling over, but once it runs out, you may fall again. If you put the fence all around you, you won't be able to go anywhere further.
Similar thing is with protection provided in C++: it works against C kind of stupid mistakes but it brings in a set of its own stupid mistakes. There is always another downfall we are yet to encounter.
Therefore, and realizing it struck me this very moment, languages should be as permissive and empowering as possible (go ahead, knock your self out completely, foot, leg, everything!), but discipline should be enforced intrinsic to language definition.
Language should have means to enable us to construct discipline rule set and just blindly check consistency of code and attached discipline (akin to XML idea, although XML is not a programming language). To return to "fence" analogy, programmer (or project architect) should be allowed to construct new safety fences (or even remove old ones if necessary) as needs arise or problems are encountered.
If I'm not mistaken, Isaac Asimov wrote in Foundation's Edge that the reason why humans have developed a technological society is because we have hands. Dolphins and whales have sizeable brains but they lack hands.
Actually, technological society came to being because we needed tools (weapons included) so much and so often that crafting them gradually became so elaborate, leading to concept of keeping objects from environment, carefully picked and/or processed, in one's possession. Early humans assigned value to their tool making efforts, which led to keeping valuable assets (very useful, but too slow to make on the spot if urgently needed), which led to concept of property, which led to concept of trade, which led to specialization,... etc.
Should had nature equipped our ancestors with more able limbs or other powerful body part tools, regardless of intelligence, we would had never became a material civilization. Earth's highest organizational achievement would be a hive society - organized multitude of naturally well equipped drones.
There are other animals that also use or even make tools, but they throw them away after using them and make another ones when needed (we are approaching that state of mind again in modern consumer society). They either have no concept of objects' value or, alternatively, they have it but it is topped by inconvenience of having to carry tools around and thus encumber own movement.
He even goes as far to say that humans 'thinks' with their hands, in that the hands are manifestations of intelligence.
We 'think' with our whole body and some more (projection of imagination or attention, Ki/Chi), and we especially think a lot with what we use the most: i.e. our eyes, other senses and our faces, which evidently shows, then hands... however that is similar to other species. Certainly birds mostly think with their eyes and wings, fish with their whole bodies, etc.
If there is intelligent life out there in other solar systems, it is more probable for them to be like other non-human intelligent animals of the Earth then to have an advanced material civilization. As Jarred Diamond observed, the latter is consequence of lucky circumstances and is usually in short supply on planetary scale. Intelligence-wise, we will sooner and more often find Aliens (or, if we are lucky, Dolphins) then E.T. .
Ever since I watched Star Wars for the first time, I had this idea: if I could rapidly move common focal point of thousands of tiny laser beams along the fixed segment of handle axis, with constructive interference (mostly) sustained, with lasers' wavelength matched to a line of absorptive spectrum of atmospheric gas (on Earth it would be nitrogen), I would have a plasma weapon (or tool) very much resembling a lightsaber.
It should also have adaptive (microcomputer controlled) focusing, so that if any obstacle enters the "blade" segment, all the lasers immediately keep focus on the point of contact, to make it yield to blade as fast as possible
Now, there is a way to it. I imagined some piezoelectric-actuated mirrors would do, but had no idea how to construct it. This new thingy is so much better and more fine-grained.
Greenland: Too busy with awesome blond chicks, high tech data centers, and hot spas. Not interested in causing it and no one is interested in attacking it.
Clearly, a slip of a mind. According to his associations, he must have meant Iceland, not Greenland.
Hmm, with layered design approach it doesn't have to be a cuff for progress. There is a lot of prior experience on handling transactions laying around waiting to be reused.
Basically it could be very simple, e.g.:
DEV12345 to NET (broadcast): seek 100W, limit 0.01 cents, starting in at most 10 seconds, ref.ask# 12345_12... SUP11 to DEV12345: bid 12345_12, 0.003, in 5s, ref.bid# 11_12345_0 SUP53 to DEV12345: bid 12345_12, 0.008, in 3s, ref.bid# 53_12345_0 SUP37 to DEV12345: bid 12345_12, 0.0029, in 8s, ref.bid# 37_12345_0... DEV12345 to NET (broadcast): close# 12345_12, 37_12345_0, 0.0029c, 8s... SUP37 to DEV12345: go# 37_12345_0... [DEV12345 going ON]...... DEV12345 to SUP37: release# 37_12345_0 in 0.2s [DEV12345 going OFF]
(DEV12345 could keep the bid going on while ON, to switch off to another supplier... in fact, DEV12345 was on all the time, however, if no supplier was selected, then DEV12345's power meter will bill it with highest, unfavorable price - akin to taking lawn from a lawn shark - interest is always the steepest. That's why all the appliances are seeking cheapest power in real time, all the time. There is a lot to be thought of very carefully in such a system, but basically it is a banking market with electric power in role of currency. IMHO, if we ever construct it, this infrastructure will bring huge profits, just like banking, or telecomms business, it is about brokering common pool of piled resources among small scale producers and consumers. Perhaps, some day all three systems will converge and electric power WILL become universal, global, hard currency.
IMHO, to prevent instabilities and peaking, system can not be left blind and non-cooperative. We should have an integrated intelligent system for power delivery: There should be an asynchronous handshaking protocol for appliances to request exact amount of additional power from the grid and to postpone activation before the grid acknowledges that it is ready to supply it.
Furthermore, when load intensifies, in order to prevent "starvation" of new appliances waiting to be switched on, all appliances would have to be able to gradually scale down their consumption on demand from the grid.
Alternatively (/additionally), there should be "power bid" system: consumer should set the limit for the price of a watt consumer is willing to pay for given appliance (according to consumers' own priorities and preferences) and then the grid could clear the overload by raising the price (thus pushing of-grid appliances with lower priority set by their respective owners) in real time.
Obviously, we could set our low priority "batch job" appliances (dishwashers, clothes washer/dryer,...) on low price/priority settings and our immediate need appliances (hair dryers, computers, lights, microwave ovens,...) on high price/priority settings.
Interestingly, this system could also allow small/micro/local rapid response energy producers and merchants (buying low, selling high, provided they have efficient energy storage/retrieval systems) to compete on the "watt market" and offload the system, thus creating new opportunities, better energy supply and more accurate cost management.
For instance, we could also express the timing in monetary equivalents: you can buy immediate power from small producer or merchant now, for higher cost, or you can book lower cost watts delivered from huge power station at some later time, when they are ready to deliver some extra power. In short, if you can tell exactly how many watts you need, for how long and you can afford to wait some time to get it, you could get yourself significantly lower cost.
Hmm, tofu is too... jelly-consistency for my liking. However, it came to my attention that medical research came out with something called Artificial Extracellular Matrix Proteins, which perhaps could be combined with soy proteins to make something that could be chewed like a meat?
Basically, they should make something like... artificial muscular long fibers (perhaps even cellulose fibers would do if they have lots of proteins lumped to it), and we can try pretending it was meat.
Oh... and no, "the ability to use available information to arrive at good outcomes of any decision" is not free will. That is called reason. Free will comes in when you knowingly chose not to take the better of two options... such as a randomly deciding to use a nail gun to attach your hand to a wall. Free will is the ability to choose in SPITE of the known outcome.
Hmm, If that is a correct definition, than the overall lack of free will could be inferred from Anthropic principle, as such defined free will, when exercised, sooner or later gets you a Darwin Award!
Anything with negative effects that manifest after the next quarter's numbers doesn't matter. By that time the perrpetrators have been rewarded and have moved on.
Then, forbid vertical migration inside companies.
Employees in small enterprises are better motivated. Managers in small enterprises are often owners and/or do part of the work. Large companies are stalemate and prefer to rely on external resources (consultants and subcontractors, which, incidentally, ARE little enterprises). IMHO, there is an obvious solution: No large company should consist of too many direct employees - each department should be an independent and employed specialized entity, a company in itself.
Each "collective employee" should bear complete undivided responsibility for own tasks and own employees (or "collective employees"). No way manager of the "collective employee" would climb corporate ladder - she is not part of corporation, she is part of closed "collective employee" module. No way up, only in or out, onto workforce market. Those individuals who wish to have carriers in top corporate layers should get adequate training and progress through changing jobs, or even better, selling smaller CE companies and buying ones positioned on a higher intermediate levels (CECs which employ lower level CECs). Hey, this would make a nice RP game, too!
True. There will be little industry enterprises in space, spaceships construction included, without abundance of materials from some place out of deep gravity well, unless we get to make a space elevator, of course. However, it is a chicken-and-egg type of problem: in order to go and get enough materials for new space industry, we need large cargo vessels to begin with. And, we'll need permanent orbital bases as well.
Perhaps first (OK, next) generation of these structures will be universal: suitable for permanent orbiting celestial bodies, as well as for moving between them, with facilities to dock relatively small STO ships, as well as attach to own class ships to form larger structures.
Some sort of sphere with lot of ports comes to mind - single one easily rotated for artificial gravity, can be connected to sibling spheres with addition of cylindric corridors (Atomium - like), same unused ports/connection points can be equipped for cargo capsules docking. The universal dock/connection points should also be strong points of the spheres: external thrust engine modules should be delivered from Earth as final stage (like any other STO ship, satellite, etc.) of a rocket and connected there when needed, manipulator (robotic "hands") modules too.
However, all this versatility is in vain if it cannot be repaired indefinitely. For short lived things, we better go for "do one thing and do it well" approach. If we cannot finish a project before its components wear out, we shouldn't set goal that ambitious. We need methods of reducing wear on critical components, perhaps by making replaceable outer shells or sheet layers that can be patched if damaged (and a method of patching that works in outer space, of course).
Last but not least, anything large enough in orbit must have autonomous safety self-destruction (breaking down in small enough chunks to burn in atmosphere) mechanism embedded inside, to be triggered by certain signs of atmospheric (re-)entry in progress. Or, there should be a strict regulation regarding limits of how big structures are allowed in sub-geosynchronous orbits.
As for blue lights in the car, I think it's potentially a bad idea. Blue light makes it hard to see in the dark.
I have noticed that most people, myself included, cannot focus their vision on "deep blue" (sapphire blue) glowing signs at night, those remain "fuzzy" no matter how hard you concentrate. Making any displays but the simplest indicator lamps with blue LEDs is ridiculous. However, as long as you give up trying to read them and ignore them, they don't affect seeing other object in your visual field. "Nixie tube blue" (light blue, aquamarine blue) is definitely easier on eyes... and it is also more similar to "morning sky blue", but I am yet to see such LEDs.
Slashdot Mirror
Using more RAM doesn't use more energy. Either your RAM is powered on, or it's not. And if it's powered on it maintains its contents, no matter whether the OS has actually written anything useful to it.
That is not entirely true. Although much of the power dissipation in DRAMs comes from driving the data bus at high speeds (and it happens always, no matter what portion of internal memory space is actually used), some of it comes from memory matrix of the chip. Each DRAM cell is built around tiny on-chip capacitor. The capacitor can be either charged or discharged, which represents two values bit can assume. As bit held in the memory cell toggles its state, the capacitor gets charged and discharged. Whenever the capacitor is charged, it receives a portion of energy from power supply. When it is discharged, that energy is thrown away. The faster the average bit toggle rate and greater the average number of bits toggled, the greater the power dissipation of DRAM. Also, since those capacitors are "leaky" (they discharge spontaneously over time measured in milliseconds), a mechanism is in place to refresh them from time to time. Therefore, if memory contains static data consisting predominantly of bit states which correspond to charged capacitors, it wastes more energy then if it contains predominantly bit states which correspond to empty capacitors.
Personally, I would prefer some sort of direct separation of (gaseous or liquid) oxygen and (solid, or various nanostructure material) carbon,
Hmm, could liquid CO2 be electrolyzed, or gaseous CO2 broken down by a strong electric field?
Comfortably is safely, for large values (YMMV) of A to B.
What isn't clear is why would you want these batteries to power your car? I don't really see any discussion on whether these pack more power than a 50lb car battery would. From the description it sounds like they're just regular batteries which expire, but are tiny. So by my no-math-involved logic, 50lbs of these nano-batteries should pack about the same punch as a regular 50lb car battery.
It may be easier to unload and load 50lb of small batteries then single big one, provided you don't have to manually disconnect and connect all the little ones. The difference is like between stopping for gas and going to the repair shop.
I see nothing in those articles about these batteries being "mega efficient", as the title of this Slashdot post screams. The novelty seems to be the fact that they're grown using viruses and can be applied in thin films.
Oh, no, that is not complete story of what this bugs could do. Think about it for a moment:
1. those are big-molecule-sized particle batteries.
2. You can construct them in such a matter that their terminals can be accessed only trough specific shape of (molecular, e.g. an enzyme) connectors.
3. You can make each terminal incompatible with opposite polarity terminal, allowing for suspending those batteries in a liquid, or, if the batteries can bond with each other through (weak) hydrogen bonds, a large mass of them might already be in liquid form.
Now, what is that all together? An "electric fuel", something that might power electric cars, but refuel on pump stations in same time ICE cars refuel. Car would have nanobatteries' processing unit, which would allow parallel connection of great many such batteries, pumped from the "fresh" tank. Once discharged in processor, batteries would be would be pumped into "used" tank.
Bonus points for hypothetical clever battery design that would spoil terminals' shape if battery is empty as it would allow processor to be installed in "fresh" tank and just keep the tank stirred enough. Once processor squeezes out all the "juice", battery should fall off it, allowing connection with another, fresh battery to commence.
Natural gas turbines burn the fuel directly in a turbine. I'm not sure, but I suspect the reason you can't do this with coal is that the fuel powder particles will raise hell with the moving parts of the turbine.
You could avoid particle problem. You could gasify coal into syngas (Carbon monoxide and Hydrogen mixture) and use it in turbines, but low quality grade coal is rich in impurities (e.g. sulphur), so turbine would probably suffer from acid corrosion and vary in output power level as mixture varies in CO/H2 proportion and it would wear down quicker then natural gas turbine.
it can be subsurface, so as to have little or no long-term impact on the environment (obviously construction would temporarily beat up the habitat, though.)
If it is built underground, you may increase energy density as well: use the water injected into the ground as hydraulic fluid to raise the covering terrain, thus the energy is stored as gravitational potential energy of elevated earth (well, this has to be NIMBY, as it regularly produces small earthquakes as it works).
If local terrain geology allows it (parallel water-impervious layers) you can make a sort of reverse artesian well, without much investment into construction works.
This is going to require an infrastructure capable of storing power for long time periods.
It is already solved problem.
Compression didn't make it much better. Almost any decent compression algorithm is fast when deconpressing, but slow when compressing. When handling a page fault in that context, you had to do both. Compress the page you want swapped out, and decompress the page you want swapped in. Not only that took time, but it was CPU time. Unlike IO time, which happens on DMA in an ideal world, and lets your CPU schedule some other task in that time.
Obviously, it begs for a hardware solution, simple coprocessor of sorts, which would seize the memory bus (while CPU grazes in its cache), perform the comdec algorithm and mem-to-mem DMA copying.
It could probably fit in an ASIC, FPGA, whatever, but it would be even better if it was integrated with MMU.
Compression could be done in advance, because of the selection criteria for page swap: the page in working memory which was least recently accessed is the most probable candidate for it.
Pages containing 'code' and 'text' segments shouldn't even bother the system to compress them, they should be just discarded (there is non-compressed copy in Flash, read access time is not so tragic).
I hope none patents this ...
And you're saying leave that to the programmer??? That's the biggest maintenance nightmare I have EVER heard of.
I just don't think it should be left to the whims of some dude in the back room that would never document his intent and execution properly.
If you do go ahead and write it, ...
I can see you are very tempted with the idea of unlimited power but you struggle to keep your sanity (*my preciouss*)...
Yes, it IS a lot like putting all the eggs in one basket ... it requires WATCHING OVER THAT BASKET LIKE A HAWK! Hopefully, it should be easier then watching all over wide area of baskets (whole project). With it, you could actually *take away* freedom to do many stupid things from your underling code monkeys.
The dangerous "freedom" is just theoretical. Flexibility may mean more freedom, but also less freedom, of for that matter, same amount of it as it is presently. First of all, the language would have to carry "standard set of rules definition" with it, but including them in your project would be optional and RECOMMENDED. Rule sets would not be designed by any programmer (like probably someone you regret to know, or whose code you regret to had to read), but by an expert (e.g. a CS PhD) who is capable of properly detecting problems and devising solutions.
It is near equivalent situation to C/C++ system API being moved from language definition into accompanying standard library: you *could* write your own library replacement, or even not use any at all (in small embedded systems development), but hardly ever anyone does anything like that. However, should it become absolutely necessary, it could be done. Of course, anyone could write their own rule sets, if they dared, but it will be considered dangerous and not recommended, just like messing with standard library. Someone more foolish, toying with programming for fun, or knowing very well what they do, could also do some stunts without safety gear, hopefully in some very thoroughly isolated and well documented performance-critical part of code.
Imagine integrating language contemporary best practices and recommendations, your own organization coding standards, your project specific safety (or style) rules, thus (by means of having each coworker #include-ing header file with their definition in each source file) instantly enforcing them project-wide, all in modular and layered manner? Over time accumulated experience will be possible to transfer onto new projects. I think it could be great collaboration (hmm, an one-way collaboration) tool.
Admittedly, saying about a project that it was written in such a language would not mean any hint of measure of its quality any more. Instead, one would say that certain well known and respectable set of rules was applied to the project, and then we would know that it was enforced by compiler, not left to whim of developers to "respect" and prone to bugs wiggling through the loopholes of manual code inspections.
Well, it is like a fence: it protects you from falling over, but once it runs out, you may fall again. If you put the fence all around you, you won't be able to go anywhere further.
Similar thing is with protection provided in C++: it works against C kind of stupid mistakes but it brings in a set of its own stupid mistakes. There is always another downfall we are yet to encounter.
Therefore, and realizing it struck me this very moment, languages should be as permissive and empowering as possible (go ahead, knock your self out completely, foot, leg, everything!), but discipline should be enforced intrinsic to language definition.
Language should have means to enable us to construct discipline rule set and just blindly check consistency of code and attached discipline (akin to XML idea, although XML is not a programming language). To return to "fence" analogy, programmer (or project architect) should be allowed to construct new safety fences (or even remove old ones if necessary) as needs arise or problems are encountered.
If I'm not mistaken, Isaac Asimov wrote in Foundation's Edge that the reason why humans have developed a technological society is because we have hands. Dolphins and whales have sizeable brains but they lack hands.
Actually, technological society came to being because we needed tools (weapons included) so much and so often that crafting them gradually became so elaborate, leading to concept of keeping objects from environment, carefully picked and/or processed, in one's possession. Early humans assigned value to their tool making efforts, which led to keeping valuable assets (very useful, but too slow to make on the spot if urgently needed), which led to concept of property, which led to concept of trade, which led to specialization, ... etc.
Should had nature equipped our ancestors with more able limbs or other powerful body part tools, regardless of intelligence, we would had never became a material civilization. Earth's highest organizational achievement would be a hive society - organized multitude of naturally well equipped drones.
There are other animals that also use or even make tools, but they throw them away after using them and make another ones when needed (we are approaching that state of mind again in modern consumer society). They either have no concept of objects' value or, alternatively, they have it but it is topped by inconvenience of having to carry tools around and thus encumber own movement.
He even goes as far to say that humans 'thinks' with their hands, in that the hands are manifestations of intelligence.
We 'think' with our whole body and some more (projection of imagination or attention, Ki/Chi), and we especially think a lot with what we use the most: i.e. our eyes, other senses and our faces, which evidently shows, then hands ... however that is similar to other species. Certainly birds mostly think with their eyes and wings, fish with their whole bodies, etc.
If there is intelligent life out there in other solar systems, it is more probable for them to be like other non-human intelligent animals of the Earth then to have an advanced material civilization. As Jarred Diamond observed, the latter is consequence of lucky circumstances and is usually in short supply on planetary scale. Intelligence-wise, we will sooner and more often find Aliens (or, if we are lucky, Dolphins) then E.T. .
Ever since I watched Star Wars for the first time, I had this idea: if I could rapidly move common focal point of thousands of tiny laser beams along the fixed segment of handle axis, with constructive interference (mostly) sustained, with lasers' wavelength matched to a line of absorptive spectrum of atmospheric gas (on Earth it would be nitrogen), I would have a plasma weapon (or tool) very much resembling a lightsaber.
It should also have adaptive (microcomputer controlled) focusing, so that if any obstacle enters the "blade" segment, all the lasers immediately keep focus on the point of contact, to make it yield to blade as fast as possible
Now, there is a way to it. I imagined some piezoelectric-actuated mirrors would do, but had no idea how to construct it. This new thingy is so much better and more fine-grained.
Clearly, a slip of a mind. According to his associations, he must have meant Iceland, not Greenland.
Yes, but, if the hammer left the room through the window instead, ... OK, wrong example.
Hmm, with layered design approach it doesn't have to be a cuff for progress. There is a lot of prior experience on handling transactions laying around waiting to be reused.
... ... ... ... ... ...
Basically it could be very simple, e.g.:
DEV12345 to NET (broadcast): seek 100W, limit 0.01 cents, starting in at most 10 seconds, ref.ask# 12345_12
SUP11 to DEV12345: bid 12345_12, 0.003, in 5s, ref.bid# 11_12345_0
SUP53 to DEV12345: bid 12345_12, 0.008, in 3s, ref.bid# 53_12345_0
SUP37 to DEV12345: bid 12345_12, 0.0029, in 8s, ref.bid# 37_12345_0
DEV12345 to NET (broadcast): close# 12345_12, 37_12345_0, 0.0029c, 8s
SUP37 to DEV12345: go# 37_12345_0
[DEV12345 going ON]
DEV12345 to SUP37: release# 37_12345_0 in 0.2s
[DEV12345 going OFF]
(DEV12345 could keep the bid going on while ON, to switch off to another supplier... in fact, DEV12345 was on all the time, however, if no supplier was selected, then DEV12345's power meter will bill it with highest, unfavorable price - akin to taking lawn from a lawn shark - interest is always the steepest. That's why all the appliances are seeking cheapest power in real time, all the time. There is a lot to be thought of very carefully in such a system, but basically it is a banking market with electric power in role of currency. IMHO, if we ever construct it, this infrastructure will bring huge profits, just like banking, or telecomms business, it is about brokering common pool of piled resources among small scale producers and consumers. Perhaps, some day all three systems will converge and electric power WILL become universal, global, hard currency.
IMHO, to prevent instabilities and peaking, system can not be left blind and non-cooperative. We should have an integrated intelligent system for power delivery:
...) on low price/priority settings and our immediate need appliances (hair dryers, computers, lights, microwave ovens, ...) on high price/priority settings.
There should be an asynchronous handshaking protocol for appliances to request exact amount of additional power from the grid and to postpone activation before the grid acknowledges that it is ready to supply it.
Furthermore, when load intensifies, in order to prevent "starvation" of new appliances waiting to be switched on, all appliances would have to be able to gradually scale down their consumption on demand from the grid.
Alternatively (/additionally), there should be "power bid" system: consumer should set the limit for the price of a watt consumer is willing to pay for given appliance (according to consumers' own priorities and preferences) and then the grid could clear the overload by raising the price (thus pushing of-grid appliances with lower priority set by their respective owners) in real time.
Obviously, we could set our low priority "batch job" appliances (dishwashers, clothes washer/dryer,
Interestingly, this system could also allow small/micro/local rapid response energy producers and merchants (buying low, selling high, provided they have efficient energy storage/retrieval systems) to compete on the "watt market" and offload the system, thus creating new opportunities, better energy supply and more accurate cost management.
For instance, we could also express the timing in monetary equivalents: you can buy immediate power from small producer or merchant now, for higher cost, or you can book lower cost watts delivered from huge power station at some later time, when they are ready to deliver some extra power. In short, if you can tell exactly how many watts you need, for how long and you can afford to wait some time to get it, you could get yourself significantly lower cost.
Hmm, tofu is too
Basically, they should make something like
Then, forbid vertical migration inside companies.
Employees in small enterprises are better motivated. Managers in small enterprises are often owners and/or do part of the work. Large companies are stalemate and prefer to rely on external resources (consultants and subcontractors, which, incidentally, ARE little enterprises). IMHO, there is an obvious solution: No large company should consist of too many direct employees - each department should be an independent and employed specialized entity, a company in itself.
Each "collective employee" should bear complete undivided responsibility for own tasks and own employees (or "collective employees"). No way manager of the "collective employee" would climb corporate ladder - she is not part of corporation, she is part of closed "collective employee" module. No way up, only in or out, onto workforce market. Those individuals who wish to have carriers in top corporate layers should get adequate training and progress through changing jobs, or even better, selling smaller CE companies and buying ones positioned on a higher intermediate levels (CECs which employ lower level CECs). Hey, this would make a nice RP game, too!
True. There will be little industry enterprises in space, spaceships construction included, without abundance of materials from some place out of deep gravity well, unless we get to make a space elevator, of course. However, it is a chicken-and-egg type of problem: in order to go and get enough materials for new space industry, we need large cargo vessels to begin with. And, we'll need permanent orbital bases as well.
Perhaps first (OK, next) generation of these structures will be universal: suitable for permanent orbiting celestial bodies, as well as for moving between them, with facilities to dock relatively small STO ships, as well as attach to own class ships to form larger structures.
Some sort of sphere with lot of ports comes to mind - single one easily rotated for artificial gravity, can be connected to sibling spheres with addition of cylindric corridors (Atomium - like), same unused ports/connection points can be equipped for cargo capsules docking. The universal dock/connection points should also be strong points of the spheres: external thrust engine modules should be delivered from Earth as final stage (like any other STO ship, satellite, etc.) of a rocket and connected there when needed, manipulator (robotic "hands") modules too.
However, all this versatility is in vain if it cannot be repaired indefinitely. For short lived things, we better go for "do one thing and do it well" approach. If we cannot finish a project before its components wear out, we shouldn't set goal that ambitious. We need methods of reducing wear on critical components, perhaps by making replaceable outer shells or sheet layers that can be patched if damaged (and a method of patching that works in outer space, of course).
Last but not least, anything large enough in orbit must have autonomous safety self-destruction (breaking down in small enough chunks to burn in atmosphere) mechanism embedded inside, to be triggered by certain signs of atmospheric (re-)entry in progress. Or, there should be a strict regulation regarding limits of how big structures are allowed in sub-geosynchronous orbits.
I, for one, welcome our new robotic underdogs!