All 10 years that I have.
All 10 years that I have.
There's no alt.* yet at all, in 1981, but this was just posted "today" to fa.info-cpm:
Keith Petersen (W8SDZ@MC) has uploaded the following files for those
of you with the APPLE II with the Microsoft Z80 cards and CP/M. We
suggest that you capture MC:CPM;APBOOT MAC (or MC:CPM;APMBOT ASM),
assemble it, and use it with
the MC:CPM;APMODM 21ASM or MC:CPM;APMODM 2ASM. Assemble either APMODM
and you can throw away APBOOT. From there you can use APMODM to grab
whatever other files of interest from MC:CPM; or the various Remote
CP/M systems around the country (see MC:CPM;RCP/M NOS and MC:CPM;RCP/M
INFO for more details).
1 APBOOT MAC 0 +235
1 APBYE ASM 4 +764
1 APHIGH MEMASM 0 +310
14 APMBOT ASM 1 +500
1 APMODM 21ASM 7 +550
1 APMODM 2ASM 7 +832
1 APMODM DOC 0 +908
1 APXMOD ASM 4 +848
I'm ending it when my archive ends. If google or someone wants to donate more material I'll consider running it further.
I'd like to get to 1994 myself, so I can read my own 1st post.
One commit per tested bugfix. One commit per semi-tested feature. One commit per update to design spec. One commit per update to docs (if not included in a feature/bugfix commit). Also, one merge commit per non-fastforward, non-rebased merge from a feature or bugfix branch can easily bloat the numbers. Plus you can choose to make multiple commits while within those branches, which both bloats the numbers greatly, and helps with backing out if you get into that broken state you mention and can't find your way out.
Also, you can get seriously more productive by increasing your iteration rate. No matter what resources need to be thrown at the test infrastructure etc to allow an increase. This is why Debian, which used to iterate once a day, now pushes out updates to unstable 6 times a day (with CD builds etc) and testing 2, IIRC,
While basically true, an interesting ration is LOC/commits. In one of my projects, the ratio is 5.35. Another, 5.01.
I started ikiwiki in 2006 and have since committed 10262 times. Some of those were web-based edits committed to its wiki's git repository, most were code changes.
Wow, it was under $1000 when I paid this morning.
Also interesting that someone paid $500. And 3 others, >= $200.
Also, Gish is x86-64, the rest x86-32 (except World of Goo, which works with either).
The ISS crew time needed to deal with mundane crap caused by their poorly designed computer infrastructure is, however, absurdly expensive.
Solved problem from the 1970's. Answer: UUCP.
I suspect that NASA doesn't run servers on the ISS though. Their computer model seems to be ancient, proprietary, space-hardened embedded stuff for mission critical needs, and a pile of disposable laptops for crew needs. That's probably crippling their network infrastructure in many ways.
Every app you run, when it was started, when it was closed.
If an app crashes, the fill list of installed apps (including homebrew); plus information like df, ps, etc.
LunaSysMgr has a hook in it to palm://com.palm.contextupload/contextUpload
There is a "contextupload" ipkg; all it contains is the daemon and dbus hook.
I haven't found which piece handles writing to
So FWIW, I have "Background Data Collection" set to off, that did not stop the Pre sending those logs to Palm. I'm sure that that switch does prevent sending your location info to the Google, which makes it doubly unsettling that it's still sent to Palm, no?
I actually have the backup service enabled, but I would not expect it to "back up" my GPS location,
and the data collection I found is pretty clearly not done as part of that backup.
Any given program will expand to fill available memory.