Possibly Its turning you car into a more efficient gasoline-powered vehicle. Electric engines are efficient. Internal combustion engines less so. So the combination of an efficient fuel cell and electric engine *may* outperform an ICE car. Also you can still use batteries for short trips if it is a plug-in which is the dominant use case.
The other advantage of using a fuel cell is that it makes it feasible to capture the CO2. In an ICE because you burn the fuel the concentration of CO2 in the exhaust is low, making it impracticable/expensive to capture the CO2. It may be possible then that when you are filling up to return the CO2, which can then be used to produce a synthetic hydrocarbon based fuel. Major technology hurdles, but a possible route to solve both the range problem of electric vehicles and the emission problems associated with hydrocarbon fuels.
Not only should the programmer learn assembler, they should also learn Operating system mechanisms. So they understand how their program is operating relative to those mechanisms. but that is not enough, they should also learn CPU design. How else are they really going to understand? Actually they really need to learn about materials science. Not enough really is it? Physics, laws of thermodynamics, electronics, quantum theory. Then when they program they will *really* know what is going on.
Alternativly they could learn more about the problem domain, so that the design better reflects the problem domain and will be more flexible in the changing environment. Nah, that really would be a waste of time.
Turn all your hard disk space into swap!
on
Is Swap Necessary?
·
· Score: 1
Turn all you disk space into swap space and do everything in memory!
RAM versus Hard disk...
Virtual memory is one concept to free the programer from having to think about physical program size versus physical memory size, by providing a general mechanism to get stuff to and from the hard disk into physical memory.
Files/file systems are another concept, that also require the loading from hard disk to and from physical memory (ultimately).
Who needs both!
Transactions? What? yeah, yeah, yeah... Your happy to do all the file open, file close, read, read, read, but not prepared to be explicit about transaction boundaries? *sigh* use method invocation and pay the penalty, chump.
"Files" are used for both data transfer and data persistence.
The brilliance of Unix, was, that everything is a file. Which allows amoung other things for a kind of closure ( i.e. cat fred | awk | sed...).
It is a very useful abstraction.
The abstraction has limitations.
When transfering data - you have to describe what the data is (metadata). The description must be in terms of a common frame between the transferring parties. or the data must be "self describing" at the file level or the protocol level.
When storing or persisting data - you want it to hang around reliably and efficiently. There are layers of implementation and interface. The requirements of these interfaces are not the same as for data transfer.
I think some of the reasons for these difficulties is taking the file abstraction too seriously, and not considering the difference between storage and transfer.
i.e. I agree with the conclusion reached by the article - other OS implementations are bleeding into OS X in the name of interoperability. They dont have to, you just have to know that there is some sort of transformation between the files that are stored and the files that are transmitted.
Re:The problem is in the dependency database
on
An RPM Port Of APT
·
· Score: 2
"Inevitably, the database will get out of sync
the moment you have to compile something from source because no.deb or.rpm file is available right then, or..."
I agree with this. and it is THE PROBLEM and it would make everybodies life easier if it were "solved".
I disagree with your reaction to it though. Why not make the goal that the database CAN NOT get out of sync?
The implication is that when do need to compile something from sources (or do a patch) - that you create a package to add it to your system. Until the tools are made to make this very trivial it is not practical. but it makes sense as the goal. It also gets to a position where when you run something - anything on your system - it is ready to be put on somebody else's system. Lets take it all the way - I mean write a perl script or a bash script and rather than "chmod u+x script" - tell the system "apt package and install script" - or whatever. sounds crazy? perhaps, but think about it a little longer.
However trying to detect dependencies through what is installed is worse than "not easy". So I want to go the other way!
As Josh notes FreeNet is a mechanism that efficiently distributes static data is sorely needed and that is what freenet provides. It should be thought of as a caching mechanism and it or somehting similar could be used to replace the add-hoc caching mechanisms (squid) in place for the web and any other services that rely on the distribution of static data.
However - something like slashdot is also mostly static data - with a small amount of information that is per user specific.
Imagine that there was an HTML directive to include some text (or whatever) from a named object. That the static parts of slashdot was published as these named objects and the dynamic stuff you had to get by quering the slashdot server directly.
The objection you might raise is - but there is no such HTML directive - so its impractical to think as though there is - BUT there has never been a good reason to have such a directive - because there has never been a really efficient caching mechanism for static data built - Soooo...
Static data is more prevalent/significant than you might think if you were focused on the current web implementation, because you can only effectivly currently identify a subset of static data.
and of course there is lots of other static data as well, notably software (and security and other concerns are solvable)
Given an efficient underlying transportation mechanism, the implementation of the web could change - so I advocate being more positive about the utility of FreeNet or similar. It is BECAUSE there has been no such underlying mechanism, that there has be no thought of implementing the web this way.
However, from a inertia perspective - I think my point is probably well and truly moot - so there you go - Josh is right - I just wanted to emphasise looking outside the current implementation when thinking about these things.
Once you have done the analysis and have a working system, put your XML DTD forward as the standard. Make this your business model - be the first to market. Get the qudos of being the ones who wrote the standard. Let the other companies "steal" you DTD - if they do, you have created a bigger less segmented market in which you are the leaders. Try and be the best implementors and supporters of the system that you have written the standard for.
What licence should a standard be released under? Does not really matter - the only problem is if another company takes the standard and uses and "embrace and extend" policy that makes old implementations incompatible. The role of the standards body is to check whether implementations conform to the standard. If you cant find the right standards body to do that - do it yourself - you need a "brand" to make this work.
Slashdot Mirror
Necessary but not sufficient is really tough for some people isn't it?
Possibly Its turning you car into a more efficient gasoline-powered vehicle.
Electric engines are efficient. Internal combustion engines less so.
So the combination of an efficient fuel cell and electric engine *may* outperform an ICE car.
Also you can still use batteries for short trips if it is a plug-in which is the dominant use case.
The other advantage of using a fuel cell is that it makes it feasible to capture the CO2. In an ICE because you burn the fuel the concentration of CO2 in the exhaust is low, making it impracticable/expensive to capture the CO2.
It may be possible then that when you are filling up to return the CO2, which can then be used to produce a synthetic hydrocarbon based fuel.
Major technology hurdles, but a possible route to solve both the range problem of electric vehicles and the emission problems associated with hydrocarbon fuels.
Not only should the programmer learn assembler, they should also learn Operating system mechanisms. So they understand how their program is operating relative to those mechanisms. but that is not enough, they should also learn CPU design. How else are they really going to understand? Actually they really need to learn about materials science. Not enough really is it? Physics, laws of thermodynamics, electronics, quantum theory. Then when they program they will *really* know what is going on.
Alternativly they could learn more about the problem domain, so that the design better reflects the problem domain and will be more flexible in the changing environment. Nah, that really would be a waste of time.
Turn all you disk space into swap space and do everything in memory!
RAM versus Hard disk...
Virtual memory is one concept to free the programer from having to think about physical program size versus physical memory size, by providing a general mechanism to get stuff to and from the hard disk into physical memory.
Files/file systems are another concept, that also require the loading from hard disk to and from physical memory (ultimately).
Who needs both!
Transactions? What? yeah, yeah, yeah... Your happy to do all the file open, file close, read, read, read, but not prepared to be explicit about transaction boundaries? *sigh* use method invocation and pay the penalty, chump.
"Files" are an abstraction.
"Files" are used for both data transfer and data persistence.
The brilliance of Unix, was, that everything is a file. Which allows amoung other things for a kind of closure ( i.e. cat fred | awk | sed...).
It is a very useful abstraction.
The abstraction has limitations.
When transfering data - you have to describe what the data is (metadata). The description must be in terms of a common frame between the transferring parties. or the data must be "self describing" at the file level or the protocol level.
When storing or persisting data - you want it to hang around reliably and efficiently. There are layers of implementation and interface. The requirements of these interfaces are not the same as for data transfer.
I think some of the reasons for these difficulties is taking the file abstraction too seriously, and not considering the difference between storage and transfer.
i.e. I agree with the conclusion reached by the article - other OS implementations are bleeding into OS X in the name of interoperability. They dont have to, you just have to know that there is some sort of transformation between the files that are stored and the files that are transmitted.
"Inevitably, the database will get out of sync .deb or .rpm file is available right then, or..."
the moment you have to compile something from source because no
I agree with this. and it is THE PROBLEM and it would make everybodies life easier if it were "solved".
I disagree with your reaction to it though. Why not make the goal that the database CAN NOT get out of sync?
The implication is that when do need to compile something from sources (or do a patch) - that you create a package to add it to your system. Until the tools are made to make this very trivial it is not practical. but it makes sense as the goal. It also gets to a position where when you run something - anything on your system - it is ready to be put on somebody else's system. Lets take it all the way - I mean write a perl script or a bash script and rather than "chmod u+x script" - tell the system "apt package and install script" - or whatever. sounds crazy? perhaps, but think about it a little longer.
However trying to detect dependencies through what is installed is worse than "not easy". So I want to go the other way!
Joshes comments are right on the money.
As Josh notes FreeNet is a mechanism that efficiently distributes static data is sorely needed and that is what freenet provides. It should be thought of as a caching mechanism and it or somehting similar could be used to replace the add-hoc caching mechanisms (squid) in place for the web and any other services that rely on the distribution of static data.
However - something like slashdot is also mostly static data - with a small amount of information that is per user specific.
Imagine that there was an HTML directive to include some text (or whatever) from a named object. That the static parts of slashdot was published as these named objects and the dynamic stuff you had to get by quering the slashdot server directly.
The objection you might raise is - but there is no such HTML directive - so its impractical to think as though there is - BUT there has never been a good reason to have such a directive - because there has never been a really efficient caching mechanism for static data built - Soooo...
Static data is more prevalent/significant than you might think if you were focused on the current web implementation, because you can only effectivly currently identify a subset of static data.
and of course there is lots of other static data as well, notably software (and security and other concerns are solvable)
Given an efficient underlying transportation mechanism, the implementation of the web could change - so I advocate being more positive about the utility of FreeNet or similar. It is BECAUSE there has been no such underlying mechanism, that there has be no thought of implementing the web this way.
However, from a inertia perspective - I think my point is probably well and truly moot - so there you go - Josh is right - I just wanted to emphasise looking outside the current implementation when thinking about these things.
Once you have done the analysis and have a working system, put your XML DTD forward as the standard. Make this your business model - be the first to market. Get the qudos of being the ones who wrote the standard. Let the other companies "steal" you DTD - if they do, you have created a bigger less segmented market in which you are the leaders. Try and be the best implementors and supporters of the system that you have written the standard for. What licence should a standard be released under? Does not really matter - the only problem is if another company takes the standard and uses and "embrace and extend" policy that makes old implementations incompatible. The role of the standards body is to check whether implementations conform to the standard. If you cant find the right standards body to do that - do it yourself - you need a "brand" to make this work.