Daniel Kalny's GA144 projects' YouTube channel:
410 karma · joined January 8, 2013
If it were a complex application it wouldn't be very forthy would it? Factor the problem instead of trying to factor a preconceived solution.
> 2. What is “sourceless programming”? Where is a good place to learn more about it?
Sourceless programming was used in Okad a vlsi design tool written by Chuck Moore.
http://www.ultratechnology.com/mofe16.htm
Brad Nelson also experimented with sourceless forth:
https://docs.google.com/presentation/d/1wL2eqf7eHGEybsK0C4MU...
Although there have been some widespread and fairly comprehensive implementations of anarchism, namely the Makhnovists in the Ukraine and the Spanish Revolution in Catalonia, Aragon, Andalusia, and some parts of the Valencian Community, anarchism is more of a political tension "from where you are standing right now" than an attempt to conquer a territory to establish anarchism. That should follow from the name itself.
https://theanarchistlibrary.org/library/alfredo-m-bonanno-th...
The Situationist movement had some enduring effect on French culture from the first-person perspective. (Situationism is not anarchist, but it is libertarian and communist). The Spanish revolution less so, because it was followed by General Franco's rule.
I thought this article/transcript was of interest to hackernews in a large part due to one of the two authors being the author of the Open Whisper Systems Signal SMS app.
It may be easier to have everyone use the same software and hardware platform everywhere. After all we do want interoperability and we do want everyone to play well with others, but, standardization and portability is a push to stop people from trying new things. The push to standardize everything is an unfortunate consequence of not having a separation of concerns, separate concerns such as content and UI.
The current state of software development has huge issues with needless complexity resulting from poorly chosen abstractions.
Gopher and IRC make it possible to use any client of your choosing, thus keeping innovation and improvements accessible to anyone with an idea.
The web has effectively killed innovation in operating systems. A clean and consistent system will be out of reach as long as this web app nonsense continues.
"Chuck Moore, the inventor of Forth and ColorForth programming languages, gives a presentation on writing "1x software," or how to avoid common sources of bloat in software. Topics covered include: what it means to be Forth (as distinct from other languages), how ColorForth is simpler still than Forth, how common system services such as files, windows, and even local variables, complexify (complect) the software, the impact of bloat, maintenance on that bloat, etc. And, as is usual for Chuck, deeply philosophical thoughts as well."
...and consequently limited driver support. Copyleft is permissive. There's no need for non-copyleft licensing unless you want restrictive proprietary licensing somewhere or sometime.
http://catid.mechafetus.com/news/news.php?view=281
Ideas for Online Codes [Comment] by catid posted (>30 days ago) 9:35pm Thu. Jan 26th 2012 PST Online Codes are an unpatented approach to rateless forward error correction (FEC) codes from a 2002 paper by Petar Maymounkov. I first learned about Online Codes from a wikipedia article and since then I have been reading as much as I can about how to implement them with good performance.
Since that paper was published, Luby et al have made fantastic advancements in rateless error codes, culminating in RaptorQ last year. Unfortunately they decided to patent their algorithms, which makes their wonderful algorithms worthless for almost everyone on the Internet. So, roll back the clock by a decade and start over. sigh
Online Codes are a great place to start. I like the layered approach where there is an inner code and an outer code. After reading about a lot of modern implementations I have some ideas to try and see what will help Online Codes reach good performance:
(1) Peeling decoder. This is an unpatented approach to decoding sparse low-density parity check (LDPC) codes. It's O(N) and fast, and is pretty easy to get running.
(2) Gaussian elimination decoder. This is also an unpatented approach used to solve linear systems of equations when the equations are not sparse.
(3) Combine (1) and (2). This is an unpatented approach that provides maximum likelihood decoding in roughly O(N) for good performance. I noticed that the "Raptor Codes" monograph includes a description of this algorithm, so it must be excellent in practice. I've implemented it myself and managed significant performance (300 MB/s) before optimization. I have a few ideas for how to optimize this:
+ Reduce the number of variables needed by analyzing how data is passed between parts of the algorithm and eliminating unneeded data. + Profiling the application to see where hot spots are, and storing pre-processing in parts of the code that are taking up less time. + When back-substituting the Gaussian elimination decoded (2) symbols back into the peeling decoded (1) symbols, the check matrix is pretty dense. Borrowing a trick from windowed modular exponentiation, combinations of bits can be precomputed and then stored in a table to greatly reduce the number of XORs required. I think this can be implemented without any additional memory since at that point in the algorithm many of the received rows have been copied over to the output file. + Reduce the number of memory copies by waiting for memcpy() until back-substitution and using memxor() where possible to avoid the copy.
(4) Use two inner codes instead of one. The second inner code will be based on GF(256) octets instead of GF(2) like the rest of the check matrix. Since the normal overhead is low, adding just a few more check matrix rows in a higher field should help out the recovery properties a lot. This seems like a logical extension to the layered approach of Online Codes.
(5) Decode all codes at once. The outer code might be combined with the inner codes into one large matrix to solve. This would improve decoding performance to that of the maximum likelihood decoder, and should work well with the decoder I'm writing. We'll see...
(6) Since A = Decode(Encode(A)) and A = Encode(Decode(A)), the code can be made systematic by precomputing Decode(A) on the transmitter, and then running Encode() forward so that the first symbols sent are equal to the input data file. This can reduce processing time but still allows check symbols to be generated afterwards with good recovery properties. There should be a lot of room for optimization on the transmitter side too since it already knows what the output should be.
(7) Raptor codes are using some kind of "permanent inactivation" thing that makes the outer code more complicated but apparently helps with the recovery properties when the number of symbols is lower. Might be patented and unusable, we'll see..
Online Codes: https://www.cs.nyu.edu/media/publications/TR2002-833.pdf
Rateless Codes and Big Downloads: https://pdos.csail.mit.edu/~petar/papers/maymounkov-bigdown-... (Start here)
GitLab bought Gitorious so they could shut it down, not so they could give it to someone else. That is the purpose of acquisitions within the same field.
Gone are the major performance issues with exponential merges and more recently, pushing large files.
https://www.mail-archive.com/darcs-users@darcs.net/msg18423....
https://www.mail-archive.com/darcs-users@darcs.net/msg18425....
After having used git, darcs is a joy to use.
http://www.reddit.com/r/tinycode/comments/2rzuwp/da_here_h_2...
http://www.reddit.com/r/Forth/comments/2s0g4a/da_here_h_2_h_...
I think there is an opening again for Forth in the Internet of Things. That's many low-power (and thus) small computers.
http://www.alibaba.com/trade/search?fsb=y&IndexArea=product_...
This sounds like it could be a great fit for Software Defined Radio.
I use darcs because we would all enjoy more innovation if were to resist the inertia of the status quo and work on improving the tools we like. Unfortunately git's slipshod user interface design can't be easily fixed through incremental development and the underlying model won't be changed.
git could not switch from their history centric model to darcs' patch centric model and fix the schizophrenic ui without breaking everything built around git. In such a case a different project is useful. See python2 vs python3.