estinc.com · Domains · Slashdot Mirror

DLT + BRU by green+pizza · 2001-05-27 12:01 · Score: 2 · on Tape Backups for Personal Use, Using Linux?

The only tape drives I've ever had problems with have been the ghetto-cheap Best Buy discount aisle variety.

Get a decent tape drive:
http://www.quantum.com/Products/Quantum+l+DLTtape/ DLT+8000/Default.htm

And a decent app:
http://www.estinc.com/products.php

Or if perhaps you need a slightly larger tape "drive":
http://www.storagetek.com/products/tape/9310/

Spam, spam, the funny-tasting ham by Eric+Green · 2001-01-22 10:53 · Score: 3 · on Using GPL/BSD Code In Closed Source Projects?

One thing to bear in mind is that this is Unix. Unix was conceived under the principle of "many small programs chained together". There is no reason why the communications protocols involved in a chess game cannot be created that same way. If I can do it for a tape server, I don't see why it couldn't be done for a chess server. And if the program is many small programs chained together, then those small programs that happen to include GPL'ed code can be released as GPL'ed programs without compromising the closed-source nature of the rest of the system. Everybody wins. People who want more GPL'ed software get more GPL'ed software, you get to use that GPL'ed software yourself from your non-GPL'ed software, and you get a more reliable architecture to boot (since a Unix-style "many small programs chained together" system can be MUCH more easily tested than some big monolithic monstrosity -- each component can be tested independently to insure proper operation).

-E

Real world objects, procedural objects by Eric+Green · 2001-01-09 04:34 · Score: 2 · on The Object Oriented Hype

One thing that Python makes easy is the concept of a procedural object -- a chunk of code that performs some task. For example, in BRU Professional the tape switcher (that switches tapes in a tape loader as you proceed in a network backup) is a procedural object. The high level backup/restore/verify code that actually manages tapes initializes the tape switcher with a list of what slots in the tape changer to go to for which volume in the backup, then passes this tape switcher object down to the lowlevel code that actually touches the hardware. The lowlevel code then calls the tape switcher object's "load a volume" method whenever it needs to change tapes.

I can't think of anything more procedural than an actual tape backup, but even there many things can be easily abstracted out as objects -- not just the high level stuff like "drive" and "tape", but also lower-level procedural items such as changing tapes.

-E

Pipes are *NOT* dead! by Eric+Green · 2000-08-18 02:41 · Score: 2 · on KDE Developer on the GNOME Foundation

Do not confused the fact that X11 is not programmable via pipes, with the notion that pipes are therefore useless. Rather, this is a case of where X11 is itself broken. See Plan9 for a GUI that needs nothing beyond pipes in order to effectively embed things.

For more of a an example: XBRU is a TCK/TK application. It never touches any actual tape hardware. That is all done by (surprise) BRU, which in turn is controlled via (surprise surprise!) PIPES! (A bunch of pipes, actually -- two named pipes, and two anonymous pipes). This is how the Unix component model was supposed to work -- and it does work, quite well, except in the realm of X11 components, where the design of the X11 interface is incapable of properly supporting the Unix component model.

Summary: Don't let the incompetent design of the X11 system interface lead you to excessively complicated communications mechanisms. In most cases, CORBA-style communications mechanisms are needed only because of deficiencies in design, not because of any inherent limitations in the Unix component model.

-E

That's not the point... by Eric+Green · 2000-06-13 20:56 · Score: 3 · on When Volunteer And Commercial Developers Don't Mesh

The point is when the commercial developer hires someone with no experience in the free software community, and said commercial developer's new hire ends up trashing the list with "bug reports" that in fact reflect his own personal opinions of how "things should be" rather than real bugs. This can be extremely disruptive of the development process.

This happens within commercial companies too, BTW. What we do, when that happens, is move that person off that part of the project onto something else where he can't hurt the development process. I know that I find it irritating when some dude we hired off the street, who doesn't have any experience in our industry, starts telling the two seniormost programmers in the company "how it should be" without listening to a bit of our input as to what functionality the GUI needs. Unfortunately, the KDE team can't move this Corel guy to another part of the project, all they can basically do is "fire" him by putting him in their kill filters.

