Slashdot Mirror

Have you looked into doing a Samba share. You can use it on a mac..

Some people might scare you with security issues, but that only applies to earlier versions. If you get the latests build, you will be safe.

You have the classic battle between OpenOffice and Microsoft Office.
After just Linux and OpenOffice installed, it will be evident the advantages are much greater than using Microsoft products, namely because of the price. If these guys are donating thousands of computers to schools, reducing software price from $200-300 per unit to $0 is going to enable them to construct out quite a bit more labs.

There are quite a few Gnome applications which would help in everyday usability. Of course, Gnome or KDE would probably be your desktop of choice, especially if the organization is coming off of Microsoft Explorer; keep it familiar to effectively show advantages.

You didn't specify what type of educational environment the labs target, but for programming Anjuta is a great alternative to Microsoft Visual C++.

A few other mentionable applications would include Mozilla Firefox (over Microsoft Internet Explorer), and The Gimp (over Photoshop).

For networking with existing Windows labs, Samba is an effective alternative.

This might be irrelevant to graphics, but I think french cafe analogy written by Andrew Tridgell who developed Samba is a good reference on how to do reverse engineering (or in his term: network analysis or protocol analysis) in general.

What you describe isn't an OS flaw. It's a flaw with the way Samba is designed. It also may have been the only way to do something like that. And if Samba is set up correctly, you should be able to write to that share if your userid matches the owning userid. That's done as part of a translation. Once I've logged in, however, I haven't had problems working on specific files I own that are on the share.

Check the Samba How-To if you're running Linux (or Solaris, or FreeBSD, etc) as your server.

Linux sparc64 supports SMP just fine, thankyouverymuch. In fact, it supports it better than any free BSD does.

sparc uses 32-bit userland apps *where the additional virtual memory space is not required*. This has the benifits of being smaller in memory and disk footprint (64-bit ls?). But they are also faster. That's right faster. This isn't like the amd64 architecture where going to 64-bit gives you more registers.

Later components of Samba (domain authentication, etc.) almost certainly did require reverse engineering, though.

A shortened version of the story (about a third of the way down the page).

"In the past, what we'd have to do is reverse-engineering, and we had been getting into a pickle, because for open-source projects like Samba and OpenOffice, the only way to get the information was by reverse-engineering," he said."Pretty much for ALL the countries in the world, reverse-engineering was a perfectly fine thing to do."

Pardon me for being insistent, but "openoffice.org" is a Web address, not a name. If the company that makes it doesn't want their customers to call it "Open Office," they should change the name. (They should probably change the name in any case. "Open Office" doesn't exactly stir the soul.)

That's not being insistent, it's being stupid. OpenOffice.org is the name of the software. The original poster was correct, you tried to correct him but looked like an idiot because you were wrong and then I corrected you. It's a very simple sequence of events; do try and keep up. As for what you think of the name, nothing you've posted so far inspires me to assign any value to your opinion.

Numbers.

A meaningless non-response with nothing to back it up, almost certainly indicating that you have no basis for your opinion. This is unsurprising.

No, it was supposed to be illustrative. Reading comprehension much?

Illustrative of what? That you don't hire competent people? That you change your hardware and software platform whenever you change IT personnel? It's certainly not illustrative of anything regarding open source software.

> We use open source software because we like the support, reliability and licensing freedom.

How odd. Because it has none of those three things.

I don't normally go in for personal attacks but you're really not a very honest person, are you? Starting from the end:

For you to claim that open source software doesn't provide licensing freedom is either stupid or dishonest. Since you're apparently capable of operating a computer with at least minimal competency I find it difficult to believe that you could be stupid enough to believe what you said. So you've apparently lying. Unfortunately you chose to lie about a subject that the Slashdot audience understands reasonably well so you're not going to get very far.

As for reliability, there are plenty of studies that show the reliability of open source.

And finally, support. I don't think this will be news to anyone except (perhaps) you but paid support is available for open source software. Linux is supported by distributions such as Redhat and Novell, Apache & Tomcat are supported by companies like JBoss and Samba is supported by a truly huge list of companies in many countries. As another poster pointed out, OpenOffice.org has commercial support available from companies like Blue Point

