Slashdot Mirror

• TiVo runs Linux. All Linux related news be posted even if the only Linux related part of the story is that the author bought Linus a beer in Cupertino five years ago.
  
• It's an intellectual property issue. All IP issues are on topic.
  
• Because Hemos said so.
  
• Because TiVo is hackable.
  
• Because a lot of nerds love Buffy, Star Trek, and The Simpsons.
  

I soon plan on discontinuing my Verizon service. And, I would like to buy a TiVO, but I realize that it requires a phone connection. So.. is there any way to get a TiVo that can make use of Ethernet, such as from my DSL? I mean, it's not like I don't have 'net access -- it's just not via the local monopoly.

Through Google, I did run across a TiVo Ethernet project, but I'd like some way to get those results without hacking up my TiVo -- I just want it to work!

Alex Bischoff
---

Here's my procedure for supporting proprietary clients from an open standard print server.

I typically buy a printer that's supported by Linux, set up a Linux print server, then export that via lpd, Appletalk, and Samba. Then I install the standard Apple Laserwriter driver on any Windows clients, because it's simply a Postscript driver. In fact, you'll find that a lot of the entries in the Windows driver database are simply alternate names for or versions of the Apple Laserwriter driver because it's just Postscript. Then I install MacOS's standard Postscript lpr client on the MacOS client hosts.

Another time, I made Linux print to a totally proprietary printer. It was an HP 3150, which is an excellent value although proprietary; sometimes you take the hit and run with it. You can install an ethernet adapter from HP, on any parallel printer device of any kind. Then on the aforementioned print server, I installed VMware and Windows 98 with the proprietary drivers, which exported the printer to Samba, which reexported it as Postscript. That whole virtual machine was just another printer driver!

That's almost as crazy as writing an open source, open standard implementation of a reverse engineered Microsoft protocol based on their buggy specs and implementations. ;) But it's still a good idea to try to eventually directly support the alleged standards, to support the exceptional cases where a direct local client-side driver is necessary.

I am sure there are people who are unfortunate enough to have chosen very driver-specific proprietary devices for printing and imaging, but in most cases it was technicall preventable.

===

There are a lot of people looking to build out MAN's in their cities, with some in Seattle and San Francisco already running. You can tap into them and get free Internet access and share files with your neighbors.

Check out the following links:

• http://www.wavelan.com
• http://lists.samba.org/pipermail/wireless/2000-Apr il/001371.html
• http://www.notwise.net/LUGOJ/2001/Jan/0764.html

If Maxtor uses Samba, they have to put up with all the hard-to-useness. If Maxtor uses Win2K, SMB support is already there. Then all they have to do is write in support for NFS (unless win2k already has an NFS solution) and AppleShare (ditto).

Samba is really coming along nicely, but it's STILL a pain in the ass after all this time. Microsoft's implementation works better with Windows because, well, they just plain old wrote the OS and know how best to interface with various versions of Windows and their SMB features.

Maybe someday Samba will really be "drop-in", but it isn't today, not for me at least. I can fully understand why Maxtor would make a network appliance-type box run off Win2K... it will work with every Windows box they can throw at it, and work the first time.

"rsync is an open source utility that provides fast incremental file transfer. rsync is freely available under the GNU General Public License."

"Xdelta is released under a BSD-style license" and features a "delta-compression algorithm, including diff- and patch-like utilities. Xdelta uses a fast, linear-time, and linear-space algorithm that works well on both binary and text files." Newer versions support "XDFS", the "Xdelta File System", "making it a reliable solution for delta-compressed file storage".

Bugzilla, OTOH, is more full-featured (too full-featured for most small dev groups, IMHO) and uses a SQL database. So you could theoretically run just about any report you like. I don't think it records all the bug dates you'd need for the reports you mentioned, but that's a relatively trivial patch.

I'd prefer to have something that replicated changes made to one disk to another disk located in a separate PC that may well be in a location 100 metres away. Is there anything open sourced that can do this?

Yes, rsync. http://rsync.samba.org

-Peter


"There is no number '1.'"

there doesn't seem to be mention of an rsync type approach, which is odd considering the bandwidth problems they're trying to address.

each device is required to maintain a change log for each server that it syncs with. could get expensive in terms of memory if you don't sync for a while, especially on small devices. however, does anybody have an alternative other than a complete resync every time?

one of the things it's based on is that each item to be synced will have a unique ID, which is something that can't be relied upon to exist at the moment. hopefully, this will encourage PIM writers etc to implement these as it makes things much simpler. the only alternative i can see is to compare items every time to try and find similarities which is fraught with difficulties ;)

