A preservation of assembler code and small areas of code for base operating systems are necessary for a stable function.There is no easy fix. For example GNU software that drags in a number of unmaintainable dependencies still attribute to this problem even though it is "open-source".
Agreed. Actually my PhD is on digital preservation of software (games), where archiving is a close relative to the problem.
The main thing is that there is "currently" no money in it and too many people these days are in for a quick buck. They don't care about the future or their users in the future.
There is no easy fix. For example GNU software that drags in a number of unmaintainable dependencies still attribute to this problem even though it is "open-source". Not only does something need to be open-source but also architected in a responsible manner.
Quite off topic.
Last I heard, the lifetime expectation of SSDs is spec'ed as "at least 10 years", obviously ignoring flash wear out due to too many writes. The real-world life time of disks in large quantities is about 5-7 years; after that older disks are no longer economically viable (too little storage capacity per physical space and power consumption, often quoted as GB/l and GB/W), and it becomes cheaper to copy the data to newer disks.... it will be there for 30 years: for normal use I preffer ufs. I use magnetic disks, not flash rom, for archiving, but the firmware of the disc is sure flash rom and the whole data goes with it. And are modern magnetic disks or tapes with so dense data reliable?
There is a pretty large industry of archiving software and systems. About a decade ago I dealt with a handful of startups that were pretty successful in that space; I think they were called "Archivas" and "Permabit". I think they have been absorbed into larger companies in the meantime, but their products still exist. There is also extensive research on the problem of creating self-describing data formats, which allow data to still be decoded hundreds of years from now, when we have long forgotten the data structures in a JPG or PDF file. I think the experts in this field consider this to be a solved problem, although perhaps the solutions have not been widely deployed yet (that takes decades). My former colleague Raymond Lorie worked on this, and has a long list of publications that have helped solve this problem. Alas, he was taken from us by cancer shortly after his retirement; he was a real gentleman and a scholar.And of course the format of the data must be readable in the future. Archiving is not a simple problem, is not solved, and unfortunately it seems there is no much interest.
so the failure of individual devices is merely an inconvenience and a cost. Data is then copied regularly to newer devices
cd ; ls ; cd ; ls ; cd ; ls ; cd ; ls
. Yikes.In fact, the tk toolkit can be used natively from Python scripts, too (it's called “tkinter”). So you can write GUI-based Python programs that work without change on BSD, Linux, Windows and Mac. I've learned tcl a long time ago, but since I switched to Python, I never looked back. It's so much easier to use, and you get results much more quickly. In fact, when you write down a draft of your program in pseudocode, it's already valid Python syntax. Well, almost.With tcl you have the widget toolkit tk, a very comfortable way without much effort and lines of code of writing GUIs.
the tk toolkit can be used natively from Python scripts
Of course, Tkinter uses libtk, which in turn depends on libtcl, so these are installed as dependencies.Not exactly, it seems the whole Tcl is bundled into pyton for making Tk as Tkinter available.
Indentation is a natural and unambiguous way to structure code, and at the same time it leads to very compact and readable code. Actually I think that using things like curly braces or begin/end keywords is just an error-prone workaround from the “old ages” of programming languages.I prefer the original and meagerer: Tcl. It is easy enough to use. And python, where indentation seems to have a semantic meaning, is strange to me.
#!/bin/sh
inline_c("
#include <X11/Xlib.h>
Display *d;
")
if [ -e "/some/file/path" ]; then
inline_c("d = XOpenDisplay(NULL);")
...
else
...
fi
There are Python bindings for many C libraries.I think the issue for me when using Tcl or Python is that, yes you get a GUI library, but you loose easy access to all other native C libraries (which is still king in the world of *nix).
You mean bindings for GUI toolkits, right? There is about a dozen of them (maybe even more). Among the smallest and lightest are Tkinter (Tk) and FLTK. They are lightweight and have very few dependencies, and they are portable beyond UNIX so you can easily write portable GUI programs that run on Windows and Mac, too.So in Python you would need to create a binding (https://docs.python.org/2/extending/extending.html) (which I find a too much effort to be worth it) or use an existing binding. These bindings however drag in all sorts of dependencies that I am not prepared to have. They also become obsolete and replaced far too often.
Please forgive me, but to my eyes that looks like combining two ugly languages, forming an even uglier chimera language.I think the nicest solution for me would be allowing inline C within sh. i.e
#!/bin/sh -
BUTTONS=' Power-off :7, Reboot :8, Cancel :9'
DEFAULT='Cancel'
cat <<-EOM | xmessage -buttons "$BUTTONS" -default "$DEFAULT" -center -file -
Please confirm shutdown of $(hostname).
EOM
case $? in
7) shutdown -p now ;;
8) shutdown -r now ;;
esac
I think the issue for me when using Tcl or Python is that, yes you get a GUI library, but you loose easy access to all other native C libraries (which is still king in the world of *nix).
So in Python you would need to create a binding (https://docs.python.org/2/extending/extending.html) (which I find a too much effort to be worth it) or use an existing binding. These bindings however drag in all sorts of dependencies that I am not prepared to have. They also become obsolete and replaced far too often.
With C, you have Xaw (which is a little bit bare but good enough for scripts) but then direct access to other libs. I find this much cleaner.
I think the nicest solution for me would be allowing inline C within sh. i.e
Code:#!/bin/sh inline_c(" #include <X11/Xlib.h> Display *d; ") if [ -e "/some/file/path" ]; then inline_c("d = XOpenDisplay(NULL);") ... else ... fi
But that is either a pipedream or will simply require me to use a different shell and thus drag in more dependencies
history
, but discovered that using the command history didn't boost my day-to-day shell skills.