Difference between revisions of "General discussion"

From apm
Jump to: navigation, search
m
(Added general software issues)
Line 7: Line 7:
  
 
= Discussion of speculative technologies  =
 
= Discussion of speculative technologies  =
 +
 +
[yet empty]
 +
 +
= General software issues =
 +
 +
'''In a world where the digital and physical realm starts to blend'''
 +
that is physical products become metworked live acutateable and reconfigurable
 +
'''software architecture / organisation  / design or however one may call it becomes even more important''' than it is already today.
 +
 +
Key issues are:
 +
* stability (at best error-proofness) [http://en.wikipedia.org/wiki/Correctness_%28computer_science%29 correctness]; [http://www.haskell.org/haskellwiki/Research_papers/Testing_and_correctness research in Haskell]
 +
* maintainambility
 +
* extendability
 +
* modularity
 +
* diversity (as options for unexpected dead end routes)
 +
* optimized-specialisation conserving functionality-expanding-generalisation and vice versa
 +
* highly complex version management ([http://en.wikipedia.org/wiki/Dependency_hell dependency hell])
 +
* ...
 +
 +
== File systems ==
 +
 +
Currently used tree based and machine local file systems have their limits.
 +
Sorting the same data after multiple hierarchical criteria is impossible.
 +
To give an example: Assume one owns a lot of image-file text-file sets.
 +
The small text files are of high importance (e.g. source code) while the huge images are of relatively low importance (e.g. rendered from source).
 +
Archiving different backup levels (location, redundancy level) for file types of different importance isn't possible with the basic functionalities of tree based file systems.
 +
 +
File system indexing usage of meta-data and file tagging only mend but do not solve the problem.
 +
Some kind of graph based file systems are needed.
 +
Graph databases (like Neo4j?) are interesting but are only crutches if implemented on top of tree based file systems.
 +
 +
The limitation to serial access to mass storage disk space (now changing with random access SD drives)
 +
led to the fact that current systems are still hardware near programmed and suffer from a lack of abstraction.
 +
Data must be manually serialized for persistent storage.
 +
Net based services like [http://de.wikipedia.org/wiki/Google_Drive Google drive] and Facebook already emulate this behavior.
 +
Another interesting "on top" approach is [http://www.yesodweb.com/ yesod] with its [http://www.yesodweb.com/book/persistent integrated persistence].
 +
 +
* A good writeup about the problem and solution approaches can be found here: [http://c2.com/cgi/wiki?FileSystemAlternatives file system alternatives]
 +
 +
== Dependency hell ==
 +
 +
Current packet management systems suffer from the dreaded problem of [http://en.wikipedia.org/wiki/Dependency_hell dependency hell].
 +
Especially developers who install a lot of software packages in parallel are affected.
 +
Solution approaches include:
 +
 +
* [http://en.wikipedia.org/wiki/Nix_package_manager Packet manager of experimental NixOS] - [http://www.linuxplanet.com/linuxplanet/reviews/6654/1 review]
 +
* [http://en.wikipedia.org/wiki/Zero_Install multi-platform reversible java package management system]
 +
 +
== Further related information ==
 +
 +
Avoiding hidden state (a potential source of errors) can be compatible with interactive environments:
 +
* Wikipedia: [http://en.wikipedia.org/wiki/Functional_reactive_programming Functional reactive programming]
 +
* [http://en.wikipedia.org/wiki/House_%28operating_system%29 House functional operating system]
  
 
= Other stuff  =
 
= Other stuff  =
  
<br>
+
[yet empty]

Revision as of 17:23, 19 February 2014

From Sci to Fi

Discussion of technologies that may or may not be enabled through technology level III and the chances and dangers they may bring can be discussed here.
Please add them to the list of potential applications as short and concise as possible and link back here or to a new page to the apropriate section.
If the topic grows big you are welcome to create a new page and link it from here.

Please don't add technologies where there is no reason to believe that APM will help making them a reality like beaming of humans, warp drives, neutron star physics or the like.
Also the effects of self improving AI that might crop up in the future is of no concern here.

Discussion of speculative technologies

[yet empty]

General software issues

In a world where the digital and physical realm starts to blend that is physical products become metworked live acutateable and reconfigurable software architecture / organisation / design or however one may call it becomes even more important than it is already today.

Key issues are:

  • stability (at best error-proofness) correctness; research in Haskell
  • maintainambility
  • extendability
  • modularity
  • diversity (as options for unexpected dead end routes)
  • optimized-specialisation conserving functionality-expanding-generalisation and vice versa
  • highly complex version management (dependency hell)
  • ...

File systems

Currently used tree based and machine local file systems have their limits. Sorting the same data after multiple hierarchical criteria is impossible. To give an example: Assume one owns a lot of image-file text-file sets. The small text files are of high importance (e.g. source code) while the huge images are of relatively low importance (e.g. rendered from source). Archiving different backup levels (location, redundancy level) for file types of different importance isn't possible with the basic functionalities of tree based file systems.

File system indexing usage of meta-data and file tagging only mend but do not solve the problem. Some kind of graph based file systems are needed. Graph databases (like Neo4j?) are interesting but are only crutches if implemented on top of tree based file systems.

The limitation to serial access to mass storage disk space (now changing with random access SD drives) led to the fact that current systems are still hardware near programmed and suffer from a lack of abstraction. Data must be manually serialized for persistent storage. Net based services like Google drive and Facebook already emulate this behavior. Another interesting "on top" approach is yesod with its integrated persistence.

Dependency hell

Current packet management systems suffer from the dreaded problem of dependency hell. Especially developers who install a lot of software packages in parallel are affected. Solution approaches include:

Further related information

Avoiding hidden state (a potential source of errors) can be compatible with interactive environments:

Other stuff

[yet empty]