You shouldn't bother replying to this, but if you do be sure to bring some facts to back up your position. Your blind assertions do not impress.

Link to it, son.

It's now more than 50%.

What is needed to make Linux more widespread on the desktop is to find a niche where Linux is cleqrly superior to Windows and to push into that niche

It is hard to tell from your statements, but this may stop tools like ccache from working. I use ccache in my projects and it radically cuts down the amount of recompilation required when I do a complete rebuild. Now, an obvious question is why I don't simply rely on makefiles to ensure only changed files ever get rebuilt. This often happens because compilation involves generating new cpp files that are then compiled and I don't want to be grepping through these all the time. I suppose I could move them all to a different directory, but ccache works very well.

The other problem, of course, is that separating your classes into header and implementation means that if you change the implementation, you only need to recompile that one file and relink, rather than recompiling EVERYTHING. This can be a matter of a few seconds vs. several minutes. And implementation does change, a lot... fix a bug, you fix the implementation. The headers change too, but much much less frequently.

The real patch is here.

distcc

One is the official HOWTO
http://us4.samba.org/samba/docs/man/Samba-HOWTO-Co llection/winbind.html

The other is from the Samba 3 by Example
http://us4.samba.org/samba/docs/man/Samba-Guide/ke rberos.html

One is the official HOWTO
http://us4.samba.org/samba/docs/man/Samba-HOWTO-Co llection/winbind.html

The other is from the Samba 3 by Example
http://us4.samba.org/samba/docs/man/Samba-Guide/ke rberos.html

If you are compiling a lot of code and have several Linux boxes around you could look into DistCC Nice to have around if you will install Gentoo on anything

actually, true:

Samba

Ad Aware

(saw the window, had to go through it ;)

Seriously? Just tell the poster to go to Samba and leave space for more interesting questions.

• An explanation of Samba
• A Google search for Samba consultants
• Some companies that sell Samba support
• Another Google search for problems with Samba and Windows Server 2003 - to know what may lay ahead
• And of course the classic Samba HowTo with another Google search concerning install problems

Seriously? Just tell the poster to go to Samba and leave space for more interesting questions.

• An explanation of Samba
• A Google search for Samba consultants
• Some companies that sell Samba support
• Another Google search for problems with Samba and Windows Server 2003 - to know what may lay ahead
• And of course the classic Samba HowTo with another Google search concerning install problems

Seriously? Just tell the poster to go to Samba and leave space for more interesting questions.

• An explanation of Samba
• A Google search for Samba consultants
• Some companies that sell Samba support
• Another Google search for problems with Samba and Windows Server 2003 - to know what may lay ahead
• And of course the classic Samba HowTo with another Google search concerning install problems

not true
http://us4.samba.org/samba/docs/man/Samba-HOWTO-Co llection/domain-member.html#ads-member

I assume you haven't heard of this: distcc It does improve speed during compiling. Gentoo can be compiled using distcc and there is even a how to on the gentoo documentation page.

Forget palm, get a Zaurus and have it your way.