I don't know what the solution is, other than have people with experience in the free software community be the ones who the commercial companies hire to do the work. I don't think anybody has had any objections to the way further MTX development has taken place, for example, even though EST paid me to do the work of bringing MTX up to date to work with the latest/greatest tape libraries. On the other hand, people with experience in the Linux industry or with Open Source are rarely in the job market -- I know, we've been trying to find some of them to hire, and finding people who have the skills we need, in this industry, has been difficult.

-E

That's not the point... by Eric+Green · 2000-06-13 20:56 · Score: 3 · on When Volunteer And Commercial Developers Don't Mesh

The point is when the commercial developer hires someone with no experience in the free software community, and said commercial developer's new hire ends up trashing the list with "bug reports" that in fact reflect his own personal opinions of how "things should be" rather than real bugs. This can be extremely disruptive of the development process.

This happens within commercial companies too, BTW. What we do, when that happens, is move that person off that part of the project onto something else where he can't hurt the development process. I know that I find it irritating when some dude we hired off the street, who doesn't have any experience in our industry, starts telling the two seniormost programmers in the company "how it should be" without listening to a bit of our input as to what functionality the GUI needs. Unfortunately, the KDE team can't move this Corel guy to another part of the project, all they can basically do is "fire" him by putting him in their kill filters.

I don't know what the solution is, other than have people with experience in the free software community be the ones who the commercial companies hire to do the work. I don't think anybody has had any objections to the way further MTX development has taken place, for example, even though EST paid me to do the work of bringing MTX up to date to work with the latest/greatest tape libraries. On the other hand, people with experience in the Linux industry or with Open Source are rarely in the job market -- I know, we've been trying to find some of them to hire, and finding people who have the skills we need, in this industry, has been difficult.

-E

Re:Linux still a desktop joke by Eric+Green · 2000-03-07 23:53 · Score: 2 · on Walnut Creek CDROM And BSDi To Merge

Strange, for a "joke", it manages to run our entire corporation ( Enhanced Software Technologies ). Even the marketing people have KDE desktops, and they are DEFINITELY non-technical people.

Linux may be a "joke" as a home user desktop, but as a corporate desktop it works, it is low maintenance (the users cannot trash their system no matter how hard they try, and all user-changable files are mounted off of the NFS server so that all user files are backed up every night without any special software other than plain old BRU), and the users have a pre-defined desktop with easy-to-use icons for all the software they need to run. And any user can log in to any machine on campus and get his own desktop -- no "roaming profiles" needed!

Upsides: Low maintenance. Easy to swap out dead machines without disrupting user's work (he can just go to another machine, or I can slide in a backup machine, he logs in, and is back to his desktop).

Downsides: User can't install games that he brings from home. Hmm, is that really a downside? (grin).

-E

Already is a foreign implementation of TwoFish by Eric+Green · 1999-10-29 05:20 · Score: 2 · on Crypto Guru Bruce Schneier Answers

Dr. Brian Gladman has already independently implemented each of the AES candidates. Their source code is available on his web site at www.seven77.demon.co.uk (yep, United Kingdom, i.e., not U.S.).

The idiocy about U.S. export restrictions is that I cannot give Dr. Gladman a copy of a program whose only cryptographic component is Dr. Gladman's own code. See the bottom of my Ocotillo page at http://www.estinc.com/~eric for more details.

-E

Re:backup programs for Linux by Clith · 1999-07-15 21:14 · Score: 2 · on Ask Slashdot: Heterogeneous Network Backups w/Linux?

This is simply a URL-enabled version of the informative posting, all URL's verified and typo-checked. :-)

Freeware

http://www.amanda.org/ - Amanda

ftp://ftp.zn-gmbh.com/pub/linux/ - afbackup

http://www.cs.wisc.edu/~jmelski/burt/ - Burt

http://www.estinc.com/features.html - BRU

http://www.estinc.com/qsdr.html - Quickstart

Commercial

http://www.unitrends.com/bp.html - Backup Professional

http://www.unitrends.com/ctar.html - CTAR

http://www.unitrends.com/ctarnet.html - CTAR:NET

http://www.unitrends.com/pcpara.html - PC ParaChute

http://www.arkeia.com/ - Arkeia

http://www.legato.com/Pro ducts/html/legato_networker.html - Legato Networker Linux client

http://feral.com/networker.html - Legato Networker server