Speaking of changing your password, I think I last logged in in 2007 and my password was still 1999 vintage until today. Oops. Disappointed the account was not cracked.
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:LMODEM on MC to get MC:CPM;CRCK COM and 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).
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,
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.
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.
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.
I particularly like how init is "started" before the kernel is "booted". The "automounter" is also a nice touch. It's also impressive how the kernel boots in exactly 1 second every time.
echo "Custom Linux Pseudo Bootstrapper V1.0 - by Mark Walker" echo "WEB: http://www.androidfanatic.com/" echo "EML: admin@androidfanatic.com" echo " " sleep 1 echo "Starting init process" sleep 1 echo "INIT: Debian booting....." sleep 1 echo "Running Linux Kernel" sysctl -w net.ipv4.ip_forward=1 sleep 1 echo "AutoMounter started" sleep 1 echo "Type EXIT to end session" echo "Make sure you do a proper EXIT for a clean kill of Debian!" echo " "
chroot $mnt/bin/bash
On the other hand, my prediction re debootstrap was wrong. Rather than just use the shell script as designed, the creator of this thing ships an entire pre-built debian system that's chrooted into. Amusingly, this includes a root/.bash_history showing every command he ran while setting it up. (It also includes 104 mb of cached debs in/var, etc.)
All the video shows is debootstrap being run in a terminal on, presumably, a G1 phone.
Since debootstrap is a shell script that builds a debian chroot and is designed to be run on any linux system, that is not a significant accomplishment, is it?
That's the "installer" portion. The "bootloader" portion would appear to consist of something like:
#!/bin/sh chroot/debian
Anyway, it's nice to see interest in running Debian on these devices, I guess..
FWIW, the win32-loader is interesting in that it gets compiled using entirely free software that's all available in Debian. Getting this to be true of every bit of it was one of the trickier things in developing it. http://packages.debian.org/win32-loader
It's also possible to run it in wine, it won't do anything, but you can see the dialogs --good enough for the (very little bit of) testing/development that I've done on it.
The win32-loader is mostly the work of Robert Millan, who I'm sure like most of us has several licensed copies of Windows, even if he doesn't want them.
I'm sure that someone will figure out a way to boot linux from vista eventually. In the meantime, I understand that vista has fairly extreme system requirements, so there's a whole load of machines that won't be able to run it, and the installer seems like a nice advocacy move to switch those away from the obsolete version of windows they're stuck with, and over to linux.
The current implementation for Debian is different than what Ubuntu is working on. goodbye-windows.com just downloads the two files (kernel, initrd) that let the completely standard Debian installer boot, installs a grub bootloader and uses it to convince windows to boot linux. Thereafter it's identical to what would happen if you netboot the Debian Installer.
d-i does allow optional resizing of the windows partition and setting up a dual-boot system. It does not scan windows for settings or the like.
I think it's indicative of the quality of this zdnet article that it attributes a page I maintain to Martin Schulze. More details in my blog entry, here:
Interesting how you ignored 90% of the substance of my post and latched on to something that comes down to the standard full-disclosure-or-not argument. Do you speak for the Mozilla project?
Bugzilla seems to encourage this with its system of various ways of voting on a bug, which encourages users to advocate their pet bug in order to get it fixed. I've seen this advocacy spill over into projects that don't use bugzilla recently, and IMHO it just causes a lot of distracting noise.
I'm flabbergasted that the mozilla security people seem to think that "hiding" a previously public bug after it's noticed that it has security ramifications is an effective way to keep black hats from noticing it.
I think it's safe to assume that black hats interested in finding 0-day security holes in mozilla have already, or soon will create a mirror of the bugzilla archive, with history. Then they can look for bugs that are suddenly removed from the public bugzilla archive, and have some very good candidates for fresh security holes.
And there's no way the mozilla security people can effectively combat this. At best they get into a technology arms race with the black hats, trying to figure out what techniques they're using to spider and mirror the archive.
Once a bug is posted to a public bug tracking system, even if it's only been there for an hour, you might as well give up and assume it's widely publically known.
Oh and in my personal experience, the best way to get a security bug fixed once you discover it is to immediatly write an exploit, clearly flag the bug as a security hole, and post it to a public forum with a sifficuently broad readership that someone in a position to fix the bug will, be that the project's BTS or bugtraq.
Slashdot Mirror
Speaking of changing your password, I think I last logged in in 2007 and my password was still 1999 vintage until today. Oops. Disappointed the account was not cracked.
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 :LMODEM on MC to get MC:CPM;CRCK COM and
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).
MC:CPM;
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 /var/context/ yet.
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.
Here is the actual code from the bootdeb script.
I particularly like how init is "started" before the kernel is "booted". The "automounter" is also a nice touch. It's also impressive how the kernel boots in exactly 1 second every time.
echo "Custom Linux Pseudo Bootstrapper V1.0 - by Mark Walker"
echo "WEB: http://www.androidfanatic.com/"
echo "EML: admin@androidfanatic.com"
echo " "
sleep 1
echo "Starting init process"
sleep 1
echo "INIT: Debian booting....."
sleep 1
echo "Running Linux Kernel"
sysctl -w net.ipv4.ip_forward=1
sleep 1
echo "AutoMounter started"
sleep 1
echo "Type EXIT to end session"
echo "Make sure you do a proper EXIT for a clean kill of Debian!"
echo " "
chroot $mnt /bin/bash
On the other hand, my prediction re debootstrap was wrong. Rather than just use the shell script as designed, the creator of this thing ships an entire pre-built debian system that's chrooted into. Amusingly, this includes a root/.bash_history showing every command he ran while setting it up. (It also includes 104 mb of cached debs in /var, etc.)
Anyway, very amusing.
All the video shows is debootstrap being run in a terminal on, presumably, a G1 phone.
Since debootstrap is a shell script that builds a debian chroot and is designed to be run on any linux system, that is not a significant accomplishment, is it?
That's the "installer" portion. The "bootloader" portion would appear to consist of something like:
#!/bin/sh /debian
chroot
Anyway, it's nice to see interest in running Debian on these devices, I guess..
FWIW, the win32-loader is interesting in that it gets compiled using entirely free software that's all available in Debian. Getting this to be true of every bit of it was one of the trickier things in developing it. http://packages.debian.org/win32-loader
It's also possible to run it in wine, it won't do anything,
but you can see the dialogs --good enough for the (very little bit of) testing/development that I've done on it.
The win32-loader is mostly the work of Robert Millan, who I'm sure like most of us has several licensed copies of Windows, even if he doesn't want them.
I'm sure that someone will figure out a way to boot linux from vista eventually. In the meantime, I understand that vista has fairly extreme system requirements, so there's a whole load of machines that won't be able to run it, and the installer seems like a nice advocacy move to switch those away from the obsolete version of windows they're stuck with, and over to linux.
d-i does allow optional resizing of the windows partition and setting up a dual-boot system. It does not scan windows for settings or the like.
Oh BTW, while it's slashdotted, you can see it at http://www.mirrordot.org/stories/f592f4a8f9a66105d 885ff7a49228380/index.html
I think it's indicative of the quality of this zdnet article that it attributes a page I maintain to Martin Schulze. More details in my blog entry, here:
7 -06-11-28.html
http://kitenet.net/~joey/blog/entry/secfud-2005-0
Surely the juxtaposition of this story with the BSGng one was not accidental?
Interesting how you ignored 90% of the substance of my post and latched on to something that comes down to the standard full-disclosure-or-not argument. Do you speak for the Mozilla project?
Bugzilla seems to encourage this with its system of various ways of voting on a bug, which encourages users to advocate their pet bug in order to get it fixed. I've seen this advocacy spill over into projects that don't use bugzilla recently, and IMHO it just causes a lot of distracting noise.
I'm flabbergasted that the mozilla security people seem to think that "hiding" a previously public bug after it's noticed that it has security ramifications is an effective way to keep black hats from noticing it.
I think it's safe to assume that black hats interested in finding 0-day security holes in mozilla have already, or soon will create a mirror of the bugzilla archive, with history. Then they can look for bugs that are suddenly removed from the public bugzilla archive, and have some very good candidates for fresh security holes.
And there's no way the mozilla security people can effectively combat this. At best they get into a technology arms race with the black hats, trying to figure out what techniques they're using to spider and mirror the archive.
Once a bug is posted to a public bug tracking system, even if it's only been there for an hour, you might as well give up and assume it's widely publically known.
Oh and in my personal experience, the best way to get a security bug fixed once you discover it is to immediatly write an exploit, clearly flag the bug as a security hole, and post it to a public forum with a sifficuently broad readership that someone in a position to fix the bug will, be that the project's BTS or bugtraq.