No silly application-file ownership, no proprieratory OSes (can run an opensource linux, including OpenZaurus, Gentoo, and probably others. I particularly like the Gentoo build, as I can use distcc with my home machine to do the actual builds for my zaurus all over WLAN. Then sit back and reap the rewards of hundreds of precompiled packages and thousands more that you can build yourself using the ARM toolchain.

I don't know about you, but these things when compared to a tunsten just seem a whole lot sexier to me.

My servers do have gui interfaces... Webmin and SWAT...

Rsync will do this simply and efficiently, plus it can resume transfers and also tunnel through ssh.

Also you can pipe dd through gzip/bzip2 and netcat to give you a loopback mountable, unmodifiable image that you can look at in case you want to grab the whole drive before putting it in the evidence locker.

yeah sure, except that you replied to it: http://lists.samba.org/archive/samba-technical/200 2-January/018474.html

you're like an open source community troll, except you don't do it with trolling in mind.

Here is the link M. Coward posted, but fixed, plus my +2 score so more will see it. (Sorry M. Coward, but then, I figure if you're Anonymous, you're not worried about credit or karma.)

http://lists.samba.org/archive/samba-technical/200 2-January/018388.html

I don't know the people or the situation enough to judge either one, but I figure it is good to see both sides. The truth, I suspect, is somewhere in the middle, but I say that onlly because it usually is.

This is explained step-by-step in The Official Samba-3 HOWTO and Reference Guide. In particuliar, have a look at chapter 21 if you are trying to use your Active Directory as a source for Unix account (ssh, mail, etc). You could also use a combination of nss_ldap, pam-ldap and MS Service For Unix if this is what you are trying to achieve. Note that this is definitely not a project for beginner; it touch some pretty advanced Linux sysadmin-fu like the nsswitch library and PAM.

so wait, your management and environment forces you to use iPlanet, and you havn't bothered to even try compiling a more recent version of samba to see if it works, and this is somehow all samba's fault?

oh wait, i see here the first sentence in your reply:

Well, you see, that's the problem... Management refuses to let me implement a solution that's not supported

maybe you should try looking here: http://us1.samba.org/samba/support/ instead of whining on slashdot. better yet, give iPlanet support a call, or (and this is pretty crazy i know) try, just try, compiling a more recent version than than the ancient version shipped with RHEL, to see if that works. maybe you'll learn something.

also how are you getting away with using iPlanet , if as you say, you only are supported when using openLDAP with Redhat?

and not bothering to file a bug, but bitching loudly about it on slashdot, and investing 6 months of your time trying to get around the bug, says a lot

It would be nice if they actually fixed their LDAP code so that it would work with any directory server other than OpenLDAP.

It does. We routinely run it with IBM Directory Server.

and the buggy Samba implementation of LDAP as a storage mechanism for account information just doesn't work with anything other than OpenLDAP.

Were you linking against iPlanet LDAP libs or OpenLDAP libs? It's quite possible that you're linking against the OpenLDAP libs and that they're not getting along with iPlanet.

Samba only uses the standard LDAP calls. Other than the schema extensions (which unfortunately aren't in a standardized format) there's no LDAP-platform dependence.

It's bizzare, it's actually as if Samba is sending the XP client a buffer overflow while authenticating.

Why haven't you submitted this as a bug report at samba.org?

I spent weeks working with RHEL technical support,

Grab the latest from samba.org. The RHEL packages are sometimes quite old.

I'm sorry, but Samba is not ready for prime-time.

It's good that you made this decision for the world. Since noone's actually using Samba in production environments right now.

Look, Samba's used in a lot of enterprise environments. You're experience isn't the norm. You're environment also isn't the norm. Not many folks use iPlanet. Netscape's DS is also considered one of the lesser LDAP servers out there.

If this is a reproducable bug, and of the severity you describe, and is still present in the latest version of Samba, it's certainly be a high priority fix.

Keep in mind though, we don't do a lot of testing with things like iPlanet because we don't have access to copies of it. OpenLDAP and IDS get a lot of testing with Samba because people who work on Samba have ready access to it.

What's more, I don't see a single way in which any kind of LDAP failure could result in Samba sending an incorrect packet (with an incorrectly sized buffer) to a Windows client.

Bugzilla is your friend.

So basically the Samba team is doing what they believed was too ambtious in 2000, thus leading to the forked Samba - TNG project. Am I correct?

Judging from the results probably Tridgell & co. were right...

Andrew Tridgell is the man behind two of the most interesting and usable free software products available; samba and rsync. Samba is truly great, but I find rsync so incredibly useful and smart. Does the Windows world have any kind of rsync-equivalent? (Besides the Windows rsync-ports, which require a lot of extra stuff like Cygwin.) Backing up data with rsync makes me sleep well at night :-) Thanks Tridgell! :-)