the best sync stuff i've used has been truesync by starfish, so it's encouraging to see them involved.

You can increase the Live TV buffer of TiVo, however it still gets reset anytime you change the channel - which isn't so bad because channel surfing generally goes out the window when you have a PTV system.

• Free Software Foundation
• OpenBSD
• Apache
• NetBSD
• PostgreSQL
• SAMBA
• FreeBSD
• LinuxFund.org
• KPFK radio

No, it's more of a loud fan/HD whine. It comes on a couple of seconds after booting the laptop, and stays until it goes to sleep or is shut down.

Also, the camera driver is Here, although I've never tried it out.

Just browsing somewhat futher in the mailinglist, I found this stating that win2k PDC was on its way in the HEAD branch. Btw as a answer to above mentioning (like you need to have a FTP server running the get files across win2k linux), nothing less is true, just disable active directory (or whatever it is called) and it does work!

Those who have registered in the Samba survey as "Pizza Factory" will already know this, but the rest may need some help. Andrew doesn't ask for payment, but he does appreciate it when people give him pizza. This calls for a little organisation when the pizza donor is twenty thousand kilometres away, but it has been done.

---

Convoluted? In what way. I setup Mandrake in about 5 minutes to file and print share with my other boxes. Oh right, you mean file and print share with Windows clients, yes that is a bit harder, I blame the monopoly. If they used common networking protocols instead of their own badly-documented crud then you wouldn't have a problem and the Samba team would be able to do something better than have to figure out the garbage hack that Microsoft Notworking is (no offence to the Samba boys, you do a fine job, you just shouldn't have to)

As has been already posted and discussed, Java computational performance is a match for C+=[you mean C++ ?] today.

