Slashdot Mirror
Procom to Release NETBEUI for Linux
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).
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
"Flyin' in just a sweet place,
Never been known to fail..."
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
"Flyin' in just a sweet place,
Never been known to fail..."
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.
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.)
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
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.
--
-- Slashdot sucks.
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 under "The NetBIOS Frames protocol".
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 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.
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.)
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.
A DOS client can be useful in some cases. Diskless workstations have already been mentioned. Our PABX runs under DOS, now I can let it write its logfiles to a Linux machine for processing!
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!
-------
Warning: Slashdot may contain traces of nuts.
Samba 2 does have PDC support. It's BDC and domain trust relationships that it needs right now. IntelliMirror tech would be nice too (directory replication). This won't help further any of those goals.. it'll just allow linux to have backwards combatability with other windows products. Which is nice, but it won't help Samba.
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)
I've finally had it: until slashdot gets article moderation, I am not coming back.
Samba doesn't use netbeui -- it uses netbios on TCP/IP.
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.
--
This is not a flame. I am a Microsoft Certified Systems Engineer/Microsoft Certified Trainer. I am not an OS bigot (I also run Linux, MacOS, AmigaDOS, and OPENSTEP), so no flames, please...:) I just have to say one thing: NetBEUI sucks. I mean, for Chrissakes, it's a BROADCAST based protocol. Even with MS machines, the stack has to pull EVERY packet all the way up to the Application Layer of the OSI model to check whether or not the machine name matches it's own! I mean, we already have a fast, well desgined protocol to run our networks on (TCP/IP) and a way to make it almost zero-administration (DHCP/BOOTP).
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
My posts don't reflect the opinion of my employer, and my employer's opinion doesn't influence the content of my posts.
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
dennis
j. scott olsson
Yes! In fact NETBEUI is more efficient than TCP/IP for DB connections (many set-up and tear down events which are expensive in TCP/IP, especially on NT). Some NT people doing this for DB back ends to web sites already.
We still are using mission critical apps that use NetBEUI as part of a data gathering and distribution system for scientific experiments. A DOS box collects the data and distributes it to NT clients (using NetBEUI) for further processing. The apps are closed and proprietary, so we don't have much choice about the networking. :(
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.
"It's overkill, of course. But you can never have too much overkill." - Anonymous Slashdot Coward
OS/2 v1.2, I think - I could have grabbed it, but really, what good would it have been?
Now, with this, everything changes.
GNU/Linux. The Freshmaker.
Try smbclient
IBM invented it and Microsoft absorbed it. Now Samba has another feature to be added...
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.
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.
I know that client.
It does not support dns or even wins (or NetBEUI for that matter) and it uses lots of room.
Mielipiteet omiani - Opinions personal, facts suspect.
-----------
"You can't shake the Devil's hand and say you're only kidding."
The costs that I was figuring in were in the devices themselves (i.e. printer, mouse, keybd, etc). I can find USB mice for $15-20 (albeit not great ones - but an MS PS/2 mouse runs much more), and 4 port USB hubs for $16... the outboard devices can be real cheap. Just about every motherboard has USB support now, so it's really not a big deal that way. You could even calculate in that $7-50 savings for not buying an ethernet card, using yor model. The question is the ASICs in the peripheral, and how that price compares to a similar ethernet ASIC... which may be very prevalent, but are far more complicated with communications, and can be overkill for a lot of things.
"It's tough to be bilingual when you get hit in the head."
Check pricewatch - you can find 4 port USB hubs for $16... for $18 you can get a colored one to match your iWhack... harldy $70... There are a number of printers that directly support USB - I wouldn't think a conversion there would save you all that much, since the USB link would still have to do all of the transfers at parallel speed, which is what your computer wants to avoid... I don't think I've ever even seen a kludge box of that nature 8^) Ethernet -> parallel cards with buffers or network printers with memory provide a nicer solution - one quick transfer. File and forget, so to speak. If the USB converter had some memory, then that would alleviate much of it, but it's not a very clean solution...
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.........
"It's tough to be bilingual when you get hit in the head."
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...
www.eFax.com are spammers
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?).
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
I thought Samba already managed NetBEUI interoperability pretty well. What kind of improvements does this bring to the table?
What Samba really needs is the ability to run as a Primary Domain Controller. Will this contribution help meet that goal?
Hmm... well, IP was invented before NetBEUI, no?
:)
SEAL
I am yet again amazed that the /. crowd, which seems to be have a large Open Source/Linux crowd, would criticize a post such as this one. One of great hallmarks of linux is it's compatibility to older stuff, especially hardware. Try running the latest m$ OS on an old piece of hardware on an old network and see just how well it does. At least with linux you have a chance. Why should people care if someone decides to Open Source xyz protocol? You're certainly not forced to use it. Most likely it will be of benefit to someone, even if it is to see where someone else went wrong. :) I know this is flamebait.
..but isn't this good? I mean, Samba piggybacks SMB on top of TCP/IP, increasing packet size. Won't this let Linux do SMB natively, increasing throughput?
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.
-- Ever notice that fast-burning fuse looks exactly the same as slow-burning fuse? I didn't... (Edgar Montrose)
cool! Now Linux can join in with the M$ Boxes to flood the network with excessive NetBlooey traffic. Can you say 'Packet Collision'? I knew you could.
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...
Feed The Need[goatse.cx]
Have they told us how to pronounce it yet?
No, Procom have GPLed an implementation of the NetBEUI protocol, specificat ions for which 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.)
Broadcasts suck NOT because they suck bandwidth. Most LAN's broadcast bandwidth is a small fraction of the availabe bandwidth, but may still have a significant broadcast problem.
:) ). And broadcasts are forwarded on to ALL stations on a LAN, so all stations take that performance hit. Multicasts are like broadcasts, but the NIC card can be told to only subscribe to the multicast addresses it wants, so it doesn't have to process what it is not interested in.
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
John Kramer
God may be my co-pilot, but the devil is my backseat driver.
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 Tesla LLC filed suit against Marconi Corp for improper use of Patented materials. Tesla LLC claims that Marconi Corp. used their patented algorythms in the creation of the "Morse Code" protocol stack and will appear in Court on Friday seeking a priliminary injunction.
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.
:)
This space for rent. All reasonable inquiries will be entertained at proprietors discretion.
>Ethernet will even allow you to run both 10 and 100 Mbps devices on thesame medium.
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.
"It's tough to be bilingual when you get hit in the head."
I for one could sure use NetBEUI under Linux. Here's why:
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.
-- Will quantum computers run imaginary-time operating systems?
There are a few good reasons for NetBEUI. Here are a couple:
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.
Even very small LAN's now use TCP/IP. NetBEUI is a thing of the past. And where it is used, it is usually used incorrectly. I remember a large corporate network that bridged NetBEUI to over 2,000 nodes and hired me for big bucks to determine why their network was so unstable. Duh.
Screw Micro$oft.
Our site (a university in Oxford, but not the Oxford University) ran on NETBEUI for years and years. It was already well established when I joined in 1991, and some very privileged folk had network connections on - gasp - "the backbone" (a bit of coax that ran through ceiling voids and through the ducts between the buildings).
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
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?
As many have mentioned already, this product is so old and out-dated, no one really wants it. However, it allows Procomm to get a free image-enhancement with the Open-Source community. They give away something they don't want anyway, and in return, get lots of fuzzy feelings from us Linux geeks. I'm waiting for the day when a company like this GPLs a serious application that's actually worth something. Then, I'll be impressed.
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
In a move that rocked the open source community, the Marconi Corp. today announced plans to GPL their "Morse Code" telegraphy protocol stack, formerly widely used for telegram transmission. "Now that we have our entire office on the open TCP/IP protocol, we felt it was time to 'give back' to the community", said Paul J. Oldtimer III, his wrist still twitching from a long session at the key. "Our Morse Code Stack is the best in the business, with centuries of development and debugging that has left it the most mature protocol available."
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.
try { do() || do_not(); } catch (JediException err) { yoda(err); }
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!
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.
I'll be the first to tell you to get rid of Netbeui from your main network but there is one thing you can use it for.
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
The world isn't run by weapons anymore, or energy, or money. It's run by little ones and zeroes, little bits of data.