Andrew Tridgell is the man behind two of the most interesting and usable free software products available; samba and rsync. Samba is truly great, but I find rsync so incredibly useful and smart. Does the Windows world have any kind of rsync-equivalent? (Besides the Windows rsync-ports, which require a lot of extra stuff like Cygwin.) Backing up data with rsync makes me sleep well at night :-) Thanks Tridgell! :-)

Can we start blaming Microsoft for bugs in Linux now?

Not that I'm a fan of M$ but you can probably blame IBM too as they are the ones who wrote the first version of SMB

It should be clarified, that this is NOT to do with the smbd process aka Samba Project

But this is.

I agree with the rest of your post, but this strikes me as a little strange. Why not use all of these machines for compiling with distcc? That's what I use anyway. And NFS for sharing the /usr/portage tree, but that doesn't probably matter as long as your solution works.

If the other machines are not doing anything useful, they might just as well be helping with compilation. Portage can take advantage of distcc readily, by specifying FEATURES="distcc" and MAKEOPTS="-j(2N)" for compiling on N machines. Ccache is another package that can help speed up compilation, and works with Portage likewise. By the way, and old P3 is the fastest machine I've got...

This post was generated by a Horde of Gentoo Boxen for TeknoHog.

I agree with the rest of your post, but this strikes me as a little strange. Why not use all of these machines for compiling with distcc? That's what I use anyway. And NFS for sharing the /usr/portage tree, but that doesn't probably matter as long as your solution works.

If the other machines are not doing anything useful, they might just as well be helping with compilation. Portage can take advantage of distcc readily, by specifying FEATURES="distcc" and MAKEOPTS="-j(2N)" for compiling on N machines. Ccache is another package that can help speed up compilation, and works with Portage likewise. By the way, and old P3 is the fastest machine I've got...

This post was generated by a Horde of Gentoo Boxen for TeknoHog.

Not just FUD, but also lock-in. Please see the warning at the Samba Development page: In order to avoid any potential licensing issues we also ask that anyone who has signed the Microsoft CIFS Royalty Free Agreement not submit patches to Samba, nor base patches on the referenced specification.

Anyone who voluntarily licenses, for example, eating fish, must then abide by the fish-eating license (:-))

--dave

The second part with shell acounts and home directories are all problems already solved by NIS/NFS. You could setup a pool of machines that all share the same NIS/NFS info so anywhere the user logged in they'd have the same files/passwords, and load balance it via ipvs or dns.

AFAIK the current state of clustering works well for custom code situations, where you write your app to run on the cluster, but doesn't transparently make your 4 boxes act like 1 box with 4X the resources for just any program.

I've used distcc with some luck on gentoo, but it only distributes compiling over your nodes.

I had a conversation with one of the top IBM Australia execs at the "open source" section of IBM Forum in Melbourne earlier on this year, and I asked him what was stopping IBM from using Linux on more desktops within their organisation (from memory he said that the desktop spread at IBM is something like 95% Windows, 5% Linux). His response was that it was only Lotus Notes that was holding them back.

Andrew Tridgell (Samba), who at the time was doing some work for IBM in Canberra and had just completed a panel discussion on the use of open source software, joined in the conversation and started fervently campaigning for IBM to ditch Notes in favour of the use of a wiki. The other IBM bigwigs who were floating around after the session gravitated over to the conversation and seemed genuinely interested in any technology that would free them from having to use Lotus Notes!

I'd wager that given IBM's newfound interest in OSS, a shift in trend from Notes to using a wiki would be something that is taken very seriously indeed.

Something that was unthinkable under GCC.

The concept would work better with ccache. The compile delay only happens on the first execution, and subsquesent ones are fast, not only to start, but also to execute (because the code has been optimized as normal)

What if one of those packagers got a rooted samba? How can he know? Today he is lost. If there was a signing infrastructure I mentioned, he could test the signature.

Perhaps samba wasn't the best example. Or, rather, it seems to be a very good example of achieving the main goal, since it does have a simple, open-source method for verifying source code integrity. From the top of Samba's download page:

The Samba distribution GPG public key can be used to verify that current releases have not been tampered with. Using GnuPG, simply download the Samba source distribution, the tarball signature, and the Samba distribution public key. Then run