I have not done any J3D and only a little AWT and Swing but I have done a ton of Java(http://jcifs.samba.org) and I frankly don't see how what you say above is possible. Java is slow. Java AWT is slower. I found the article you mention but just don't have time to read the whole thing at this moment. You have a relavent section you can point me to? A string I can search on using find in the browser would be great.

KidSock

i've been doing some research on the picture book and it seems a native of slashdot has one. he also seems to have gotten linux and just about every feature working.

check it at: cowboy neal's vaio page

also, i was concerned about not being able to use the firewire camera(anyone read cryptonomicon?) think of how cool it would be to have running under linux.
So check out : camera capture program

it's all very spiff. it will be doubly cool(no pun) when the transmeta chip gets in there.

xavii aka bob
disconnect_myself.from_your.memory_and.never_feel anything.at_all-strung.out

My experience is that VA has a quality product and knowledgable tech support. I'm buying two new 2230s for my server room.

Another thing which is important to me is that I feel this is a way I can support the open source movement, rather than buying clones or whatever -- I mean they have Jeremy Allison on staff (the samba guy) and I'm sure many others who are contributing to the Linux "movement" or whatever you want to call it.

As always, your mileage may vary

I think a project whose job would be to take many modern day UNIX configuration files (/etc/*) and translate them into XML formatted files would be quite useful.

This is a very interesting suggestion, and it may actually receive some enthusiasm. There are actually a couple software projects that I can think of that use an XML-like configuration file (take note of the "<DIRECTORY>" directives). Apache(example) and ProFTPd(example). Xinetd has a configuration file format that could easily be XML'ified, as could SAMBA.

Frankly, providing a generic, hierarchical, XML-formatted configuration file parser would be EXTREMELY useful. Personally, I'm ready to rip out Apache's or Proftpd's config parsers for my own projects and modify them accordingly.

Another interesting software project to take a look at if XML configuration files is something that appeals to you is Everybuddy, an all-in-one Internet Messanger client.

Yesterday, I took down my Linux server at work, and replaced it with a Windows 2000 server. Yes, I'll probably get flamed for this, but I had a specific reason, Samba. Eight months ago, I set up a Red Hat Linux server to act as a file server for my Windows users. It was rock-solid stable, the machine would never crash, but transfers at 100 Megabits would eat up 70% of the CPU time on a PIII-500 with 192MB of RAM. This would render the GUI unusable, and the Samba status window I had running in X would die as well.

Might I suggest CoriolisOpen Press' SAMBA Black Book? One of the best books I've found for SAMBA. Something was definitely mistuned on you server, as no way should SAMBA be using that much resources. In particular, chck out pages 439 - 442 (Configuring Samba for Optimal Performance)

Also, try the resources available from samba (www.samba.org), including subscribing to the mailing lists.

In terms of your problems with the Linux LUG, I can suggest the Greater New Hampshire Linux Users Group as an excellent one for answering questions. Feel free to subscribe to their mailing list (directions on their home page), we do serve the "Greater" New Hampshire.
jeff

We need to librarify everything first. Just as this /. article with the troll title of UNIX Sucks! points out.

I'm totally into Java at the moment but I can appreciate the benifits(and know how to avoid the pitfalls of) object oriented programming and the need for reusable software components on unix.

We must librarify everything before we build apps! How bout that IBM? I mean it. I want to work on unix libraries. I'm not bad at c/c++.

There should be a very high quality library with a uniform API for e-mail, mathmatics/finance, network filesystem, distributed computing, configuration file API, logging for apps, ... etc.

Examine everything that is common/and not so common to day to day computing, reduce it to it's primitives and freeze it into a portable library.

I can go on like this if someone wants to talk about it.

KidSock

• Microsoft.com. Search for exact phrase "SAMBA." (include the period)
• Web Workshop - CIFS Products and Vendors
• Samba
• At the bottom of the page select Linuxcare
• then click the Linuxcare logo to go to the US site for Linuxcare
• Under Linux Links select News/Press
• then, finally, Slashdot!

Samba book online is located at http://us1.samba.org/samba/oreilly/ using_samba/ though you should probably log onto the closest mirror at the samba.org link about and go to the documentation from there.

The documentation should soon be available via cvs as well.

Lando

Samba book online is located at http://us1.samba.org/samba/oreilly/ using_samba/ though you should probably log onto the closest mirror at the samba.org link about and go to the documentation from there.

The documentation should soon be available via cvs as well.

Lando

Unless 400,000 minutes of configuration for the LAN client alone sounds like fun of course...

gruntvald meant 20 minutes per server, not per workstation you dimwit.

Samba runs on the server, not the client.

I struggled with this for a while as well, and I realized that, all things considered, Samba is definitely the way to go. I ended up setting up a dedicated Linux box, running Samba and having it authenticate against the NT domain in which all the Windows boxen lived, and kept tons of data on the Linux box. The windows users never knew that they weren't talking to an NT box, and I got all the advantages of using Linux.

The advantages are (quickly):

• stability
• you can use any unix filesystem on the back end, since the Windows box communicates with it via SMB, and not through direct file access
• it doesn't have to run on Linux; you can use a Solaris box, for example (samba is developed on Solaris and Irix, not Linux) and this is also transparent to the Windows users
• because SMB is a network protocol, and not a kernel driver, you can share the same disk via several methods simultaneously: to Windows boxen via SMB, to *nix via NFS, to Macs using Netatalk, and, of course, you can ssh in to the box and access the files through the filesystem in the normal fashion.

Disadvantages:

• you need to have an extra box on the network (might be a problem if you have limited address space or physical space, like at your house)
• there are Windows boxen on your network (not a samba problem per se).

Are they going to integrate the code for the Netfilter modules into Linux 2.4 or do people need to download/compile/install separate Netfilter modules if they want to do some NAT'ing? Somewhere I read that the Netfilter team goal is to get it into 2.4 but the current version (0.1.18) doesn't even compile with kernel 2.3.51 source. I guess they have to hurry up if we want to have NAT support out-of-the-box for 2.4...

Try smbclient

Bullshit, if you are supporting an environment, you created and/or sysadmin, you call the shots. Or you convince your boss to lay down the rules. I.E. "We will not support your environment if you are not running the latest version of debian.", etc. Else you tell them to find someone else to support them, they'll switch. It's called a support agreement. Having many, many distros IS a blessing. You can tailor your evironment to which distro you want, the one that makes your support most productive.

Offtopic:
UNIX is ideal for desktop environments. For one the users only have access to the system as their user, they almost can't screw up system level things. I say this from first hand experience working for a group of 8 who supports over 1500 HPUX desktops. We laugh at the windows helpdesk scurrying around all day and night fixing systems. We have the users home dirs on nfs mounts, so we can update the systems at will, without having to remove user data or shutdown the system. We even use scripts to update systems and applications via rsync upon reboot. We have reduced admin/helpdesk time to next to zero, so we can lie around writing web tools and looking good (getting more support agreements). :-)

Taking a very quick look at the documentation myself, I see that you'd probably have a rsync server running on each site, and then have a cronjob run on each site that mirrors every other site. If all 3 sites do this, it should mirror pretty well. The lag time will probably be something like 2T, where T is the time between cronjob runs.

In regards to your specific what-if questions, I think the best way to answer those will be to try it out yourself. :) Hope that helps

---

I also wish there had been more push for make Linux x86 a better database server platform. Limitations that get in the way are:

• 15 partition limit should be raised to a 31 partition limit
• Support in the offical kernel for accessing raw partitions such as rawfs or char partition devices
• Support in the offical x86 kernel for file over 2 gigs

Another item is the ability to have multiple default routes and routing to the default route based on source ip address. Multi-homing on multiple Internet feeds just isn't any fun when all your outbound traffic goes through the same pipe regardless of where the request comes from.

Anyways, I look forward to the 2.5 developments. The 2.3 kernel series has been fun. :)

Surely the most deserving title worth the prize is Using Samba by O'Reilly. First because their authors open-sourced the book. You can read it at
this address. Second because Samba is the project who is giving the best advocacy argument to us, Linux lovers. To put a Linux server in an enterprise, instead of (Argh!) NT we must ensure the boss that machines with Windows 95 and 98 also can connect and use the Linux box as easily as if would be an NT. And the Using Samba book is the complete, official and best reference written about the best practices and examples to make Samba works(many times with best performance than a NT or W2K box!).

I read that Samba can now be configured to use domain authentication when connecting a Samba box to an existing NT domain. You need to use smbpasswd to add the machine to the NT domain and set "security=domain" in your smb.conf. See "security=domain" under http://us1.samba.org/s amba/docs/man/smb.conf.5.html#security for details. I'm not sure if this helps at all, but good luck.

The book has been adopted by the Samba Team as the "official" Samba book and we will strive to keep it up to date. O'Reilly have sent us the full sources for the book and we will be making it available online as soon as we can, we just need to work out some formatting and conversion issues. We also plan to make it directly accessible from SWAT. A huge thanks to O'Reilly for this great step forward in the documentation of Samba!

• USA
• USA
• USA
• Canada Austria -->
• Germany
• Spain
• Portugal
• Russia

• Portugal -->
• Poland
• Italy
• Hong Kong
• Korea
• Romania
• Hungary
• Czech Repuplic

• United Kingdom -->
• Ireland
• Denmark
• Sweden
• Norway
• Finland
• Iceland
• Iceland

• France
• Turkey
• Japan
• Singapore
• Malaysia
• Australia
• Australia

• USA
• USA
• USA
• Canada Austria -->
• Germany
• Spain
• Portugal
• Russia

• Portugal -->
• Poland
• Italy
• Hong Kong
• Korea
• Romania
• Hungary
• Czech Repuplic

• United Kingdom -->
• Ireland
• Denmark
• Sweden
• Norway
• Finland
• Iceland
• Iceland

• France
• Turkey
• Japan
• Singapore
• Malaysia
• Australia
• Australia

• USA
• USA
• USA
• Canada Austria -->
• Germany
• Spain
• Portugal
• Russia

• Portugal -->
• Poland
• Italy
• Hong Kong
• Korea
• Romania
• Hungary
• Czech Repuplic

• United Kingdom -->
• Ireland
• Denmark
• Sweden
• Norway
• Finland
• Iceland
• Iceland

• France
• Turkey
• Japan
• Singapore
• Malaysia
• Australia
• Australia

• USA
• USA
• USA
• Canada Austria -->
• Germany
• Spain
• Portugal
• Russia

• Portugal -->
• Poland
• Italy
• Hong Kong
• Korea
• Romania
• Hungary
• Czech Repuplic

• United Kingdom -->
• Ireland
• Denmark
• Sweden
• Norway
• Finland
• Iceland
• Iceland

• France
• Turkey
• Japan
• Singapore
• Malaysia
• Australia
• Australia

• USA
• USA
• USA
• Canada Austria -->
• Germany
• Spain
• Portugal
• Russia

• Portugal -->
• Poland
• Italy
• Hong Kong
• Korea
• Romania
• Hungary
• Czech Repuplic

• United Kingdom -->
• Ireland
• Denmark
• Sweden
• Norway
• Finland
• Iceland
• Iceland

• France
• Turkey
• Japan
• Singapore
• Malaysia
• Australia
• Australia

• USA
• USA
• USA
• Canada Austria -->
• Germany
• Spain
• Portugal
• Russia

• Portugal -->
• Poland
• Italy
• Hong Kong
• Korea
• Romania
• Hungary
• Czech Repuplic

• United Kingdom -->
• Ireland
• Denmark
• Sweden
• Norway
• Finland
• Iceland
• Iceland

• France
• Turkey
• Japan
• Singapore
• Malaysia
• Australia
• Australia

• USA
• USA
• USA
• Canada Austria -->
• Germany
• Spain
• Portugal
• Russia

• Portugal -->
• Poland
• Italy
• Hong Kong
• Korea
• Romania
• Hungary
• Czech Repuplic

• United Kingdom -->
• Ireland
• Denmark
• Sweden
• Norway
• Finland
• Iceland
• Iceland

• France
• Turkey
• Japan
• Singapore
• Malaysia
• Australia
• Australia

• USA
• USA
• USA
• Canada Austria -->
• Germany
• Spain
• Portugal
• Russia

• Portugal -->
• Poland
• Italy
• Hong Kong
• Korea
• Romania
• Hungary
• Czech Repuplic

• United Kingdom -->
• Ireland
• Denmark
• Sweden
• Norway
• Finland
• Iceland
• Iceland

• France
• Turkey
• Japan
• Singapore
• Malaysia
• Australia
• Australia

• USA
• USA
• USA
• Canada Austria -->
• Germany
• Spain
• Portugal
• Russia

• Portugal -->
• Poland
• Italy
• Hong Kong
• Korea
• Romania
• Hungary
• Czech Repuplic

• United Kingdom -->
• Ireland
• Denmark
• Sweden
• Norway
• Finland
• Iceland
• Iceland

• France
• Turkey
• Japan
• Singapore
• Malaysia
• Australia
• Australia

• USA
• USA
• USA
• Canada Austria -->
• Germany
• Spain
• Portugal
• Russia

• Portugal -->
• Poland
• Italy
• Hong Kong
• Korea
• Romania
• Hungary
• Czech Repuplic

• United Kingdom -->
• Ireland
• Denmark
• Sweden
• Norway
• Finland
• Iceland
• Iceland

• France
• Turkey
• Japan
• Singapore
• Malaysia
• Australia
• Australia

• USA
• USA
• USA
• Canada Austria -->
• Germany
• Spain
• Portugal
• Russia

• Portugal -->
• Poland
• Italy
• Hong Kong
• Korea
• Romania
• Hungary
• Czech Repuplic

• United Kingdom -->
• Ireland
• Denmark
• Sweden
• Norway
• Finland
• Iceland
• Iceland

• France
• Turkey
• Japan
• Singapore
• Malaysia
• Australia
• Australia

• USA
• USA
• USA
• Canada Austria -->
• Germany
• Spain
• Portugal
• Russia

• Portugal -->
• Poland
• Italy
• Hong Kong
• Korea
• Romania
• Hungary
• Czech Repuplic

• United Kingdom -->
• Ireland
• Denmark
• Sweden
• Norway
• Finland
• Iceland
• Iceland

• France
• Turkey
• Japan
• Singapore
• Malaysia
• Australia
• Australia

• USA
• USA
• USA
• Canada Austria -->
• Germany
• Spain
• Portugal
• Russia

• Portugal -->
• Poland
• Italy
• Hong Kong
• Korea
• Romania
• Hungary
• Czech Repuplic

• United Kingdom -->
• Ireland
• Denmark
• Sweden
• Norway
• Finland
• Iceland
• Iceland

• France
• Turkey
• Japan
• Singapore
• Malaysia
• Australia
• Australia

• USA
• USA
• USA
• Canada Austria -->
• Germany
• Spain
• Portugal
• Russia

• Portugal -->
• Poland
• Italy
• Hong Kong
• Korea
• Romania
• Hungary
• Czech Repuplic

• United Kingdom -->
• Ireland
• Denmark
• Sweden
• Norway
• Finland
• Iceland
• Iceland

• France
• Turkey
• Japan
• Singapore
• Malaysia
• Australia
• Australia

• USA
• USA
• USA
• Canada Austria -->
• Germany
• Spain
• Portugal
• Russia

• Portugal -->
• Poland
• Italy
• Hong Kong
• Korea
• Romania
• Hungary
• Czech Repuplic

• United Kingdom -->
• Ireland
• Denmark
• Sweden
• Norway
• Finland
• Iceland
• Iceland

• France
• Turkey
• Japan
• Singapore
• Malaysia
• Australia
• Australia

• USA
• USA
• USA
• Canada Austria -->
• Germany
• Spain
• Portugal
• Russia

• Portugal -->
• Poland
• Italy
• Hong Kong
• Korea
• Romania
• Hungary
• Czech Repuplic

• United Kingdom -->
• Ireland
• Denmark
• Sweden
• Norway
• Finland
• Iceland
• Iceland

• France
• Turkey
• Japan
• Singapore
• Malaysia
• Australia
• Australia