So, if you want backups every day, you must have a tape for every day.
Sure, but it doesn't have to be a unique tape each day. Since amanda normally uses a holding area to spool to tape rather than spooling directly from the source directories, I just back up the holding area daily (to tapes HOLDING001 or HOLDING002), and when either of my two holding tapes almost fill up, I flush the holding disk to another tape set (DAILY001, DAILY002, etc).
Sometimes a single daily tape might end up holding 10 days worth of backups.
Next up, apt-get is bad about handling low disk space. Try apt-get upgrade when you're going from stable to unstable. You need to download 100MB+ of packages for a reasonably complete install. That's more than many people have in/var, which is where apt-get stubbornly insists downloaded files must go. If there's a way to change this, it's undocumented, because believe me I've looked.
I believe you, but it's not undocumented. Try
apt-get -o dir::cache::archives=/some/other/dir...
or setting the Dir::Cache::archives setting in/etc/apt/apt.conf
Or, like the other poster said, symlink the archives directory to the other partition. I don't have an easy answer to the other parts about apt-get's desire to download and upgrade all at once, but others might.
Frustrating as hell to know what you're doing and deal with people who don't believe that you do.
I have a 2-week-long series of emails between myself and
some tech support reps and managers at a relatively large computational fluid dynamics software company.
To beat all, after we stopped the software from simply segfaulting partway in when running on a display with less than 24-bit color, it wouldn't use DNS to find its license server. I had to stick in an entry in/etc/hosts.
This machine is my mp3 player walking to work, an instant on recording device, plays movies (PocketDivX), and I can read slashdot from it, not to mention the regular PDA features.
Don't think I have a solution for the MP3 or DivX parts, but the others can be handled with Handera products. My old TRGPro with Eudora Internet Suite handles online browsing, though with a limited HTML set (no frames or tables, iirc). The newer 330 model does that, and also has the instant-on voice recording, too.
Ease of programmability, I don't know about. I do know the PalmOS can handle limited Python, plus Tcl, some type of Basic, and I think some sort of Java.
I can get an expansion pack that allows me to plug in any USB keyboard and has a VGA port that will do 800x600 @ 256 colors - yes, I can put a powerpoint presentation on this and leave the laptop at home
Easy Calc's Integer mode appears to fit the bill nicely, if you already have a Palm.
Base conversions: got it. Four buttons in the bottom-left of the screen handle base-2, -8, -10, and -16. Selecting any of them will automatically reformat the number sitting on the result line.
Shift/rotate: got it, I think. At least it has << and >> buttons.
Absence of scientific/trig: not really, but in Integer mode, all those functions are hidden away.
Operator precedence: yep. Parenthesis: yep. Fonts are a reasonable size, too.
The Integer mode has a total of 31 buttons (16 hex digits, 4 base convertors, 2 shifters, &, |, the usual four arithmetic functions, Clear, Enter, and a button that looks like a Yen symbol), so the interface is pretty well uncluttered.
And it's GPL'd, so if you wanted to rip out all other modes, and make it an incredibly stripped down integer-math-only calculator, you could.
Spong(demo) works for me. Runs on pretty well any Perl 5 installation, some support for NT, and it's reasonably easy to extend.
Oh, and the degree of customization possible on "who gets notified about which services on which machines at what time, and at what severity" is truly mind-boggling. Or perhaps I boggle easily.
I'm probably missing something, and I'm
definitely biased against spreadsheets in general
for most scientific work (MSME here, working with grad students daily on this sort of thing).
But given that most engineering/scientific
spreadsheets have a format of:
Input parameters up top
Lots of formula cells doing calculations below, many of them hidden when the variable isn't important
Results cells at the bottom
I'm just not seeing the big advantage to it
versus:
Window running a shell for Python code, (or a Matlab window)
Window with $EDITOR editing Python or Matlab code
In the spreadsheet version, your variable names tend to be cell locations. In a program, you pick
meaningful names.
The complexity of writing formulas isn't terribly different, assuming you're using a language with a reasonable math/stats library (Matlab definitely qualifies, and Python should, too).
Now a spreadsheet does have mind-numbingly simple graphing, as long as you don't get too complicated. But at least in Matlab, if you have a pair of row or column matrices x and y, it's plot(x,y).
Instant gratification in a spreadsheet isn't terribly more instant than (up-arrow) (Enter) in the shell or Matlab window mentioned above.
And neither Python nor Matlab compare in learning curve to Fortran or most other languages. You could likely be competent in either of them
inside of two days.
See here for one example on projectile motion. The functions aren't required to be split out, but are good practice.
This page has a tarball of scripts that let you take a running Debian system and make a Live-CD version of it.
Last time I used it, I managed to get a kernel and enough of a root filesystem together to run an MP3 player out of a ramdisk. With a full CD of space, you could do much, much more.
Pound is a simple http/https load balancer that's been announced fairly frequently on the Zope mailing list. It appears to be very small, runs diskless and chrooted, and handles back-end servers dropping off and coming back.
As far as programmers are concerned, I'd have them take a good look at MaxM's Easy Product writeups.
I kid you not, the above product is nigh-indispensable to programmers who need to make custom Zope objects, but have trouble with some of the overhead of rolling products entirely from scratch. GO READ IT IF YOU'VE HAD TROUBLE OF THIS SORT.
Anecdotally, witness the difference between these threads on the Zope list, both from the same user:
Before,
After
I keep hearing that Debian's apt-get is so easy, and I've been tempted a couple of times. But fear will protect me: Fear that
someday I won't be able to get something I need in package form, so I'll install from source, and then the package database will
be wrong and I'll have the same problems I had with RPM. As long as I keep that fear in my mind, I'll be safe from Debian's
temptation.
Migrated a friend's PC at work from RH (something) (originally 6.2, largely upgraded to 7.2, but without glibc 2.2 I think -- weird box)
to Debian stable just recently. He likes testing
new Nessus builds, but was heading into a packaging problem in that Nessus required a newer
openssl than was in stable. Here's the solution we
used:
The proper version of openssl was in unstable, so we did an 'apt-get source openssl'
to grab the sources. Built them with 'dpkg-buildpackage' and installed them with 'dpkg -i'.
Crap. ssh depends on a particular version of
openssl, and this new one isn't it. Ergo, that last dpkg run didn't take, and the old library is still on the system, with the new one ready to take its place when we're consistent again. Double crap,
they changed the package name between stable and
unstable, too.
Ok, download the Debian 'equivs' package. It's
a far cleaner way to do what most people are
attempting with 'rpm --force-deps' -- tell the package system that you in fact *do* have a particular package installed, despite it being under another name, or installed in/usr/local (which dpkg never touches, and never queries).
Build and install equivs to satisfy the dpkg
dependency. Restart ssh; crap. ssh isn't starting,
since it appears that it really *did* depend on
that version of the library. No big deal:
Download Debianized sources for ssh and rebuild them. Debian source trees tend to be good about telling
you what other packages are needed to build them,
and in newer versions of apt, 'apt-get build-dep foopackage' will download and install all the build dependencies for foopackage.
Install that new build of ssh, built against
the new openssl libraries, and everything's happy again.
Continue with Nessus testing.
Yes, this could be done with Slack, or on a manual build procedure. But this is just to show you that
the procedures are there to allay your fear.
Worst case scenario, you keep *all* your local source builds in/usr/local (hopefully managed with stow or encap, to keep your sanity), and keep
all the Debian stuff outside there. It's not like
you're going to install a new Gnome library in/usr/local and then expect a Debian package from unstable to automatically deal with it. (Even if you did that, odds are 'equivs' would take care
of dpkg's complaints, and if/usr/local is in your library path, the program might even work -- barring libc incompatibility and similar).
The department's frowning on Linux-based PCs
because you can't get the student edition of
Matlab in Europe?
Your department shouldn't be installing student
edition on any institutional PCs anyway. Student
edition is for students' personal machines.
Also, this link says "Release 12 of MATLAB Student Version, including MATLAB 6 and
Simulink 4, is now available to students worldwide." Maybe that's not including the Linux version.
So, suffice to say I'm confused. Mathworks will sell your school all the non-student-edition copies it wants for any platform, regardless of whether you're in the US. So where's the problem?
The dependency system works fine, and RPM is nicer for packagers , since you don't have the same one-patch limit imposed by.deb.
There's not a one-patch limit. There's a pristine tarball and a.diff.gz file, sure, but that doesn't mean there's only one patch involved. The.diff.gz shows the difference between the original source tree and the Debianized one.
For example, in the Debianized Apache source tree, there's a whole directory of patches which are applied to the upstream sources during the build process:
Each can be selectively applied if you edit the build/make scripts, too. Not every package uses this selective patch method, but the really complicated ones often do (X, libc, and Apache at least, and those are just the ones I've seen personally).
No doubt about that. The average Slashdot reader probably didn't even get most of the PC jokes in the computer terminology dictionary. Like the one about "convertible" replacing "junior" -- the IBM PC Convertible and the PCJr were pretty nasty machines, even worse than first-generation PS/1 boxes.
-> *apt* x335-slink?
*apt* x335-slink is at http://debian.oftheinter.net/x335-slink/. Ask me about 'sources.list' on how to get XFree86 3.3.5 for slink via apt-get. or courtesy of xk
For those pieces I don't need the latest-greatest for, I use packages from stable- for everything else, I compile. No problem.
Right, the basic point is that slink is rock-solid stable and tested. Developers have already gone out and made slink-compatible packages for newer X, GNOME, KDE, etc., even if those aren't as well-tested as the rest of slink. In general, the #debian IRC channel has infobots that keep track of these unofficial releases.
Failing that, I've certainly built my own local, slink-compatible.deb files for a ton of stuff --
All of those above came from potato source files, and I've had zero trouble in getting them to run. Yes, occasionally I've had to compile a slightly newer version of a library to satisfy some random package's Makefile, but that's certainly no worse than rolling my own.
Provided one has a relatively recent version of apt and a reasonable development enviroment, building all these packages was a simple 'apt-get source packagename ; cd packagename-version ; debian/rules binary' -- in fact, I just built bnetd_0.4.19 (the current potato version) with an even simpler 'apt-get -b source bnetd'
So give the Debian folks a break already. They're not the ones with 100MB of errata/security fixes within a month of release. They are making it easy to upgrade a few packages as needed, with or without compiling your own.
Looking at Trumpet's selection of software, I see they sell a TCP/IP stack and a gateway/masquerading program. I can't believe people actually pay for that stuff when you've got Linux and FreeBSD which will do that for free.
Back in the old days (before 1995), Trumpet's Windows 3.1 stack was the best thing going in the market. Even if it's been surpassed since then, it was good stuff, it fit on a floppy, and it did the job. Most, if not all of the other Win31 stacks were serious payware, less flexible, etc.
Black Box makes several external power switch options that can be controlled by serial and/or touch tone. But they're not cheap.
The homebrew solution we had at the ISP I used to sysadmin for was all X-10 based. One password-capable phone responder with keypad for ~$85, and several of the lamp modules for under $10 each. Worked for power-cycling the terminal server and modem banks via phone or in person.
Redhat is a good way for people to get to know linux. After that, Debian is also an option. Note that Debian uses RPM's (thanks to Redhat) to increase its distributability.
No, Debian can deal with RPMs, but does not use them as its package format.
I've got some documentation on my particular settings for that sort of thing here. Debian GNU/Linux client, Win95 print server, HP Deskjet 600C printer.
Easy -- make a new entry in inittab, on an unused virtual console. You even get keyboard control of it if necessary. Something like:
9:23:respawn:/usr/local/bin/seti (put a less-than sign here)/dev/tty9 (and put a greater-than sign here)/dev/tty9
ought to work, though I haven't tested it explicitly myself. No parentheses, of course; bloody posting won't let me use the ampersanded or bare less-than/greater-than symbols.
Slashdot Mirror
Sure, but it doesn't have to be a unique tape each day. Since amanda normally uses a holding area to spool to tape rather than spooling directly from the source directories, I just back up the holding area daily (to tapes HOLDING001 or HOLDING002), and when either of my two holding tapes almost fill up, I flush the holding disk to another tape set (DAILY001, DAILY002, etc).
Sometimes a single daily tape might end up holding 10 days worth of backups.
I believe you, but it's not undocumented. Try apt-get -o dir::cache::archives=/some/other/dir ...
or setting the Dir::Cache::archives setting in /etc/apt/apt.conf
Or, like the other poster said, symlink the archives directory to the other partition. I don't have an easy answer to the other parts about apt-get's desire to download and upgrade all at once, but others might.
I have a 2-week-long series of emails between myself and some tech support reps and managers at a relatively large computational fluid dynamics software company.
To beat all, after we stopped the software from simply segfaulting partway in when running on a display with less than 24-bit color, it wouldn't use DNS to find its license server. I had to stick in an entry in /etc/hosts.
This machine is my mp3 player walking to work, an instant on recording device, plays movies (PocketDivX), and I can read slashdot from it, not to mention the regular PDA features.
Don't think I have a solution for the MP3 or DivX parts, but the others can be handled with Handera products. My old TRGPro with Eudora Internet Suite handles online browsing, though with a limited HTML set (no frames or tables, iirc). The newer 330 model does that, and also has the instant-on voice recording, too.
Ease of programmability, I don't know about. I do know the PalmOS can handle limited Python, plus Tcl, some type of Basic, and I think some sort of Java.
I can get an expansion pack that allows me to plug in any USB keyboard and has a VGA port that will do 800x600 @ 256 colors - yes, I can put a powerpoint presentation on this and leave the laptop at home
Done, with a combination of the 330 and Margi Presenter To Go. Tack on a Happy Hacking Cradle and you can use whatever PS/2 keyboard you like. This list of other keyboards might have other options to your liking.
Handera also has both CF and SD/MMC slots in the 330 models. No color on any Handera models yet, and they've not yet gone past OS 3.5.x.
Easy Calc's Integer mode appears to fit the bill nicely, if you already have a Palm.
And it's GPL'd, so if you wanted to rip out all other modes, and make it an incredibly stripped down integer-math-only calculator, you could.
Spong (demo) works for me. Runs on pretty well any Perl 5 installation, some support for NT, and it's reasonably easy to extend.
Oh, and the degree of customization possible on "who gets notified about which services on which machines at what time, and at what severity" is truly mind-boggling. Or perhaps I boggle easily.
I'm probably missing something, and I'm definitely biased against spreadsheets in general for most scientific work (MSME here, working with grad students daily on this sort of thing).
But given that most engineering/scientific spreadsheets have a format of:
I'm just not seeing the big advantage to it versus:
In the spreadsheet version, your variable names tend to be cell locations. In a program, you pick meaningful names.
The complexity of writing formulas isn't terribly different, assuming you're using a language with a reasonable math/stats library (Matlab definitely qualifies, and Python should, too).
Now a spreadsheet does have mind-numbingly simple graphing, as long as you don't get too complicated. But at least in Matlab, if you have a pair of row or column matrices x and y, it's plot(x,y).
Instant gratification in a spreadsheet isn't terribly more instant than (up-arrow) (Enter) in the shell or Matlab window mentioned above.
And neither Python nor Matlab compare in learning curve to Fortran or most other languages. You could likely be competent in either of them inside of two days.
See here for one example on projectile motion. The functions aren't required to be split out, but are good practice.
Haven't tried the latter, but it may fit the bill. DocumentLibrary home
According to this page, the PowerMac 7200 (a 601-based PCI Mac) should work fine.
It's the "universal operating system", at least for the Linux side of things. 11 architectures are scheduled to be supported in the upcoming release.
This page has a tarball of scripts that let you take a running Debian system and make a Live-CD version of it.
Last time I used it, I managed to get a kernel and enough of a root filesystem together to run an MP3 player out of a ramdisk. With a full CD of space, you could do much, much more.
Pound is a simple http/https load balancer that's been announced fairly frequently on the Zope mailing list. It appears to be very small, runs diskless and chrooted, and handles back-end servers dropping off and coming back.
As far as programmers are concerned, I'd have them take a good look at MaxM's Easy Product writeups.
I kid you not, the above product is nigh-indispensable to programmers who need to make custom Zope objects, but have trouble with some of the overhead of rolling products entirely from scratch. GO READ IT IF YOU'VE HAD TROUBLE OF THIS SORT.
Anecdotally, witness the difference between these threads on the Zope list, both from the same user: Before, After
Mi-Notepad
Migrated a friend's PC at work from RH (something) (originally 6.2, largely upgraded to 7.2, but without glibc 2.2 I think -- weird box) to Debian stable just recently. He likes testing new Nessus builds, but was heading into a packaging problem in that Nessus required a newer openssl than was in stable. Here's the solution we used:
Yes, this could be done with Slack, or on a manual build procedure. But this is just to show you that the procedures are there to allay your fear.
Worst case scenario, you keep *all* your local source builds in /usr/local (hopefully managed with stow or encap, to keep your sanity), and keep
all the Debian stuff outside there. It's not like
you're going to install a new Gnome library in /usr/local and then expect a Debian package from unstable to automatically deal with it. (Even if you did that, odds are 'equivs' would take care
of dpkg's complaints, and if /usr/local is in your library path, the program might even work -- barring libc incompatibility and similar).
The department's frowning on Linux-based PCs because you can't get the student edition of Matlab in Europe?
Your department shouldn't be installing student edition on any institutional PCs anyway. Student edition is for students' personal machines.
Also, this link says "Release 12 of MATLAB Student Version, including MATLAB 6 and Simulink 4, is now available to students worldwide." Maybe that's not including the Linux version.
So, suffice to say I'm confused. Mathworks will sell your school all the non-student-edition copies it wants for any platform, regardless of whether you're in the US. So where's the problem?
There's not a one-patch limit. There's a pristine tarball and a .diff.gz file, sure, but that doesn't mean there's only one patch involved. The .diff.gz shows the difference between the original source tree and the Debianized one.
For example, in the Debianized Apache source tree, there's a whole directory of patches which are applied to the upstream sources during the build process:
mwr@ch208h:~/apache-1.3.20/debian/patches$ ls
ab_round_robin_support phf_dot_log
apxs_assumes_dso regex_must_conform_to_posix_for_LFS_to_work
debian_config_layout server_subversioning
debian_ps_is_brutal suexec_of_death hurd_compile_fix_for_upstream
usr_bin_perl_owns_you mime_type_fix
Each can be selectively applied if you edit the build/make scripts, too. Not every package uses this selective patch method, but the really complicated ones often do (X, libc, and Apache at least, and those are just the ones I've seen personally).
No doubt about that. The average Slashdot reader probably didn't even get most of the PC jokes in the computer terminology dictionary. Like the one about "convertible" replacing "junior" -- the IBM PC Convertible and the PCJr were pretty nasty machines, even worse than first-generation PS/1 boxes.
Right, the basic point is that slink is rock-solid stable and tested. Developers have already gone out and made slink-compatible packages for newer X, GNOME, KDE, etc., even if those aren't as well-tested as the rest of slink. In general, the #debian IRC channel has infobots that keep track of these unofficial releases.
Failing that, I've certainly built my own local, slink-compatible .deb files for a ton of stuff --
All of those above came from potato source files, and I've had zero trouble in getting them to run. Yes, occasionally I've had to compile a slightly newer version of a library to satisfy some random package's Makefile, but that's certainly no worse than rolling my own.
Provided one has a relatively recent version of apt and a reasonable development enviroment, building all these packages was a simple 'apt-get source packagename ; cd packagename-version ; debian/rules binary' -- in fact, I just built bnetd_0.4.19 (the current potato version) with an even simpler 'apt-get -b source bnetd'
So give the Debian folks a break already. They're not the ones with 100MB of errata/security fixes within a month of release. They are making it easy to upgrade a few packages as needed, with or without compiling your own.
Back in the old days (before 1995), Trumpet's Windows 3.1 stack was the best thing going in the market. Even if it's been surpassed since then, it was good stuff, it fit on a floppy, and it did the job. Most, if not all of the other Win31 stacks were serious payware, less flexible, etc.
Not without precedent -- look into some older kernels for xiafs. IIRC, named after its creator, Francis(?) Xia.
Besides, it's not like anybody ever refused to submit filesystem patches to old Bob Ext or his son (Bob Ext II)
The homebrew solution we had at the ISP I used to sysadmin for was all X-10 based. One password-capable phone responder with keypad for ~$85, and several of the lamp modules for under $10 each. Worked for power-cycling the terminal server and modem banks via phone or in person.
www.smarthome.com is a good place to start.
No, Debian can deal with RPMs, but does not use them as its package format.
Reasons to Choose Debian -- dated before the 2.1 release, but pretty much accurate even today.
I've got some documentation on my particular settings for that sort of thing here. Debian GNU/Linux client, Win95 print server, HP Deskjet 600C printer.
Easy -- make a new entry in inittab, on an unused virtual console. You even get keyboard control of it if necessary. Something like:
/dev/tty9 (and put a greater-than sign here) /dev/tty9
9:23:respawn:/usr/local/bin/seti (put a less-than sign here)
ought to work, though I haven't tested it explicitly myself. No parentheses, of course; bloody posting won't let me use the ampersanded or bare less-than/greater-than symbols.