$ gpg --import samba-pubkey.asc
$ gunzip samba-version.tar.gz
$ gpg --verify samba-release.tar.asc
gpg: Signature made Tue 26 Nov 2002 07:12:04 PM CST using DSA key ID 2F87AF6F
gpg: Good signature from "Samba Distribution Verification Key<samba-bugs@samba.org>

Where I might disagree is on the philosophical level of whether this truly needs to be directly integrated into the tar utility, as per your post at the top of this thread. For myself, I would say not, since the above approach can easily be integrated into makefiles, RPM specs, etc - providing automation without needing to make tar slurp in large chunks of gpg. But I appreciate that others may have different opinions on where the proper place is for performing integrity-checking. (I felt the same way about tar incorporating compression/decompression, but clearly others felt this was worthwhile.)

Now, I'm no Linux zealot (in fact, I develop and sell Windows software) but I have had several years experience admin'ing a student-run computer lab and I have learned a few things about spyware.

We had Windows 2000 machines installed, and for the longest time keeping them up to date and users locked down to regular user privileges prevented the spread of nasties. Individual accounts got spyware and viruses, but it didn't spread across the machine.

Then over the past year and a bit I noticed that even though I kept the machine up to date, spyware did seem to "leak" from one user's account to elsewhere on the system. I do keep the systems patched, but sometimes I am as late as a week applying a fix. Let's face it, I have better things to do and I'm not paid to look after the lab.

But here's what I recently did. We set up our beefy Linux server (which already acted as the primary domain controller for the NT domain, with samba) as an XDMCP capable server. This means that any UNIX (or windows) station can login into the server as a dumb terminal, using XDMCP. This is done easily with Xfree/X.org with the command "X -query hostname"

So now we still have Windows 2000 and Windows XP stations, which are clean at the moment... but I suspect that the Linux workstations are going to fare better over time. After all, they're dumb terminals to the Linux server. People can still run Mozilla Firefox, OpenOffice which takes care of 99% of our users' activities. People are happy, I am happy, and we're re-using old equipment (graphical terminals) that would otherwise be occupying landfill space.

DVB (this text to bypass lameless filter)

SMB (this text to bypass lameless filter)

HTH

So creating a thread that immediately exits is faster than creating a process that immediately exits. Woo-hoo.

A more interesting case is if they keep running together. In the thread, everything is shared: there must be a locks on the heap to synchronize access, so you pay a price on every malloc and free[*]. (It should not be necessary to point out that these are far more common than creating threads.) There are similar issues for per-process in-kernel structures such as the file table. Because more data is shared, there is more likely to be contention between threads from the same process on different CPUs.

Some of tridge's benchmarks show that on $vendor Unix, using threads can be twice as slow for a server-side tasks as using processes. On Linux, threads are only slightly slower.

Shared-everything is often a slower model, not faster.

[*] OK, it doesn't have to be a lock, but the heap does have to be thread-safe, which makes it slower or more complex or both.

The current Xbox console has an Ethernet jack. There exist hard drives that connect to TCP/IP/Ethernet; these use various network attached storage protocols such as iSCSI, NFS, CIFS, etc. Assuming that somebody does figure out how to mod the Xbox 2 to run arbitrary code, would it be so hard to port Darwin and tell it to mount such a network filesystem?

Forcing MS to release technical documentation describing the protocol is probably the most important issue, forget WMP! Microsoft, of course, doesn't want to make it easy to implement their file serving protocol. That will allow 3rd parties to more easily interoperate with Windows. That 3rd party could be a Linux box instead of another bought and paid for Windows box.

The release of this documentation will undoubtedly make the jobs of the Samba developers much easier. Good for Linux, bad for Microsoft. I for one don't care when something is bad for Microsoft.

I'm not sure tying build-avoidance into the kernel and the SCM system is really the best way to do it. It does give you automagic dependencies, but at a price -- last time I used Clearcase we had to run a buggy two-year-old kernel because that was the last one Rational supported.

ccache and SCons give you build-avoidance too, without slowing things down or making everyone depend on a central server.