Procom to Release NETBEUI for Linux 280
Procom has announced that they are releasing their NETBEUI stack to the Linux community. Press release is here. What the press release doesn't mention is that the stack will be available under the GPL license. The actual code release will be today or tomorrow (I will post a URL for the source as soon as I get it).
Re:security joy (Score:1)
I went to a "security site" with this stock W2K install that I am running and had it portscan. No unneeded ports were left open. In fact, they were configured to just not answer. That's called giving portscanners a "black hole" and it forces them to observe timeouts which slows down the little thugs running them.
Again, the security risk running just about any version of Linux is greater than W2K.
Re:Why bother? (Score:1)
Ever hear of an Intel Netport Express print server? Guess what...you MUST RPL it using netbeui. Until now, I had to store it's config files on a windoze box that isn't always up. If I could run netbeui on a linux server, I can RPL the print server without having to use windoze.
Newer versions have web management built in, but why spend that kind of money for a home lan when you can get a used netport for $20?
Here's a link to the source (Score:1)
Much of the excitement we get out of our work is that we don't really know what we are doing. -- E. Dijkstra
Existing stuff plus documentation? (Score:1)
Maybe this means they're getting a clue. The CD FORCE units I have in a middle school are running some ancient 2.0 kernel and thus are vulnerable to the likes of teardrop. Fortunately they seem to have a hardware watchdog, since it eventually springs back to life.
Put it this way - when I called up asking for a kernel upgrade to deal with this "little" problem, they shipped me an upgrade for their "MESA" (Linux renamed, mind you) that didn't fix the kernel issue at all. Duh.
Re:Wider is better (Score:1)
Join our Anti-Linux oganization here [bigcock.com].
Re:Why? What next, punch card readers for Linux (Score:1)
Re:Why bother? (Score:1)
Re:I could sure use NetBEUI (Score:1)
Pretty cool , but uhhhm, ... why? (Score:1)
But NetBEUI? Why would anyone use that in today's day and age. Unless you're designing a high speed system or a standalone custom (like in a auto or something), I see this release news as mostly noisy output from another "me too" open source come lately.
While were at it, can somebody get the source to Lantastic released. I think that would be cool (not).
--Aaron Newsome
Re:OS/2 (Score:1)
The crew Dave Cutler brought from Oregon were going to be building 32-bit OS/2 v.3. The problems in the relationship with IBM were exacerbated by MS insisting that the next OS/2 MUST be 32-bit, while IBM was convinced that a lighter, 16-bit version would still storm the market, given a little more time.
Gates & Ballmer got the agreement to split 16 and 32 -bit development with IBM on company lines. It was only as Win3.x applications began to emerge as the business standard that MS got the courage to implement a Win API subsystem on the NT kernel, as opposed to a PM subsystem.
The console-based OS/2 subsystem present through NT 4 was a vestige of this original direction.
Enough of this! See what talking about NetBEUI will dredge forth from the depths!
These were not systems that were designed or engineered... Rather, they were politic'ed and marketed into existance!
--Jeremiah
How soon we forget... (Score:1)
The MS branded box (plain white, with a RED stripe) came when you orderd your Toshiba laptop with OS/2, etc.
We had one of these. A 386SX, with an orange/mono VGA -- AC power only!
--Jeremiah
Re:Still a few things you can do with NETBEUI-II (Score:1)
This is not passed onto any "network co-processor" at the NIC, etc.
InterProphet is one of many companies embedding the TCP stack in Silicon, to achieve higher performance this way. Still, AFAIK, a "stub" TCP stack would need to be patched into the kernel sources for this to work in Linux. If the masq features and all the other goodies are not supported on the "silicon stack", you're out of luck. You really aren't on the Linux (BSD, etc.) TCP code anymore.
--Jeremiah
Re:This is excellent news! (Score:1)
Care for explaining with more details how to do this?
Re:OS/2 (Score:1)
It was a bit like that moment in Land of the Pharaohs [imdb.com] when Princess Nellifer (Joan Collins) lets the Pharaoh bleed to death in front of her, to further her own ambitions.
george
Let me try again ... (Score:1)
Anyway, isn't netbeui supposed to be a lot "lighter" weight protocol that tcp over ip? Lighter as in less bytes. which means more throughput.
Could I maybe run MPI or PVM over this on a cluster and gain some speed? TCP is known to be a dog for dsitribted computing, maybe this is a better off the shelf solution.
I would appreciate anyone who has tried this speaking up and letting me know before I blow time on it
later,
dv
oh yeah ... (Score:1)
i suppose I should dig up some doc on netbeui, huh?
Re:Actually, this can be useful... (Score:1)
The ability for linux to understand many of the legacy protocols is definitly a great plus. It is great for a small buisness that has a few machines and is in need of a cheap (as in $$$) solution to replace or to communicate with some piece of hardware that they can no longer find. NetBEUI, although being an old outdated protocol, is still in use..
For many small buisnesses, once they see that it can solve one problem.. the next question I usually get is in the line of "so... what else can this Linux thing do..."
--
Amarillo Linux Users Group [alug.org]
Re:Why bother? (Score:1)
Lookup MARS NWE... (nwserv)
--
Amarillo Linux Users Group [alug.org]
Oh, god, this is great... (Score:1)
Now I have to go back and tell all the people I've been telling no, Samba is NetBIOS over TCP/IP, not NetBEUI that now Samba is (or will be, shortly) also NetBEUI. *sigh*
This is good news in fact. Any user can set NetBEUI up, since there's nothing to setup. It doesn't help my old fight against former co-netadmins to stop them from polluting the network with NetBEUI, who will probably install it by default now, but so is life, you have to lick it one day at a time...
Re:"Net-Boo-Ee" (Score:1)
Re:Prior Art (Score:1)
It may not be theirs to GPL. Samuel F.B. Morse was using it about a half a century before Marconi, Tesla, Edison, Sarnoff, any of those guys. No doubt his heirs are still vigorously defending all patents, trademarks, copyrights, service marks, etc. You might even want to think twice before using S.O.S. brand soap pads.
Re:Still a few things you can do with NETBEUI (Score:1)
Re:this is a microsoft product! (Score:1)
Actually, it is. (Score:1)
Re:But... (Score:1)
Re:Whiners (Score:1)
netBEUI (IPX?) had its place, now its TCP/IP only. (Score:1)
NetBEUI was nice when you had a small office with a few machines and needed a quick and easy lan to setup. It still is the easiest way to setup a few windows machines to share files or printers.
But for me, its TCP/IP and a DHCP server.
One last thought, since its easy to setup, maybe it would be good for Home Stereo Equipment. No IP, just NetBEUI the linux(mp3?) box.
Brook Harty
-IronWolve- Tribes, UT, Half-life.. No time to code!
Re:Marconi Corp. GPL's the "Morse Code" stack (Score:1)
--
" It's a ligne Maginot [maginot.org]-in-the-sky "
How about backwards compatibility? (Score:1)
- 8Complex
Re:Marconi Corp. GPL's the "Morse Code" stack (Score:1)
I totally agree. (Score:1)
I had my head up my ass there in my clamor to denounce NetBEUI.
Replace "Bandwidth" with "Efficiency."
:)
-Kevin
Re:Still a few things you can do with NETBEUI (Score:1)
Re:Why bother? (Score:1)
--
Re:This is excellent news! (Score:1)
It does use lots of memory. It can't be installed directly onto a floppy disk (install to hard disk, selectively copy files to floppy, it will fit.) You need to manually install the DOS NDIS NIC drivers by editing INI files. It should work from a NIC Boot ROM. With some trickery, it should run under Windows 9x.
It's a pain in the ass, but when you get it working, it works pretty good (although much slower than NetBEUI).
--
Hey -- I want NetBEUI! (Score:1)
Maybe MS's TCP/IP filesharing is just broken. Doesn't matter. If you can get away with using NetBEUI for Doze/Samba stuff, I recommend using it.
(Auto configuration and non-routability is also a plus -- If you have cable/DSL, you can unbind SMB/"WINS Client" from TCP/IP on your NT boxes and use NB for local file+print, and worry less about the evil haxors.)
--
Re:Just a thought. (Score:1)
--
Re:OS/2 (Score:1)
The word "LanMan" is still all over the NT documentation. The "Server" service used to be called "LanMan Server" in NT 3.x, for example. MS claimed that it was based directly on the OS/2 networking code, and therefore bug-for-bug compatible. Microsoft wanted to hang onto that 10% market share when they moved to NT, so the networking was taken wholesale from LAN Manager.(Things started to change a bit around NT4 SP4 -- it was no longer possible to have mixed OS/2 and NT domain controllers, for example.)
IBM's version was/is known as "LAN Server" -- OS/2 Warp Server 5.0 is actually based on the Warp Client 4.0 codebase, the reason for the version number difference is MS's escalation to 2.0 back in the 1980s. The more things change, the more things seem to stay the same.
--
Re:Sorry, gotta disagree on #2 (Score:1)
(I'm aware Cable works differently, but I probably won't care how until they start installing it here in 2003.)
--
Re:Why bother? (Score:1)
AppleTalk+PostScript might be a better bet.
--
Re:samba = netbios over tcp/ip... (Score:1)
--
Re:Why bother? (Score:1)
The number one way that Win home boxes are hacked is leaving file sharing enabled on TCP/IP. (Vendors seem to ship this way.) NetBEUI is a great, but not perfect, solution to this problem.
--
Re:Correct me if I'm wrong... (Score:1)
(Could it be something wrong with NT's SMB/TCPIP instead of something right with SMB/NetBEUI? Got me!)
--
Re:Just a thought. (Score:1)
--
Re:samba = netbios over tcp/ip... (Score:1)
Re:samba = netbios over tcp/ip... (Score:1)
Well, you could use NFS rather than FTP, you know. If every machine exports the necessary directories, you basically have a network neighborhood. Especially if you have some sort of automounting magic going on - I can cd into any other developer's /home (assuming I have permissions) for example. So they are my "network neighborhood" in a sense. And you could then access the various NFS mounts through whatever filesystem browser you want: mc, kfm, etc.
Or are you thinking of something totally different?
Re:Still a few things you can do with NETBEUI (Score:2)
If you set this up, on its own interface, you can "firewall" the NIC.
If your scale is small enough, the DB can be a single-machine, connected by a cross-over cable!
TCP is wonderfull. But it is a CPU eater! Especially under heavy connection loads.
NT certainly benefits by using NetBEUI in this situation. The payoff is lesser for Linux, but it doesn't hurt, either...
--Jeremiah
Re:Still a few things you can do with NETBEUI (Score:2)
EXACTLTY!
I was about to make this point, when I saw your post. NetBEUI is a non-routable protocol, which makes a perfect little link for things like Web 2 DB.
This is how I have protected the NT-based projects around this shop. This works bets on a dedicated NIC, and small, dumb-hub. Then NetBIOS chattiness is isolated from your IP network.
--Jeremiah
Insightful? (Score:2)
Re:Insightful? (PEDANTIC NOTE) (Score:2)
Again, the idea is that while it's not going to be used in a large-scale network environment, it'll be handy to have for people in quirky, highly-underfunded environments where Linux is probably already attractive due to low resource requirements and compatibility with older, less common hardware.
Some thoughts (Score:2)
Second, the more network protocols Linux supports, the more likely it is that someone'll invent a protocol-independent wrapper that'll let you run a server or client over any protocol you like, transparently.
(Hey! I think it'd be neat if you could run a web-server over a NetBEUI connection, through an AppleTalk firewall, over a DECNet LAN, via an Econet router, onto a TCP/IP network, without any of the computers or software packages at either end caring what anything else used.)
Re:I could sure use NetBEUI (Score:2)
Under Linux, the commands would look something like this (this is off the top of my head. YMMV. IANAL. IYHDBUIANR (if your hard drive blows up I am not responsible):
(those commands are probably wrong. Subnet calculations like that are a pain in the neck and I'm too lazy to check them).The only downside would be that all your traffic would still go out over the cable modem. To fix that (mostly), trade in your hub on a switch. Switches are getting really cheap nowadays.
--
Re:IMHO -MAJOR QUESTION: How does "NetBEUI" NOT SE (Score:2)
No, because Microsoft doesn't use Procom's implementation.
Discovered by reading the source code? Probably not many, as a lot of the code path for handling SMB is probably in the SMB code, not the NetBEUI code - and, as indicated, the code Procom is GPLing probably isn't the code Microsoft are using (unless they licensed it from Microsoft, which I think is extremely unlikely).
What "New NetBEUI security holes"? And why would then then "HAVE to embrace Open Source" for this?
Yeah, they got it by other means, i.e. writing an implementation thereof.
A protocol isn't "open-source" or "closed-source", it's publicly-documented or secret, and NetBEUI falls into the former category; see this document [ibm.com] under "The NetBIOS Frames protocol".
Re:IMHO -MAJOR QUESTION: How does "NetBEUI" NOT SE (Score:2)
Well, if multiple vendors independently implement the same protocol, they can use the name of that protocol for their implementation.
As I said in my previous message, these are two presumably independent implementations of the same protocol.
(Whether "NetBEUI" is the correct name for the protocol is another matter; the IBM spec that documents it [ibm.com] calls it "the NetBIOS Frames Protocol", and Microsoft calls it "NetBEUI Frame" in the Windows NT Server Networking Guide document in the NT Server Resource Kit:
but that's another matter.)
It is an independent implementation of the same protocol, so it does have something to do with it. It just doesn't share code with it.
This doesn't ipso facto mean that there will be any new security holes (besides, the protocol was documented), and doesn't ipso facto mean that Microsoft would have to "embrace Open Source" to deal with those, unless by "embrace Open Source" you mean something other than what is normally meant by "embrace Open Source", i.e. open-source their protocol implementation.
Because what they're open-sourcing is their implementation of an existing, documented protocol. They are NOT "open-sourcing" the protocol itself - the protocol is already publicly documented. Given that, I think that it's incorrect to say that they're "open-sourcing NetBEUI", just as it's incorrect to say that Berkeley, for example, "open-sourced TCP"; it's correct to say that they're open-sourcing their implementation of the NetBEUI (or NetBEUI Frame, or whatever) protocol.
Re:Actually, it is. (Score:2)
It may be "a MS protocol" in the sense that Microsoft uses it, but that doesn't ipso facto mean that Microsoft invented it.
(It also doesn't mean it's necessarily some Secret Proprietary Protocol that Microsoft have only just now made public; it is, in fact, not such a protocol.)
Re:samba = netbios over tcp/ip... (Score:2)
Better than a poke in the eye with a sharp stick, I guess, but more pleasant might be a combination of smbfs and an automounter that understood SMB (knew which SMB servers had announced themselves to the browser, knew how to query an SMB server to see what shares it was offering) - that would let you use the KDE 1 file manager, or the KDE 2 file manager, or GMC, or Nautilus, or ls, or... as SMB browsers.
Great for small footprint DOS clients (Score:2)
I tried that with NetBIOS over TCP/IP (LANMAN, MSClient) but its footprint was too big: lots of TSRs gobble up memory which did not leave enough room for the PABX software.
And yes, as you can see on my homepage I have tried several DOS clients with Samba. The only DOS client which looks nice (little low memory usage) is the IBM LAN client but the specs say it only works with original IBM network cards. However, I got tipped that you can actually use any NDIS2 driver. Dunno if that is true, but at least I now have two options!
So all in all, I can't wait to get my hands on this one!
Re:How does this help Samba? (Score:2)
Re:Just a thought. (Score:2)
SunRays redirect their USB over 100Mb ethernet, and there is no latency at all til the load average starts pushing 120 on the server (at which point we start killing netscape processes -- not like they don't crash at random anyway)
samba = netbios over tcp/ip... (Score:2)
I have a home network with a bunch of windoze and linux boxes, and I use samba on the linux boxes and Windows file sharing (i.e. netbios) on the windows boxes, but I have only TCP/IP turned on--this is a 100% NETBEUI free zone.
--
NetBEUI- Evil! (Score:2)
I preach in my classes that unmitigated broadcasts (i.e. anything but ARP or DHCP initialization) are EVIL. They suck your most precious resource - bandwidth - like a hungry vampire.
NetBEUI is even more evil because you have a choice NOT to use it and use TCP/IP.
The only reason to use it is for MS-DOS clients...and I would segment them away from my network using a dual homed machine with TCP/IP bound to one adapter card (to the main network) and NetBEUI bound to the other (to the DOS machines).
NetBEUI's dead, folks. Don't pollute the efficiency of *NIX with this crap.
Kevin W. Bunn, MCSE/MCT
MCP ID # 1198191
Re:Why bother? (Score:2)
3: (Cable modems again). Screwey Cable Cos can put different machines on the same modem onto different class Cs. This makes TCP/IP really bad for moving data arround because you are limited to you modem bandwidth.
what you just said doesn't even make sense, secondly, you are limited to the bandwidth of the line attached to the cable modem, and lastly, under what circumstance would you not be limited to the bandwidth of your line?
what he's trying to say is, because the subnets are different, all data from one machine sent to another on the same hub will be sent through the cable modem... unless the modem is smart enough to route those back without sending through the cable line, the packets will go out to the router and back again.
with two machines on the same subnet, the cable modem isn't even involved in the connection
More than just a GPL present...? (Score:2)
Re:Still a few things you can do with NETBEUI (Score:2)
Re:Why bother? (Score:2)
However, if we can get this supported by VMWare, we can allow the currently dual booting analysis stations to remain in Linux mode all the time (which is what we prefer).
Time to check into the source, and fire off a request to VMware...
So, to us, this is potentially far from useless.
Yep.. I saw a box begin thrown out (Score:2)
OS/2 v1.2, I think - I could have grabbed it, but really, what good would it have been?
Re:Pretty cool , but uhhhm, ... why? (Score:2)
Now, with this, everything changes.
Re:Why bother? (Score:2)
Re:Actually, it is. (Score:2)
Sorry, gotta disagree on #2 (Score:2)
My cablemodem (and the cable modems of everybody I know) is a bridge, not a router, so the NetBEUI and IPX traffic gets spewed out, choking off the neighbor's bandwidth.
Other manufacturers may make cablemodems that are routers, but mine (Terapro) and those of most of my friends (Motorola) are bridges, which means that NetBEUI would indeed be propagated.
Re:DOS has wunnerful TCP/IP support (Score:2)
It does not support dns or even wins (or NetBEUI for that matter) and it uses lots of room.
Re:Please please please (Score:2)
-----------
"You can't shake the Devil's hand and say you're only kidding."
Re:Just a thought. (Score:2)
Re:Just a thought. (Score:2)
Two ports work well for most people... What someone needs to do is make a keyboard with a built in hub (maybe only one port) for the mouse (kinda Macstyle)... saves a port on the back of the box, after all. Just a thought... I'm sure there's one out there.........
Actually, this can be useful... (Score:2)
Yes, it's an old protocol. Yes, nobody in their right mind wants it on their network. But, along with TokenRing, DECNET, TCP/IP, IPX, and Appletalk, if we add NetBEUI, we get to be the glue that holds the network together. That's not a bad way to force your way into the server room...
Re:X.25 and TCP/IP (Score:2)
The most common X.25 environments I saw in the US used these for terminal emulation, so you could take your 3270 controller or your dumb-paper-terminal controller and log on to a mainframe or timesharing host, sort of a bondage-oriented version of async-dialing to a Unix host. Unlike frame relay networks, where each customer has their own permanent virtual circuits between their own locations, X.25 was designed for telcos and PTTs who could connect you to any of their customers, if you knew their network address (equivalent to knowing a phone number. To add some security, there were features like Closed User Group.) This basically meant that anybody within France, or anybody within Germany, could set up an X.25 connection to anybody else there, and could sometimes do international sessions as well. It doesn't matter that there's no Internet protocol if everybody you want to talk to is on the same Layer 2 network, so this was how computers at European universities talked to each other.
The canonical book on why all of this is a bad idea and TCP/IP is better is
M. A. Padlipsky's The Elements of Networking Style and Other Essays and Animadversions on the Art of Intercomputer Networking. Prentice--Hall, Inc., Englewood Cliffs, NJ, 1985. I don't totally agree with him - X.25 did error-checking at Layer 2 because it was designed to run over French barbed-wire, and while it might have been faster to restrict those functions to Layer 4, that mainly became true when fiber-optic long-haul networks made bit error rates many orders of magnitude lower than the original facilities X.25 ran on. But he's mostly right on.
BTW, calling ISDN a "layer 2 protocol" is pretty dodgy. The D channel does run X.25, with whatever features the telco feels like supporting, but the Bell Labs and Nortel telephone switch developers never really had the clue about what data users want (:-), and computers had gotten faster by the time ISDN was priced for consumers, so what everybody really uses are ISDN B Channels (which provide Raw Bits at 64 or 56kbps) with the end-user's choice of Link Layer framing protocols (I forget if that settled down on V.110 or V.120?).
How does this help Samba? (Score:2)
What Samba really needs is the ability to run as a Primary Domain Controller. Will this contribution help meet that goal?
Re:Why? What next, punch card readers for Linux (Score:2)
:)
SEAL
Yet Another Linux Protocol (Score:2)
Correct me if I'm wrong... (Score:2)
If my server is sending out X+Y size packets (X is the TCP/IP wrapper, Y is data) wouldn't it be better to just be sending Y size packets instead? This will make Linux that much closer to NT in terms of raw speed at the high end. You're not sending out larger packets, either to the server or the clients.
Its about time! (Score:2)
On the upside, it will make Linux even easier to setup in small networks, where TCP/IP is not required..... Where you would find this scenario, I do not know.....
Just my 0.06CAD worth...
But... (Score:2)
Re:Correct me if I'm wrong... (Score:3)
No. SMB-atop-NetBEUI is no more "native" than is SMB-atop-NetBIOS-over-TCP.
Yes, the NetBEUI headers take fewer bytes than the NetBIOS Session Service, TCP, and IP headers, but it's not at all clear that this necessarily buys you that much.
Re:this is a microsoft product! (Score:3)
No, Procom have GPLed an implementation of the NetBEUI protocol, specificat ions for which [ibm.com] have been available for a while. (Look in "The NetBIOS Frames Protocol" section of the IBM document in question - yes, IBM, who were involved in it, as well as in SMB.)
Re:How does this help Samba? (Score:3)
SMB requests and replies are stuffed into the payload of NetBIOS-over-NetBEUI (or "NetBIOS Frame Protocol") packets, just as they're stuffed into the payload of NetBIOS-over-TCP Datagram Service and Session Service packets, etc.. SMB doesn't, by and large, need to know or care what protocol NetBIOS runs atop.
why broadcasts suck...and Netbios over IP/SAMBA (Score:3)
When an ethernet card receives a frame, it evaluates whether or not the machine is interested. The frame is important and requires processing if one of the following happens:
1. The destination address of the frame is the MAC address of the ethernet card (unicast)
2. The destination address of the frame is a broadcast
3. The destination address is a multicast the ethernet adapter is interested in
An "interesting" frame results in the ethernet card generating an interrupt, which the OS must then decapsulate and analyze, even if the OS is truly not interested. Broadcasts generate a large number of "interesting" packets for the nic card, which triggers a large number of interrupts on the PC, which in turn takes CPU cycles away from other important tasks (like SETI@home
A side note....If I remember correctly, this was the initial problem with the first DOOM. The first version of DOOM used broadcasts, which killed all stations on that LAN, even if they weren't running a network protocol. A later patch updated DOOM to use unicasts instead.
NetBIOS over IP applications, like SAMBA, has the same issues. It generates broadcasts to announce "i have these services", "wheres workgroup so-and-so?", etc., etc. The saving grace of Netbios over IP is the functionality of WINS (Windows Internet Name Service, the netbios equivalent of DNS...just less scalable). With WINS, stations can register and look up other hosts on the network WITHOUT using broadcasts.
If you run Netbios Over IP on a sizeable network, across routers, or both, USE WINS. Or enable WINS resolution via DNS. And disable NetBEUI and NetBIOS over IPX. If you run NetBIOS over multiple protocols, it will broadcast over each of those. Yuck. Bye-bye network.
--
John Kramer
this is a microsoft product! (Score:3)
Sweet jesus, do you know what this means? It means I just lost atleast a dozen bets with my friends... I have to go shave my head bald now... good grief... it's 70 and balmy in hell right now!
and In a Related Story (Score:3)
Both Tesla LLC and Marconi Corp. were unavailable for comment.
Guys... forget the RIAA and MPAA lawsuits we all have to come out in force for this one. Can you imagine what would happen if we lost? The precedent that gets set? Please... buy the t-shirts that copyleft is producing showing the "Morse Code" translation algorythm! Support the EFF and lets get our voices heard.
:)
Re:Just a thought. (Score:3)
Yes, but not at the same time...you can choose one or the other for each connection. There are, of course, hubs and switches that convert the two so that your network can have both, but it's not quite the same thing.
I don't see why I'd want my mouse over (even a personal) ethernet (that's only connected to my computer). More latency is bad - I expect and demand immediate response from my pointing device... no slowdowns are acceptable. Network printers are quite common and have been for years, though not in a home setting. There are many outboard ethernet -> parallel converters, and the smarter printers have internal cards for them - a net printer with 32/64/128MB of ram is definitely the way to go, in terms of not sapping resources (parallel ports are aweful, USB better).
Mice need clocking and power, and you can't duplicate that over standard ethernet. An interesting idea, though.
USB is one big shared interrupt for all of your peripherals - so there's no need for an extra network connection, and it should save at least one or two IRQs (serial and parallel - leaving one serial open).
As for the relative pricing, I'd say USB is a lower cost solution for most things - not much translating and address matching. Much less hardware. Very little protocol overhead (as opposed to a LAN). Stands to reason the amount of hardware should reflect this.
I could sure use NetBEUI (Score:3)
I've got a 10Mb LAN set up at home with two computers, and the hub also hooks up to a cable modem. I am paying for two IP addresses from my cable company (don't ask me why I'm not using masquerading. Both machines are dual-boot, and it's too much a pain. Besides, technically I'm not allowed to do masquerading anyway).
The problem is that the two IP's always end up being on different subnets (I don't know why Videotron does this to me. It's DHCP, and they say that they can't do anything about it)! This means that for the two machines to talk to each other over TCP, packets have to actually leave my LAN, travel over the cable modem to the router, and then back through the cable modem to the other machine.
However, with NetBEUI my problem is solved, and I can transfer files from one machine to the other without having the packets routed out of my LAN and back in again.
Re:Why bother? (Score:3)
1: It's not TCP/IP and it's not routeable, therefore non attackable unless you are on the same network.
2: For people on cable modems, NetBEUI is a better protocol for file sharing because it doesn't get spewed out to the entire network.
3: (Cable modems again). Screwey Cable Cos can put different machines on the same modem onto different class Cs. This makes TCP/IP really bad for moving data arround because you are limited to you modem bandwidth.
4: A brain-dead AOL user can set it up.
Nuf Said.
Why bother? (Score:3)
let us now praise NETBEUI (Score:4)
We ran Lan Manager 2.0 with one server (running Microsoft OS/2!) and forty DOS/Windows 3.0 clients. We evaluated and immediately rejected TCP/IP because (a) the server-side stack made the server blow up and (b) the client-side stack consisted of umpteen little TSRs which together left enough real-mode memory to run EDLIN. I should also point out that we British had brilliantly chosen X25 rather than TCP/IP as our national network protocol so the Internet dawned rather late here.
NETBEUI was succesful here for three reasons. Firstly it was "on" in a default installation of server and client. Secondly it was chatty and self-discovering, a bit like Appletalk (another technically crappy protocol that nevertheless made life easy when doing small setups). Thirdly it was monolithic and small in memory.
Now you aren't supposed to go above about 200 nodes in a bridged environment like this, as any fule kno, but we eventually had about 2,000 nodes running NETBEUI quite happily. It was only last summer that we finally got around to implementing VLANS on the central Cisco - and this brought the house down, as Microsoft's SMB clients (in 3.11 and 95) are pretty broken when it comes to working on vanilla TCP/IP with just a minimal LMHOSTS file and DNS support (we didn't want to use WINS).
Nowadays NETBEUI only operates in one of our VLANS, the one containing the main servers and the public PC labs. We've recently been remote-booting 95 using Lanworks ROMs and BOOTP. They load a floppy disk image which has the real-mode Lan Manager client (including NETBEUI), do a bit of hard disk integrity checking/maintenance, then whack the real-mode client on the head, vapourise the virtual A: drive, and execute Windows 95.
Works like a charm.
SO... what is the effect of this announcement on us? Well, back in the days of DEC we bought several big Alphas. We've been feeling pretty annoyed since Compaq/Microsoft ended development on this platform. Now, assuming that SAMBA gets modified to play nicely with this NETBEUI stack, we can give them a new lease of life by running Linux on them instead.
george
Just a thought. (Score:4)
Could NetBEUI over Ethernet be a replacement for USB? Just name your mouse "mouse", your printer "printer", etc. You could plug it into a dedicated network card, a hub, or even directly into the network. I know they can make the cables reasonably thin, they do it for PCMCIA cards already.
How is USB any better than ethernet? Ethernet will even allow you to run both 10 and 100 Mbps devices on the same medium. I suppose the only thing you loose is the ability to line-power devices. With PCI you should even be able to share interrupts.
What's cheaper these days, an ethernet IC, or a USB IC?
They're just dumping a product that doesn't sell (Score:4)
Re:How does this help Samba? (Score:4)
No, Samba does NetBIOS over TCP/IP, NetBEUI is another kind of network protocol, like TCP/IP, or IPX/SPX.
NetBEUI isn't routable though, which is usually a bad thing.
Microsoft itself has been moving away from NetBUIS to NetBIUOS over TCP/IP for Windows networking.
What Samba really needs is the ability to run as a Primary Domain Controller. Will this contribution help meet that goal?
No, but the beta version of Samba already has this, you just have to compile the code yourself.
IIRC, Samba PDC code doesn't work well with BDC though.
George
Nothing wrong with that (Score:5)
Don't dis them for doing something we, as Free software advocates, have been asking companies to do -- namely giving mothballed products to everyone rather than hoarding them.
Even if NetBEUI isn't viable anymore, it has value as an Open Source application:
Opening code that companies no longer value is more than just good PR -- it's a valuable practice, and it should be encouraged on general principal.
phil
Marconi Corp. GPL's the "Morse Code" stack (Score:5)
Not all agreed that this boon to humanity was a welcome offer. "Telegraphy?!?" bellowed Peter D. Spittle, a Linux enthusiast and Networking consultant to the International Megabuck Banking consortium. "Who the heck uses that anymore in a competitive business environment? Maybe as a slow secure-channel protocol to thwart crackers busting in on your IP router, but for everyday use the manual routing personnel can delay packets for as long as an hour, depending on coffee breaks".
However, officials for the Marconi Corp. insist it is still a relevant protocol. "Look, say the line between Witchata and Flagstaff goes down, you can still get a ticker tape of the message to our guy on a horse who'll get it thru! The message must get thru!!", repeated Mr. Oldtimer, slumping in his chair as the whiskey bottle fell to the floor.
This is excellent news! (Score:5)
A lot of people would like to be able to boot diskless DOS/Win95/Win98 boxes from a Linux server. There isn't a functional way to do that using TCP/IP. Yeah, there are some DOS IP stacks but using them prevents IP from working once Windows boots up.
Currently the only real way to handle it is using Netware shares. But now it should be possible to do it with NetBEUI instead... a preferable solution for booting a Microsoft OS (call it evil if you want.) At home, this will let me run my Windows box without a hard drive just by hanging it off my Linux machine.
Heck, this would be useful if only to recover a crashed Windows box without a rescue disk. :)
NetBEUI is not dead yet!
Because _somebody_ will want it. (Score:5)
The fact is, someone will use it. How many times do you hit "n" when you're configuring your kernel? Lot's I'll bet. I know I do. I really don't give a crap about "Amateur Radio AX.25 Level 2 protocol", and yet somehow it snuck its way into my config script. So what? I just hit "n", and then forget about it.
Just because you don't (or the majority of users doesn't) care about a particular feature, it doesn't mean that there's not a place for it.
Still a few things you can do with NETBEUI (Score:5)
In a DMZ you can setup a web server and use netbeui to connect to a resource server in the same DMZ and keep your resource server safe from several types of hacks, not perfect but still gives old netbeui a job