Date | Commit message (Collapse) |
|
Trying to install pandoc on an x86-64 Debian stable system says:
> Need to get 15.2 MB of archives.
> After this operation, 117 MB of additional disk space will be used.
My laptop is on metered Internet, now, and low on disk space, so
installing pandoc is too expensive.
There's also dozens of incompatible Markdown flavors out there,
most of which don't really handle manpages.
Updating the website now requires olddoc 1.8.0 (which is much
smaller than pandoc), but I'm the only one with that burden. On
the flipside more users can update and read the manpages locally
without extra software, since nearly every developer's *nix
system has man(1) command, unlike pandoc.
|
|
bogomips.org is due to expire, soon, and I'm not willing to pay
extortionists at Ethos Capital/PIR/ICANN to keep a .org. So
it's at yhbt.net, for now... Identity is overrated.
Tor users can use .onions and kick ICANN to the curb:
torsocks w3m http://rainbows.ou63pmih66umazou.onion/
torsocks git clone http://ou63pmih66umazou.onion/rainbows.git/
torsocks w3m http://ou63pmih66umazou.onion/rainbows-public/
While we're at it, switch news.gmane.org => news.gmane.io
(but I suspect that'll need to be resynched since our mail
"List-Id:" header is changing).
|
|
Let's Encrypt is working well for us and having fewer domains
reduces subjectAltName bloat to speed up connection
establishment
HTTP will remain working indefinitely since some old systems
do not have modern TLS stacks.
|
|
wrongdoc was difficult to maintain because of the tidy-ffi
dependency and the HTML5 changes in Darkfish could not be
handled well by Tidy.
olddoc is superior as it generates leaner HTML which loads faster,
requires less scrolling and less processing power to render.
Aesthetic comparisons are subjective of course but completely
unimportant compared to speed and accessibility.
The presence of images and CSS on the old (Darkfish-based) site
probably set unreasonable expectations as to my ability and
willingness to view such things. No more, the new website is
entirely simple HTML which renders well with even the wimpiest
browser (hell, olddoc even tries to generate readable raw HTML).
|
|
We're migrating to a new public-inbox[1] + mailing list
rainbows-public@bogomips.org
[1] http://public-inbox.org/
|
|
RubyForge is going away, so we must migrate the homepage.
The mailing list will be migrated, soon.
|
|
-N/--no-default-middleware needs a corresponding manpage entry.
Additionally, the Rack::Chunked/ContentLength middleware comment
is out-of-date as of unicorn v4.1.0
|
|
pandoc 1.8 no longer supports this, and we don't need it anyways
since we only generate documentation from our repository.
|
|
Clearly users need to know about more options
|
|
They're probably ready for general use in a very limited
capacity...
|
|
They're not bad with slow clients a previously thought.
|
|
The WebSocket protocol is still undergoing changes and unused.
We won't waste time supporting it until it's finalized and
doesn't break HTTP.
|
|
We still use and define Rev internally, but that's
mostly just manual labor of converting stuff over.
|
|
This is also our website, so we need to document the new
Cool.io-based concurrency options for users and point
existing Rev* users to it.
|
|
It still burns CPU at the first sign of doing anything
interesting, so stop it. Ruby 1.9 is the future :P
|
|
It is a common base so we can share documentation tasks
more easily with Unicorn and it ensures our RDoc no longer
has JavaScript in it!
|
|
It hits 100% CPU usage and Rev's 1.8 support when mixed
with threads is currently suboptimal. Unfortunately
our tests can not check for 100% CPU usage, so I had to
*gasp* confirm it by actually starting an app :x
This appears to be a fixable bug in Rev, however, and
we'll try to fix it as soon as we have time.
|
|
I still have a hard time keeping track of what's capable of
what.
|
|
|
|
Rev 0.3.2 makes performance with Threads* under Ruby 1.8
tolerable.
|
|
working_directory and Worker#user got added over time, so
recommending Dir.chdir and Process::UID.change_privilege
is bad.
|
|
We'll export this across the board to all Rack applications
to sleep with. This provides the optimum method of sleeping
regardless of the concurrency model you choose. This method
is still highly not recommended for pure event-driven models
like Rev or EventMachine (but the threaded/fiber/actor-based
variants are fine).
|
|
|
|
|
|
manpage was blatantly copied from the Unicorn one but headers
were never updated.
|
|
This should be like RevThreadSpawn except with more predictable
performance (but higher memory usage under low load).
|
|
|
|
|
|
Guess I'll have to make the Revactor model work with that.
|
|
|
|
Patches submitted to rev-talk, awaiting feedback and
hopefully a new release.
|
|
|
|
This will hopefully make many things clearer about the project.
|
|
|
|
No tests yet, but the old "gossamer" and "rainbows" branches
seem to be basically working.
|