There are very good reasons for giving particular machines "fun" names which don't relate to their form or function, except perhaps in indirect ways. It's all about future planning. Here are some suggested principles to use when selecting names for machines on a network.
1. Don't choose names which relate to funcionality.
This sounds like a joke ("he's saying DON'T use helpful names? huh?") but I'm quite serious. The new machine you are now installing might indeed be destined to run the mail server. All the same, don't name it "mail" or "mail1" or anything like that.
Here's why. A machine can change its function, and a function can be carried out by more than one machine. And machines can carry out more than one function. There is no straightforward one-to-one link between names and functions - so don't try to force one.
It's quite possible that at some point this new machine won't be the mail server any more. At that point, being called "mail" would be a more likely to confuse people than help them.
It's equally possible that you might decide to run a news server on the machine - while it's still a mail server. Can you imagine the conversation?
"I need some setup information for Netscape. What's our mail server called?"
"It's called mail."
"Oh, cool. That's easy. Now, what's the news server called?"
"Uhm... also mail..."
"Oh. Well that's dumb. OK. Finally I need to know what machine our LDAP server is on."
"Uhm.. it's on 'news'".
Not impressive, I think you'll agree.
Here's what to do instead. Give the machines arbitrary names. Then put CNAMES in your DNS for the services pointing to the actual machines.
If you can do that, you can tell people "our SMTP server is called 'SMTP'" and "our news server is called 'news'" and they can keep those settings for ever - you just change what the CNAME points to. You can even make the CNAME round-robin across several actual machines for load balancing - all without the user needing to know.
This doesn't just apply to the traditional services, but also to your own applications. If you have a stock control computer which people telnet to, don't call it "stockctl". Call it "bart" and put in a CNAME pointing to it. Even if you think you'll never change anything, it's worth allowing for the possibility that you will at the start.
2. Don't choose names which relate to form.
This means, for instance, that if your new mail server is a Compaq, it's a bad idea to call it "compaq" or "compaq3" or "cpq00153533" where 153533 might be the serial number.
Why's this bad? Because this information is a) useless, b) hard to remember, and c) likely to become wrong.
If you have a hundred workstations mounting volumes off a machine called "cpq00153533" you're going to have a rough time the day you upgrade the box to "cpq00182243". (Such names are also hard to tab expand if you've set up tcsh to do that as I have.) Unless, of course you just decide to keep the old name, although it is now wrong as well as annoying.
If you've called your machines "dellXXX", apart from trying to remember that "dell159" is your mailserver and "dell195" your quake server, you're going to be in difficulty when you replace some or all of them with IBMs.
The fact is that the manufacturer, model or serial number actually tells you nothing you need to know about a system in day to day use. You might need to know about its disk configuration, contents of/etc/passwd, or available memory, but you will rarely need to remember if it's a 333Mhz or a 366Mhz - and if you do, it should be in your product inventory database (hosted on "ibm104032" of course).
So, the principles in summary:
Don't use functional names as hostnames. Put in CNAMES for the functional names instead. You'll save yourself lots of grief in the long run.
Don't use names describing the physical setup, as that's useless, annoying, and incorrect far too often to be relied upon anyway.
Applying these principles requires that there be an "intermediate" naming convention which deliberately does not convey information about function, and which also does not convey information about setup.
I would suggest that this naming scheme should use names which are easy to type and remember rather than ones which are repetitive and formal. "srv001" through "srv999" might look nice and orderly, but in fact is much harder to remember and type than "rivers" or "cartoon characters" or "80's arcade games".
> Geeks have been trained for this thier whole > lives; the forces of righteousness will surely > be blasted to bits.
Katz, you send out more crap than a hand grenade in a sewage works.
I'm aware how futile it is to try to penetrate your highly effective fact repulsion field, but here's some actual real information:
Many geeks are not religious...
...but many also are.
Many religious people are not geeks...
...but many also are.
There is no inherent conflict between geekiness and faith.
Indeed, many famous and prominent geeks are Christians. You might be aware (but you probably aren't) that Slashdot itself (together with many thousands of other sites) is written in a language called PERL. The geek who inveted PERL, whose name is Larry Wall, is well known as being a Christian. He isn't a in-your-face bible-thumping damnation-decreeing Christian, but hey, neither are most Christians.
At the end of the day, Katz, you are in no position to understand the minds of Christians or geeks since you are clearly neither.
He was being short-sighted; MS-DOS v1 didn't have any directories at all, and hence didn't need a directory seperator character. So they used the slash as the command-line switch character, as in fdisk/mbr. Remember, under DOS the space between the command and the switches are optional. So fdisk/mbr would be legal.
Then when MS-DOS v2 came along and needed to support directories, they couldn't use the slash as it would be ambiguous. So the "other" slash was used instead... the one which was already used as an escape character in UNIX. Which, to cut a long story short, is why Samba users everywhere regularly type four backslashes before their server name:)
You say you are just flaming. But those questions are very much in the Paxman style. He likes to make people squirm. But he isn't abusive, trivial or sensationalist; his subjects squirm because the questions are usually very perceptive.
I can easily see him asking "Are you ever going to produce a product that saves more time than it wastes?" or "When will you realize that stability is important?"
There was one famous interview where he asked a senior politician the same question thirteen times in a row until he got a straight answer. I look forward to seeing that same no-bullshit style used against Uncle Gates' carefully prepared marketing drivel.
It "only works if both sender and recipient want the message to vanish" as it says in the article. Having got the plaintext once, the recipient can obviously copy, print, or save whatever is there.
So, given that both sender and recipient have to agree, why can't they just agree to delete the damn' thing?
If there is a demand for this (and frankly I'm not convinced) surely it would make sense just to define a "Delete-After: " email header and work with that. Why involve encryption at all?
...but we all know that being technically good doesn't necessarily mean something will be a technical success, especially in the convention-bound world of corporate IT.
I am sitting in the computer support office of a company which puts NT boxes on people's desks. These boxes are used for the usual suspects - Word, Excel, Powerpoint - but also for running Reflection to connect to a big old UNIX box which runs the core business application. I look after the UNIX box, which just runs and runs, which is how I have enough time to post on Slashdot.
The Windows support people around me have a hard time. They are constantly running around installing and upgrading software on people's PCs[1]. Either that or fixing the problems people bring on themselves by changing settings or switching off their machine while the drive is writing. 90% of the problems I have are with users changing their Reflection settings so they can't connect to the UNIX box, rather than with the UNIX box itself - I'd hardly have anything to do at all if they were given dumb terminals instead of Windows boxes to connect with.
It seems to me that in this kind of environment, NCs would make a lot of sense. No local data storage. No local configuration to be mucked about with by users. All the advantages in terms of reliability and manageability of dumb terminals, but with plenty of local processing power. So the data stays where it belongs - in the center - but the processing is with the user.
Just think what a difference it would make in here. Software upgrades? Just do it once. Users screw up their configuration? Well, they can't.
Not that it is ever likely to happen. Oh well. Life as usual.
[1] Yes, I know with NT you can go a long way towards centralised applications and protecting the workstation from the actions of the local user. In fact, I believe that this has been done on this network as completely as it is possible to do so. And users still screw up their PCs. And techies still have to go around to do upgrades - to make sure those precious DLLs are in C:/WINNT or whatever.
You're missing the point. While it might technically have been "written from scratch" the design goal was to make it as similar as possible to desktop Windows. I'm not so much addressing the underlying architecture as the user interface, which is far more important on a PDA.
The Windows interface might be great on a desktop (though personally I hate it) but it is way to complex for a PDA. Compare it to the simple, effective, consistant EPOC to see what I mean.
Windows CE Take a bloated, mutated, and counter-intuitive desktop operating system. Remove most of its functionality. Squeeze it into a smaller display than it was ever intended for. It's fun for a while, but ultimately unrewarding.
PalmOS Desgined from the ground up to work in a small display. You can pull it out of your pocket and get to the data in an isntant. No fuss, no mess. You wouldn't want to enter serious amounts of text in it, but it's a very practical solution for the needs of the average business person. It's massively popular.
Epoc32 A clean and elegently designed system from a company who've been building PDAs longer than anyone. Designed from day one for mobile use - but aimed at people who really need a keyboard, either because they need to process documents on the run, or because they are geeks and like being able to telnet into their linux boxes from half way up a mountain - which is when the excellent cellphone integration comes in handy. Also let's companies easily develop custom apps in OPL for, say, insurance salesmen to use on the move. Massively popular in it's niche market.
There's a pattern here, I think:
Designed to a PDA environment - people love it.
Designed from a desktop environment - complete flop.
This is all about the clash between two views of the Internet.
When someone types "pez" into a search engine, what is it they are looking for?
The official "Pez" site, and none other.
Those sites which contain lots of information about Pez, which will probably include the official one.
The answer is, clearly I hope, the second. The problem is that corporates don't see the world this way. The thought that people might search for their name, but go to their multi-million dollar, often content-void site but instead go to the place where the information they actually want may be found, leaves them dizzy.
Meta-tags are a mechanism which allows the author of a page to specify some keywords which describe the content. It works reasonably well. It is not intended, and does not function as a mechanism for identifying the official site relating to a trademark.
As a non-lawyer, and in an utterly non-advice-giving manner, I'd suggest that attempting to use trademark law to prevent other people saying "my site talks about Pez too!" is probably asking the courts to go too far. But then I'd have said suing mcdonalds when you spill coffee on yourself was unlikely to succeed either.
If the law sides with the corporates on this, then it can only be because they don't understand what search engines are for (You want information, not marketing). And they will have made the wrong decision.
It can be very hard to respect the law sometimes, so I've given up on doing so for the time being...
You do seem to have an odd perception of what constitutes legal advice. If you read my post again, this time making some at least vague effort at understanding, you'll see that it constituted a question "what is an unregistered trademark?" and a suggestion for how trademark law *should* work.
I am not a lawyer, and I am not a citizen of the USA, but that's not going to stop me commenting on both anyway:)
First of all, WTF is an "unregistered trademark?". How can you know if you're violating an unregistered trademark or not? Maybe someone could clear up what they mean by this - but it sounds like nonsense.
Secondly, the point of trademark law is to stop company B passing itself off as company A by using the same or a similar name. So if your company has spent the last twenty years making "Miracle Widgets" and has gained a great reputation, you would be entitled to take action against a new company called "Miracles Widgets" who might be trying to pass themselves off to customers as you. On the other hand, your reputation as a widget maker would be irrelevent to, say, advertising, so "Miracle Advertising Consultancy" would probably not be considered to be passing off.
If I create a "Widget World" web site for discussion and news on the widget industry, I am perfectly at liberty to use the name of Miracle Widgets, even though it's a trademark, as long as there's no way someone looking at the site would think that my site was actually run by Miracle Widgets. It's this right that allows news sites, fan sites, etc, etc to exist. Just think how long ZDnet would last if they weren't allowed to use any trademarked names.
So the question is this; does trademark law in the US, either in statute or precedent, go beyond this simple protection of a business's name from any unscrupulous competitors who might try to deceive the public?
If it does, it's broken.
I fully appreciate that the law probably is much more complex than that. But it shouldn't be.
Let's assume for the moment that the law upholds the above principles, but doesn't go any further. (Laws that don't go far enough are a bad thing; laws that go too far are generally worse.) Let's look at the meta tags issue.
If I have a site which regularly discusses Miracle Widgets, then it would be entirely appropriate to use "Miracle" in the meta tags - the site would be a source of information about Miracle Widgets. As long as I don't actually try to sell people widgets, I'm fine.
Note that this doesn't mean I can't make money from the site. It doesn't matter if it's commercial or non-commercial. I'm allowed to discuss Miracle Widgets on the site in good or bad terms, as often as I like, as long as I never attempt to make them think I *am* Miracle Widgets. It's up to a court to decide whether I am engaging in legitimate discussion, or whether I'm trying to deceive the public. Simply using the word "Miracle" does not place me in breach of trademark.
Having a site which discusses Pez Candy is not in breach of their trademark unless I try to pass myself of as Pez Candy. I can set up a trading site for Pez Candy. I can write good or bad things about it. I can make money out of doing so. As long as I don't infringe their trademark (which means a lot more than just using the word) there's nothing they can do about it.
Does the law work this way? If not, why not? Doesn't it seem remarkably... fair?
I have a basic principle for evaluating all Internet projects:
"If you can't explain what it does in one sentence, it will fail."
I have read the linked article and looked through the epost.ca site, and I can't honestly say I'm much the wiser. The site hits you with page after page of "EPO will change the way Canadians communicate" but doesn't seem too keen to be tied down to exactly why that would be so.
For example, click on the "What does EPO do?" link. Sounds like a helpful one, yes? "EPO puts all your mail in one place" it tells you. "No more going from Web site to Web site to pay bills, view account details and get information. Now it comes to you in your private, secure, Electronic Post Office Box". That certainly makes it much clearer, doesn't it?
Then there's the promising-sounding "Frequently Asked Questions" link. You might expect this to answer the questions people seem to be asking here on Slashdot; questions like "Will I still get paper mail or will it be scanned in?" But instead the FAQ link gives you a huge and utterly uninteresting page full of reassurances about Y2K compliance. And only Y2K compliance; "our code-remediation strategy includes a logic-based solution known as windowing for interfaces to external partners." It will no doubt reassure Canadian taxpayers that this service, being launched as it is in late 1999, considers Y2K compliance to be "achievable". Whoopie-doo.
Anyway, here's the Andrew Crawford Patent No-Crap Distilled and Filtered Guide to the Canadian Electronic Post Office. FX: Fanfare
It's basically a webmail system.
You can't send or receive normal Internet email
You can send mail to and receive from other users of the system. This includes most banks, large employers, retailers, who have already signed up.
You can choose to get your bank, employer, retailer, etc to send you a bill over this webmail system instead of through paper mail. The mails you get will be a standard template with your details filled in (think credit card statement) rather than a bitmap. You will have the option of settling those bills over the EPO system.
There is no connection with paper mail whatsoever. Companies that aren't signed up for EPO will continue to send paper. Companies that you haven't asked to get bills from over EPO will continue to send paper.
If your penfriend from Australia sends you a paper mail, it will continue to arrive in paper.
If your penfriend from Canada sends you a paper mail, it will continue to arrive in paper.
If your penfriend from Canada is also signed up with EPO, they have the option of sending you the message using that instead.
So what's new here? Nothing really. It's a proprietary secure email system. The key to its success will be whether they get enough companies signed up to use it. Even then, they've failed to show any overwhelming reason why it's better than the existing email infrastructure.
I think they're making a mistake hyping it as a replacement for paper mail when it's really not. Such merit as it has consists in making life a little easier for people who already use the Internet to check their balances etc and pay their bills by centralising everything. There aren't a huge number of people who actually do that though - and those that there are often do so because they appreciate the interactive features of being connected directly to the company's database. (Want to transfer a balance from one account to another? Or see more details of this transaction? Just click.) This kind of feature will be absent from EPO.
But I don't think it will succeed, because the people marketing it don't seem to have any idea what it actually does.
> Riiight, and if you had 200 or 2000 servers, > the rpm solution would be *sooo* good.
The RPM solution would be ideal for 2000 servers. Even if you did have to do them all manually (which you wouldn't unless you were clueless), it would still be faster to issue a wildcard rpm command and walk away than to install SP5 and reboot.
Any half competent Linux systems administrator could trivially set up an automated system to roll out patches to any number of connected servers. There are lots of ways you could do it, using cron and either scp, ftp or nfs depending on how paranoid you are.
Sure, you'd have to install a script on each machine and set up a cron job - once. From then on you'd just place the relevent rpms in a nominated directory and go home. At 3am, or whenever, each of your systems has a look in that directory to see if there's anything there which updates its installed software, and upgrades using it if so.
Can you get that degree of functionality with NT? You could install PERL and cron on an NT box and get the scripting working - that would be the easy bit. But Microsoft just don't provide patches in a useful enough manner. Even if they did, how would a particular machine decide wether or not it needed to install a particular patch? Trivial with RPM. All but impossible with NT. Not to mention the need to reboot after installing each one.
ZD (and for that matter Microsoft) just don't understand the art of systems administration. Someone who stays at work all night doing point, click, reboot, point, click, reboot several hundred times over to upgrade his machines is not a good sysadmin. Someone who types a few commands then goes home at 5pm, confident in the knowledge that by 9am the next day, the systems will all have upgraded themselves - that is a good sysadmin.
Ho hum. Michael Whitmore subjecting us to his usual banal thinking in the name of filling column pixels.
Would Linux survive if Solaris was free? Of course it would. To suggest otherwise indicates a very poor understanding of what Linux is, and what it's good at.
Historically, Linux was the UNIX you could run on your PC - for free. It's ability to provide "serious computing" facilities on commodity hardware won it the hearts and minds battle a long time ago.
When I was at university we had rooms full of SPARCstations and similar kit. They opened up my eyes to what an open systems environment was capable of. Then there was X - for all it's clunkiness still based on a great architecture. The whole "it's more important to do it right than to do it quickly" philosophy which is found throughout the UNIX world - and which is still completely alien in the Windows world.
It was a revelation to me. And it came at a time when I was getting more and more frustrated with the limitations and costs of Windows 3.1 on my home PC. It crashed all the time. (Heh. We complain about NT crashing "all the time". Remember when "all the time" really was ALL the time?). You couldn't develop anything on it without spending a lot of money first. And I was a student - where would I get money?
So, when Linux hit us (in the form of Yggdrasil Linux 0.99pl13) almost every one of us CS students embraced it. Here was a free, cool, capable, stable (even then), platform that we could take home and do the same cool stuff on our home PCs that we had previously been doing on the X-tens-of-thousands-of-pounds SPARCstations. We could write C code for coursework. We could write little TCP servers and clients to our heart's content. We could write Xlib apps. And we could take them all back into university, put them on the Suns, and they would work!
It's difficult to express how significant that time was. The idea that you could run X at home now seems trivial, but back then it was a Big Thing. We're talking about students here - no money. Sure, UNIX for PCs was around in the form of things like SCO and Solaris 86, but they were expensive (VERY expensive). But Linux was free, and ran on my cheap 386sx20 with 2Mb just great.
It's no concidence, of course, that the people who discovered Linux at college back then are now graduated and starting to be in decision making positions inside companies just at the time that Linux is being taken more seriously by the commercial world.
The article's conclusion is based on some assumptions that don't seem to be right to me:
That if price is taken out of the equation, the technically better OS will "win".
That Solaris is better than Linux.
That Solaris isn't free at the moment.
That people choose Liunx purely on the basis of cost and don't care about the community aspect.
Most people would agree that the various BSDs are at least technically as good as Linux. But they are massively, hugely, enourmously less popular. So even if Solaris 86 was better than Linux, that wouldn't necessarily make a difference.
Not that Solaris 86 is better than Linux. Solaris SPARC is excellent and as robust a platform as you could hope for, but Solaris 86 I wouldn't touch with a bargepole. It simply isn't better than Linux. It has less hardware support, is less robust, has less software, and crashes more often. It is arguably more secure, in the sense that "broken" = "secure". Plus it eats resources like no other OS.
This all probably explains why people continue to choose Linux despite the fact that Solaris 86 *is* free to hobby users, as is Solaris SPARC. That's a good thing. But there's more to this issue than price.
There's the community for a start. There's the symbiosis that you get between developers and users. There's the complete lack of "us and them". There's the ever growing list of features that you can pick and choose at your own rate. There's even a healthy competition between distribution makers which is leading to improvements in installation and package support. There are thousands of applications, web pages, mailing lists, and people willing to help.
Partly, all of this is because Linux is popular. But partly, Linux is popular because of the community support. It works both ways - a nice positive feedback loop. One that just isn't there for Solaris 86.
So, nice try Michael, but try understanding what you're criticising next time.
Actually, the young British people I know are really young Scottish people, and maybe there is a distinction there regarding loyalty to the Queen. Thing is, I lived in England for four years, and in the whole time I lived there, the only person I met who expressed support for the Monarchy was a certain technical support Bob going by the nickname of Zerbey....
To be honest, the thinking among young British people isn't so much "those stiking Australians getting rid of the Queen" as "how long will we have to wait before *we* can get rid of the Queen?".
As the article points out, it's quite possible that the people who have registered the trademark have done it to protect the Linux community, rather than to exploit it. This is what happened in Austria (as the article also says).
I suppose the ideal thing would be for it to be given to Linus but some beneficient Linux-using lawyer looking after it and not causing any hassle is surely the next best thing.
Sorry, you're wrong. There's no problem in principle with lots of new TLDs being created. Indeed, new country TLDs come along every so often, and of course it is intended to create a whole new gamut of TLDs like.shop etc.
Every name server needs to know the address of a "root name server". If it doesn't know which server deals with a particular TLD, it asks a root server. That's how it works now. That's how it would work with lots more TLDs. No changes to the DNS protocols or servers needed.
Re:Are Psion moving in the wrong direction
on
New Psion Palmtop
·
· Score: 1
> My series 3 is used every day, does pretty much > everything I want it to and lasts about 3 > months on 2 AA batteries. Psion's newer > machines (the 5 and now the 7) are larger, > heavier and have comparatively short battery > lives.
The 3 is great, but you're being unfair to the '5 by comparing its battery performance to the '7's. My '5 is in daily use and goes about two months between battery changes (though heavy use of the backlight does approximately half this). The '7 on the other hand will have a battery life measured in hours. Ick.
The advantages of the '5 over the '3 are that EPOC32 is just streets ahead as an operating system. It is properly layered and extensible. It has a TCP stack. It has sensible, usable network applications (from newsreaders to IRC clients. And Hermes, a relatively new telnet program, does a great VT100 emulation).
I use my '5 with an Ericsson SH888 phone (with built in IrDA modem) to remotely maintain a number of systems by telnet. An ssh client would be wonderful, and should be relatively easy to implement.
There is no doubt that Microsoft dominates the business productivity software market. MS Word is so utterly ubiquitous that it's a suprise to find a company using anything else. This control and ownership of the application space, together with their obvious monopoly in desktop operating systems, gives them a convincing edge when it comes to the back end.
People assume that since they are using Microsoft apps, on a Microsoft operating system, it is natural and proper that the back end server should run Microsoft too - whether it be simple NT file and print, or things like SQL Server and Proxy Server. Surely it must be better to have a single supplier for all these things, rather than an rag-bag of products from different suppliers?
(Of course, in reality, a system which uses hetrogenous components with well-defined protocols operating between them is likely to be much more robust, easier to support, and more future proof. And of course if more people built such systems there would be more competition in the software industry, with all the advantages in terms of pricing and features which that would bring. But oh well. "We're a Microsoft shop.")
With the StarOffice deal, Sun is making a clever strategic move. They are betting that they can upset the applications apple-cart sufficiently to cause some re-alignment in the market. They don't have to make money from StarOffice directly; they just have to make enough of a splash with it that people reconsider their IT strategies. It will be hard for even the most died-in-the-wool Microsoft-loving manager to ignore the cost advantages of rolling out StarOffice instead of MS Office (imaging being able to tell his employees "you can copy this to use at home if you want"). And if he's going to do that, he might as well also consider looking at, say, Linux on the desktop instead of Windows. Either way, it might also make him a little more open minded about the back end.
Not that he'll necessarily choose Sun at the back end. That isn't really the point. Sun don't particularly mind if HP and IBM benefit from their strategy too. This isn't a Solaris-vs-every-other-UNIX strategy - it's a pure anti-Microsoft one. And it makes economic sense.
The bottom line is this. If the people who make the decisions can be pursuaded to see beyond Microsoft, Sun will gain.
In any shake-up of the market which reduces Microsoft's dominance, Sun are in a good position to reap the rewards. They'd rather have 40% of a UNIX-dominated market than 5% of a Microsoft-dominated one.
It's a good strategy. Giving away Star Office is a good move. In particular, giving it away to Windows users (who are not accustomed to such practices in the same way we UNIX people are) will win them a *lot* of "hearts and minds".
And the GPL? Nice though it would be, we must realise that GPLing the software wouldn't suit Sun's strategic plan for StarOffice. They need a little more control than the GPL offers. That said, I personally do trust them to engage the community and accept patches etc. Despite what has been said by some people in this discussion, Sun actually have a pretty good open source record. Consider things like OpenLook, an excellent (though now rather dated) X toolkit which they gave away in source form. They've also given away reference RPC implementations (remember, RPC is a standard Sun gave us) and NFS software (NFS too is a Sun standard). They are of course a money-grabbing corporate, but they are still "the good guys" in my opinion.
Back when I was at University (cue shimmer fade)... we had a similar lab with perhaps 50-60 SPARCstations - all SLCs, ELCs, and an IPC. Yeah, we're going back a bit, and it must be said that an SGI would beat them in graphics performance. But the whole point is - the whole time I was there, i.e. for several years, they *all* ran *all the time*. I basically lived in that lab, and there were simply *no* hardware or software problems. The machines were always available.
... except the one time someone power-cycled the IPC's colour monitor too quickly and blew its power supply...
> IRIX is a rock-solid OS, and I cannot imagine > using Linux on a production workstation at this > point
I can only imagine that the author of this piece has a very different definition of "production" to mine.
I had the misfortune of sysadmining an Irix network a few years back, and I must say I have never experienced such an unstable, unpredictable, bloated, inconsistant, swap-happy, disgusting, dreadful, CRAP operating system as Irix. There are only two operating systems I dislike more than NT; SCO and Irix.
Never before have I been told to "reinstall the operating system" on a UNIX box because of an application failure (namely that SGI's supplied named kept dying). Never before have I had filesystems become corrupt while actually in use - even SCO doesn't do that (and no, it wasn't hardware).
We had a Challenge set up as a web server that we used to call "Scroedinger's Server". I'm sure you can guess why.
As to workstation use, did you ever see such a slow window manager? This on machines with 128Mb RAM.
Of course, that was way back in Irix 5.3 days. The later versions manage to be even more bloated, and yet be even less functional.
You see, I am someone who gets paid real, live money to look after real, live, user-facing machines. "Bet your business" machines. They have been Solaris machines, AIX machines, Dynix machines, and yes, Linux machines. I sleep at night running these systems.
The author of this piece, I suspect is not in this position. His idea of a "stable" platform may be one where he can fit a complete render between crashes. If that's all he wants, fair enough - because that's about all he'll get from Irix.
When I first started reading this draft, I thought to myself, "I could help this guy redraft this in a more readable manner. It's a pity to have good ideas made inaccessible by poor writing".
This inclination quickly vanished when it became clear that good ideas were in short supply.
Up until a year ago, I was employed by an ISP. One of the major parts of my job was assessing and making IP assignments for customers. As a European ISP, we worked through RIPE and following the RIPE procedures.
There is, in principle, plenty of address space. IPv4 allows more than four billion theoretical addresses. That's plenty. The problem is that there are limits on how efficiently you can assign that space to end users. You can't realistically have 192.133.50.5 on a network in the UK and 192.133.50.6 in Australia, because it would mean having a seperate routing table entry for each individual IP address. Imagine, a routing table 8Gb in size.
So space is allocated in blocks. ISPs are allocated large blocks (typically 32x255 or 64x255 addresses at a time) and in turn assign small sub blocks to their customers. There only needs to be a small number (often one) of routing entries for the entire ISP and all its customers. Instead of having 4 billion routing entries, you have a few tens of thousands.
For those who don't know, the old "classful" system of fixed-size networks (i.e enormous, very big, or just big) is long gone. The Real Live Internet todays runs "Classless Interdomain Routing" (CIDR), which allows any number of bits in the netmask, rather than just the traditional 8, 16 or 24 which characterised classes A B and C respectively.
So when a customer with three staff members and four computers purchased a leased line, you'd assign them perhaps a/29 (that is, 29 bits in the subnet mask, allowing six hosts + broadcast + network base) or a/28. Making smaller assignments makes more efficient use of the available address space. In the "bad old days" you'd have to in practice assign a class C (253 hosts) as a minimum.
CIDR is vastly more efficient, and it's what has kept IP4 running up 'til now. For random distribution of network sizes, it's around 75% efficient (that's not a real-world figure for various reasons). The old classless system, by contrast, was only around 38% efficient. For both of these numbers you have to assume that everyone is being conciencious and using the smallest network they sensibly can.
Now, back to the draft.
One of the (several, and mutually exclusive) things he seems to be proposing is a 64-bit address space with the old 8-bit boundaries back on netmasks. This would give more space, but would be exactly as efficient as the classful addressing scheme - i.e. much less efficient than what we do now.
He seems to want to get the extra 32 bits from the netmask. This reveals thinking which is muddled beyond all hope of salvation. He quite clearly doesn't understand how IP routing works in even the most fundamental sense. You see, fundamentally, the netmask is *not* carried around with the IP address. It's a setting on your host only.
His other big idea seems to be that if we do the calculations in decimal instead of in binary, we will get different - and better, no less - answers. He does seem a little confused on this point, but of course, it's all the fault of those bad ole' IP designers for being deliberately obtuse:
"Nonetheless, it should be emphasized, that the authoritative community as a whole; i.e. Authors of IP Addressing or Internetworking Fundamentals, have shown a lack of continuity and consistency regarding the actual methods, determination and or actual explanation of the processes involved in these calculations. Where by, it has been a consistent error regarding the confusion or inability to differentiate between the calculation of the Decimal Number and the Binary Number for their individual determination. Which, to say the very least, has rendered the understanding of the most significant part of the concept of Internetworking ( that of IP Addressing ) almost an impossible undertaking."
(Indeed, an actually impossible one in his case).
He also comments at one point that the failure of the IP architects to consider extending the address range is probably the cause of the Y2K problem.
Oh well. The man's an idiot. He has exactly the understanding of IP addressing you'd expect from someone who attended (and slept through) two lectures on the subject, glanced briefly at RFC791, again at RFC1550, understands neither and thinks he's an expert. The sort of person who tells you about the font size in his.txt text/plain document. The sort of person who cites himself twice, and then cites the same RFC twice too.
Slashdot Mirror
Is here.
1. Don't choose names which relate to funcionality.
This sounds like a joke ("he's saying DON'T use helpful names? huh?") but I'm quite serious. The new machine you are now installing might indeed be destined to run the mail server. All the same, don't name it "mail" or "mail1" or anything like that.
Here's why. A machine can change its function, and a function can be carried out by more than one machine. And machines can carry out more than one function. There is no straightforward one-to-one link between names and functions - so don't try to force one.
It's quite possible that at some point this new machine won't be the mail server any more. At that point, being called "mail" would be a more likely to confuse people than help them.
It's equally possible that you might decide to run a news server on the machine - while it's still a mail server. Can you imagine the conversation?
"I need some setup information for Netscape. What's our mail server called?"
"It's called mail."
"Oh, cool. That's easy. Now, what's the news server called?"
"Uhm... also mail..."
"Oh. Well that's dumb. OK. Finally I need to know what machine our LDAP server is on."
"Uhm.. it's on 'news'".
Not impressive, I think you'll agree.
Here's what to do instead. Give the machines arbitrary names. Then put CNAMES in your DNS for the services pointing to the actual machines.
If you can do that, you can tell people "our SMTP server is called 'SMTP'" and "our news server is called 'news'" and they can keep those settings for ever - you just change what the CNAME points to. You can even make the CNAME round-robin across several actual machines for load balancing - all without the user needing to know.
This doesn't just apply to the traditional services, but also to your own applications. If you have a stock control computer which people telnet to, don't call it "stockctl". Call it "bart" and put in a CNAME pointing to it. Even if you think you'll never change anything, it's worth allowing for the possibility that you will at the start.
2. Don't choose names which relate to form.
This means, for instance, that if your new mail server is a Compaq, it's a bad idea to call it "compaq" or "compaq3" or "cpq00153533" where 153533 might be the serial number.
Why's this bad? Because this information is a) useless, b) hard to remember, and c) likely to become wrong.
If you have a hundred workstations mounting volumes off a machine called "cpq00153533" you're going to have a rough time the day you upgrade the box to "cpq00182243". (Such names are also hard to tab expand if you've set up tcsh to do that as I have.) Unless, of course you just decide to keep the old name, although it is now wrong as well as annoying.
If you've called your machines "dellXXX", apart from trying to remember that "dell159" is your mailserver and "dell195" your quake server, you're going to be in difficulty when you replace some or all of them with IBMs.
The fact is that the manufacturer, model or serial number actually tells you nothing you need to know about a system in day to day use. You might need to know about its disk configuration, contents of /etc/passwd, or available memory, but you will rarely need to remember if it's a 333Mhz or a 366Mhz - and if you do, it should be in your product inventory database (hosted on "ibm104032" of course).
So, the principles in summary:
- Don't use functional names as hostnames. Put in CNAMES for the functional names instead. You'll save yourself lots of grief in the long run.
- Don't use names describing the physical setup, as that's useless, annoying, and incorrect far too often to be relied upon anyway.
Applying these principles requires that there be an "intermediate" naming convention which deliberately does not convey information about function, and which also does not convey information about setup.I would suggest that this naming scheme should use names which are easy to type and remember rather than ones which are repetitive and formal. "srv001" through "srv999" might look nice and orderly, but in fact is much harder to remember and type than "rivers" or "cartoon characters" or "80's arcade games".
> lives; the forces of righteousness will surely
> be blasted to bits.
Katz, you send out more crap than a hand grenade in a sewage works.
I'm aware how futile it is to try to penetrate your highly effective fact repulsion field, but here's some actual real information:
- Many geeks are not religious...
- ...but many also are.
- Many religious people are not geeks...
- ...but many also are.
- There is no inherent conflict between geekiness and faith.
Indeed, many famous and prominent geeks are Christians. You might be aware (but you probably aren't) that Slashdot itself (together with many thousands of other sites) is written in a language called PERL. The geek who inveted PERL, whose name is Larry Wall, is well known as being a Christian. He isn't a in-your-face bible-thumping damnation-decreeing Christian, but hey, neither are most Christians.At the end of the day, Katz, you are in no position to understand the minds of Christians or geeks since you are clearly neither.
Then when MS-DOS v2 came along and needed to support directories, they couldn't use the slash as it would be ambiguous. So the "other" slash was used instead... the one which was already used as an escape character in UNIX. Which, to cut a long story short, is why Samba users everywhere regularly type four backslashes before their server name :)
I can easily see him asking "Are you ever going to produce a product that saves more time than it wastes?" or "When will you realize that stability is important?"
There was one famous interview where he asked a senior politician the same question thirteen times in a row until he got a straight answer. I look forward to seeing that same no-bullshit style used against Uncle Gates' carefully prepared marketing drivel.
So, given that both sender and recipient have to agree, why can't they just agree to delete the damn' thing?
If there is a demand for this (and frankly I'm not convinced) surely it would make sense just to define a "Delete-After: " email header and work with that. Why involve encryption at all?
I am sitting in the computer support office of a company which puts NT boxes on people's desks. These boxes are used for the usual suspects - Word, Excel, Powerpoint - but also for running Reflection to connect to a big old UNIX box which runs the core business application. I look after the UNIX box, which just runs and runs, which is how I have enough time to post on Slashdot.
The Windows support people around me have a hard time. They are constantly running around installing and upgrading software on people's PCs[1]. Either that or fixing the problems people bring on themselves by changing settings or switching off their machine while the drive is writing. 90% of the problems I have are with users changing their Reflection settings so they can't connect to the UNIX box, rather than with the UNIX box itself - I'd hardly have anything to do at all if they were given dumb terminals instead of Windows boxes to connect with.
It seems to me that in this kind of environment, NCs would make a lot of sense. No local data storage. No local configuration to be mucked about with by users. All the advantages in terms of reliability and manageability of dumb terminals, but with plenty of local processing power. So the data stays where it belongs - in the center - but the processing is with the user.
Just think what a difference it would make in here. Software upgrades? Just do it once. Users screw up their configuration? Well, they can't.
Not that it is ever likely to happen. Oh well. Life as usual.
[1] Yes, I know with NT you can go a long way towards centralised applications and protecting the workstation from the actions of the local user. In fact, I believe that this has been done on this network as completely as it is possible to do so. And users still screw up their PCs. And techies still have to go around to do upgrades - to make sure those precious DLLs are in C:/WINNT or whatever.
The Windows interface might be great on a desktop (though personally I hate it) but it is way to complex for a PDA. Compare it to the simple, effective, consistant EPOC to see what I mean.
Take a bloated, mutated, and counter-intuitive desktop operating system. Remove most of its functionality. Squeeze it into a smaller display than it was ever intended for. It's fun for a while, but ultimately unrewarding.
PalmOS Desgined from the ground up to work in a small display. You can pull it out of your pocket and get to the data in an isntant. No fuss, no mess. You wouldn't want to enter serious amounts of text in it, but it's a very practical solution for the needs of the average business person. It's massively popular.
Epoc32 A clean and elegently designed system from a company who've been building PDAs longer than anyone. Designed from day one for mobile use - but aimed at people who really need a keyboard, either because they need to process documents on the run, or because they are geeks and like being able to telnet into their linux boxes from half way up a mountain - which is when the excellent cellphone integration comes in handy. Also let's companies easily develop custom apps in OPL for, say, insurance salesmen to use on the move. Massively popular in it's niche market.
There's a pattern here, I think:
Designed to a PDA environment - people love it.
Designed from a desktop environment - complete flop.
When someone types "pez" into a search engine, what is it they are looking for?
The answer is, clearly I hope, the second. The problem is that corporates don't see the world this way. The thought that people might search for their name, but go to their multi-million dollar, often content-void site but instead go to the place where the information they actually want may be found, leaves them dizzy.
Meta-tags are a mechanism which allows the author of a page to specify some keywords which describe the content. It works reasonably well. It is not intended, and does not function as a mechanism for identifying the official site relating to a trademark.
As a non-lawyer, and in an utterly non-advice-giving manner, I'd suggest that attempting to use trademark law to prevent other people saying "my site talks about Pez too!" is probably asking the courts to go too far. But then I'd have said suing mcdonalds when you spill coffee on yourself was unlikely to succeed either.
If the law sides with the corporates on this, then it can only be because they don't understand what search engines are for (You want information, not marketing). And they will have made the wrong decision.
It can be very hard to respect the law sometimes, so I've given up on doing so for the time being...
Where's the advice?
First of all, WTF is an "unregistered trademark?". How can you know if you're violating an unregistered trademark or not? Maybe someone could clear up what they mean by this - but it sounds like nonsense.
Secondly, the point of trademark law is to stop company B passing itself off as company A by using the same or a similar name. So if your company has spent the last twenty years making "Miracle Widgets" and has gained a great reputation, you would be entitled to take action against a new company called "Miracles Widgets" who might be trying to pass themselves off to customers as you. On the other hand, your reputation as a widget maker would be irrelevent to, say, advertising, so "Miracle Advertising Consultancy" would probably not be considered to be passing off.
If I create a "Widget World" web site for discussion and news on the widget industry, I am perfectly at liberty to use the name of Miracle Widgets, even though it's a trademark, as long as there's no way someone looking at the site would think that my site was actually run by Miracle Widgets. It's this right that allows news sites, fan sites, etc, etc to exist. Just think how long ZDnet would last if they weren't allowed to use any trademarked names.
So the question is this; does trademark law in the US, either in statute or precedent, go beyond this simple protection of a business's name from any unscrupulous competitors who might try to deceive the public?
If it does, it's broken.
I fully appreciate that the law probably is much more complex than that. But it shouldn't be.
Let's assume for the moment that the law upholds the above principles, but doesn't go any further. (Laws that don't go far enough are a bad thing; laws that go too far are generally worse.) Let's look at the meta tags issue.
If I have a site which regularly discusses Miracle Widgets, then it would be entirely appropriate to use "Miracle" in the meta tags - the site would be a source of information about Miracle Widgets. As long as I don't actually try to sell people widgets, I'm fine.
Note that this doesn't mean I can't make money from the site. It doesn't matter if it's commercial or non-commercial. I'm allowed to discuss Miracle Widgets on the site in good or bad terms, as often as I like, as long as I never attempt to make them think I *am* Miracle Widgets. It's up to a court to decide whether I am engaging in legitimate discussion, or whether I'm trying to deceive the public. Simply using the word "Miracle" does not place me in breach of trademark.
Having a site which discusses Pez Candy is not in breach of their trademark unless I try to pass myself of as Pez Candy. I can set up a trading site for Pez Candy. I can write good or bad things about it. I can make money out of doing so. As long as I don't infringe their trademark (which means a lot more than just using the word) there's nothing they can do about it.
Does the law work this way? If not, why not? Doesn't it seem remarkably... fair?
"If you can't explain what it does in one sentence, it will fail."
I have read the linked article and looked through the epost.ca site, and I can't honestly say I'm much the wiser. The site hits you with page after page of "EPO will change the way Canadians communicate" but doesn't seem too keen to be tied down to exactly why that would be so.
For example, click on the "What does EPO do?" link. Sounds like a helpful one, yes? "EPO puts all your mail in one place" it tells you. "No more going from Web site to Web site to pay bills, view account details and get information. Now it comes to you in your private, secure, Electronic Post Office Box". That certainly makes it much clearer, doesn't it?
Then there's the promising-sounding "Frequently Asked Questions" link. You might expect this to answer the questions people seem to be asking here on Slashdot; questions like "Will I still get paper mail or will it be scanned in?" But instead the FAQ link gives you a huge and utterly uninteresting page full of reassurances about Y2K compliance. And only Y2K compliance; "our code-remediation strategy includes a logic-based solution known as windowing for interfaces to external partners." It will no doubt reassure Canadian taxpayers that this service, being launched as it is in late 1999, considers Y2K compliance to be "achievable". Whoopie-doo.
Anyway, here's the Andrew Crawford Patent No-Crap Distilled and Filtered Guide to the Canadian Electronic Post Office. FX: Fanfare
So what's new here? Nothing really. It's a proprietary secure email system. The key to its success will be whether they get enough companies signed up to use it. Even then, they've failed to show any overwhelming reason why it's better than the existing email infrastructure.
I think they're making a mistake hyping it as a replacement for paper mail when it's really not. Such merit as it has consists in making life a little easier for people who already use the Internet to check their balances etc and pay their bills by centralising everything. There aren't a huge number of people who actually do that though - and those that there are often do so because they appreciate the interactive features of being connected directly to the company's database. (Want to transfer a balance from one account to another? Or see more details of this transaction? Just click.) This kind of feature will be absent from EPO.
But I don't think it will succeed, because the people marketing it don't seem to have any idea what it actually does.
> Riiight, and if you had 200 or 2000 servers,
> the rpm solution would be *sooo* good.
The RPM solution would be ideal for 2000 servers. Even if you did have to do them all manually (which you wouldn't unless you were clueless), it would still be faster to issue a wildcard rpm command and walk away than to install SP5 and reboot.
Any half competent Linux systems administrator could trivially set up an automated system to roll out patches to any number of connected servers. There are lots of ways you could do it, using cron and either scp, ftp or nfs depending
on how paranoid you are.
Sure, you'd have to install a script on each machine and set up a cron job - once. From then on you'd just place the relevent rpms in a nominated directory and go home. At 3am, or whenever, each of your systems has a look in that directory to see if there's anything there which updates its installed software, and upgrades using it if so.
Can you get that degree of functionality with NT?
You could install PERL and cron on an NT box and get the scripting working - that would be the easy bit. But Microsoft just don't provide patches in a useful enough manner. Even if they did, how would a particular machine decide wether or not it needed to install a particular patch? Trivial with RPM. All but impossible with NT. Not to mention the need to reboot after installing each one.
ZD (and for that matter Microsoft) just don't understand the art of systems administration. Someone who stays at work all night doing point, click, reboot, point, click, reboot several hundred times over to upgrade his machines is not a good sysadmin. Someone who types a few commands then goes home at 5pm, confident in the knowledge that by 9am the next day, the systems will all have upgraded themselves - that is a good sysadmin.
Would Linux survive if Solaris was free? Of course it would. To suggest otherwise indicates a very poor understanding of what Linux is, and what it's good at.
Historically, Linux was the UNIX you could run on your PC - for free. It's ability to provide "serious computing" facilities on commodity hardware won it the hearts and minds battle a long time ago.
When I was at university we had rooms full of SPARCstations and similar kit. They opened up my eyes to what an open systems environment was capable of. Then there was X - for all it's clunkiness still based on a great architecture. The whole "it's more important to do it right than to do it quickly" philosophy which is found throughout the UNIX world - and which is still completely alien in the Windows world.
It was a revelation to me. And it came at a time when I was getting more and more frustrated with the limitations and costs of Windows 3.1 on my home PC. It crashed all the time. (Heh. We complain about NT crashing "all the time". Remember when "all the time" really was ALL the time?). You couldn't develop anything on it without spending a lot of money first. And I was a student - where would I get money?
So, when Linux hit us (in the form of Yggdrasil Linux 0.99pl13) almost every one of us CS students embraced it. Here was a free, cool, capable, stable (even then), platform that we could take home and do the same cool stuff on our home PCs that we had previously been doing on the X-tens-of-thousands-of-pounds SPARCstations. We could write C code for coursework. We could write little TCP servers and clients to our heart's content. We could write Xlib apps. And we could take them all back into university, put them on the Suns, and they would work!
It's difficult to express how significant that time was. The idea that you could run X at home now seems trivial, but back then it was a Big Thing. We're talking about students here - no money. Sure, UNIX for PCs was around in the form of things like SCO and Solaris 86, but they were expensive (VERY expensive). But Linux was free, and ran on my cheap 386sx20 with 2Mb just great.
It's no concidence, of course, that the people who discovered Linux at college back then are now graduated and starting to be in decision making positions inside companies just at the time that Linux is being taken more seriously by the commercial world.
The article's conclusion is based on some assumptions that don't seem to be right to me:
Most people would agree that the various BSDs are at least technically as good as Linux. But they are massively, hugely, enourmously less popular. So even if Solaris 86 was better than Linux, that wouldn't necessarily make a difference.
Not that Solaris 86 is better than Linux. Solaris SPARC is excellent and as robust a platform as you could hope for, but Solaris 86 I wouldn't touch with a bargepole. It simply isn't better than Linux. It has less hardware support, is less robust, has less software, and crashes more often. It is arguably more secure, in the sense that "broken" = "secure". Plus it eats resources like no other OS.
This all probably explains why people continue to choose Linux despite the fact that Solaris 86 *is* free to hobby users, as is Solaris SPARC. That's a good thing. But there's more to this issue than price.
There's the community for a start. There's the symbiosis that you get between developers and users. There's the complete lack of "us and them". There's the ever growing list of features that you can pick and choose at your own rate. There's even a healthy competition between distribution makers which is leading to improvements in installation and package support. There are thousands of applications, web pages, mailing lists, and people willing to help.
Partly, all of this is because Linux is popular. But partly, Linux is popular because of the community support. It works both ways - a nice positive feedback loop. One that just isn't there for Solaris 86.
So, nice try Michael, but try understanding what you're criticising next time.
Actually, the young British people I know are really young Scottish people, and maybe there is a distinction there regarding loyalty to the Queen. Thing is, I lived in England for four years, and in the whole time I lived there, the only person I met who expressed support for the Monarchy was a certain technical support Bob going by the nickname of Zerbey....
To be honest, the thinking among young British people isn't so much "those stiking Australians getting rid of the Queen" as "how long will we have to wait before *we* can get rid of the Queen?".
As the article points out, it's quite possible that the people who have registered the trademark have done it to protect the Linux community, rather than to exploit it. This is what happened in Austria (as the article also says).
I suppose the ideal thing would be for it to be given to Linus but some beneficient Linux-using lawyer looking after it and not causing any hassle is surely the next best thing.
Sorry, you're wrong. There's no problem in principle with lots of new TLDs being created. Indeed, new country TLDs come along every so often, and of course it is intended to create a whole new gamut of TLDs like .shop etc.
Every name server needs to know the address of a "root name server". If it doesn't know which server deals with a particular TLD, it asks a root server. That's how it works now. That's how it would work with lots more TLDs. No changes to the DNS protocols or servers needed.
> My series 3 is used every day, does pretty much
> everything I want it to and lasts about 3
> months on 2 AA batteries. Psion's newer
> machines (the 5 and now the 7) are larger,
> heavier and have comparatively short battery
> lives.
The 3 is great, but you're being unfair to the '5 by comparing its battery performance to the '7's. My '5 is in daily use and goes about two months between battery changes (though heavy use of the backlight does approximately half this). The '7 on the other hand will have a battery life measured in hours. Ick.
The advantages of the '5 over the '3 are that EPOC32 is just streets ahead as an operating system. It is properly layered and extensible. It has a TCP stack. It has sensible, usable network applications (from newsreaders to IRC clients. And Hermes, a relatively new telnet program, does a great VT100 emulation).
I use my '5 with an Ericsson SH888 phone (with built in IrDA modem) to remotely maintain a number of systems by telnet. An ssh client would be wonderful, and should be relatively easy to implement.
There is no doubt that Microsoft dominates the business productivity software market. MS Word is so utterly ubiquitous that it's a suprise to find a company using anything else. This control and ownership of the application space, together with their obvious monopoly in desktop operating systems, gives them a convincing edge when it comes to the back end.
People assume that since they are using Microsoft apps, on a Microsoft operating system, it is natural and proper that the back end server should run Microsoft too - whether it be simple NT file and print, or things like SQL Server and Proxy Server. Surely it must be better to have a single supplier for all these things, rather than an rag-bag of products from different suppliers?
(Of course, in reality, a system which uses hetrogenous components with well-defined protocols operating between them is likely to be much more robust, easier to support, and more future proof. And of course if more people built such systems there would be more competition in the software industry, with all the advantages in terms of pricing and features which that would bring. But oh well. "We're a Microsoft shop.")
With the StarOffice deal, Sun is making a clever strategic move. They are betting that they can upset the applications apple-cart sufficiently to cause some re-alignment in the market. They don't have to make money from StarOffice directly; they just have to make enough of a splash with it that people reconsider their IT strategies. It will be hard for even the most died-in-the-wool Microsoft-loving manager to ignore the cost advantages of rolling out StarOffice instead of MS Office (imaging being able to tell his employees "you can copy this to use at home if you want"). And if he's going to do that, he might as well also consider looking at, say, Linux on the desktop instead of Windows. Either way, it might also make him a little more open minded about the back end.
Not that he'll necessarily choose Sun at the back end. That isn't really the point. Sun don't particularly mind if HP and IBM benefit from their strategy too. This isn't a Solaris-vs-every-other-UNIX strategy - it's a pure anti-Microsoft one. And it makes economic sense.
The bottom line is this. If the people who make the decisions can be pursuaded to see beyond Microsoft, Sun will gain.
In any shake-up of the market which reduces Microsoft's dominance, Sun are in a good position to reap the rewards. They'd rather have 40% of a UNIX-dominated market than 5% of a Microsoft-dominated one.
It's a good strategy. Giving away Star Office is a good move. In particular, giving it away to Windows users (who are not accustomed to such practices in the same way we UNIX people are) will win them a *lot* of "hearts and minds".
And the GPL? Nice though it would be, we must realise that GPLing the software wouldn't suit Sun's strategic plan for StarOffice. They need a little more control than the GPL offers. That said, I personally do trust them to engage the community and accept patches etc. Despite what has been said by some people in this discussion, Sun actually have a pretty good open source record. Consider things like OpenLook, an excellent (though now rather dated) X toolkit which they gave away in source form. They've also given away reference RPC implementations (remember, RPC is a standard Sun gave us) and NFS software (NFS too is a Sun standard). They are of course a money-grabbing corporate, but they are still "the good guys" in my opinion.
60 machines? 2/3 not working?
Back when I was at University (cue shimmer fade)... we had a similar lab with perhaps 50-60 SPARCstations - all SLCs, ELCs, and an IPC. Yeah, we're going back a bit, and it must be said that an SGI would beat them in graphics performance. But the whole point is - the whole time I was there, i.e. for several years, they *all* ran *all the time*. I basically lived in that lab, and there were simply *no* hardware or software problems. The machines were always available.
... except the one time someone power-cycled the IPC's colour monitor too quickly and blew its power supply...
> IRIX is a rock-solid OS, and I cannot imagine
> using Linux on a production workstation at this
> point
I can only imagine that the author of this piece has a very different definition of "production" to mine.
I had the misfortune of sysadmining an Irix network a few years back, and I must say I have never experienced such an unstable, unpredictable, bloated, inconsistant, swap-happy, disgusting, dreadful, CRAP operating system as Irix. There are only two operating systems I dislike more than NT; SCO and Irix.
Never before have I been told to "reinstall the operating system" on a UNIX box because of an application failure (namely that SGI's supplied named kept dying). Never before have I had filesystems become corrupt while actually in use - even SCO doesn't do that (and no, it wasn't hardware).
We had a Challenge set up as a web server that we used to call "Scroedinger's Server". I'm sure you can guess why.
As to workstation use, did you ever see such a slow window manager? This on machines with 128Mb RAM.
Of course, that was way back in Irix 5.3 days. The later versions manage to be even more bloated, and yet be even less functional.
You see, I am someone who gets paid real, live money to look after real, live, user-facing machines. "Bet your business" machines. They have been Solaris machines, AIX machines, Dynix machines, and yes, Linux machines. I sleep at night running these systems.
The author of this piece, I suspect is not in this position. His idea of a "stable" platform may be one where he can fit a complete render between crashes. If that's all he wants, fair enough - because that's about all he'll get from Irix.
Hemos, look what you've done! You've Slashdotted Wired!
There's something deeply significant about that, I think.
When I first started reading this draft, I thought to myself, "I could help this guy redraft this in a more readable manner. It's a pity to have good ideas made inaccessible by poor writing".
/29 (that is, 29 bits in the subnet mask, allowing six hosts + broadcast + network base) or a /28. Making smaller assignments makes more efficient use of the available address space. In the "bad old days" you'd have to in practice assign a class C (253 hosts) as a minimum.
.txt text/plain document. The sort of person who cites himself twice, and then cites the same RFC twice too.
This inclination quickly vanished when it became clear that good ideas were in short supply.
Up until a year ago, I was employed by an ISP. One of the major parts of my job was assessing and making IP assignments for customers. As a European ISP, we worked through RIPE and following the RIPE procedures.
There is, in principle, plenty of address space. IPv4 allows more than four billion theoretical addresses. That's plenty. The problem is that there are limits on how efficiently you can assign that space to end users. You can't realistically have 192.133.50.5 on a network in the UK and 192.133.50.6 in Australia, because it would mean having a seperate routing table entry for each individual IP address. Imagine, a routing table 8Gb in size.
So space is allocated in blocks. ISPs are allocated large blocks (typically 32x255 or 64x255 addresses at a time) and in turn assign small sub blocks to their customers. There only needs to be a small number (often one) of routing entries for the entire ISP and all its customers. Instead of having 4 billion routing entries, you have a few tens of thousands.
For those who don't know, the old "classful" system of fixed-size networks (i.e enormous, very big, or just big) is long gone. The Real Live Internet todays runs "Classless Interdomain Routing" (CIDR), which allows any number of bits in the netmask, rather than just the traditional 8, 16 or 24 which characterised classes A B and C respectively.
So when a customer with three staff members and four computers purchased a leased line, you'd assign them perhaps a
CIDR is vastly more efficient, and it's what has kept IP4 running up 'til now. For random distribution of network sizes, it's around 75% efficient (that's not a real-world figure for various reasons). The old classless system, by contrast, was only around 38% efficient. For both of these numbers you have to assume that everyone is being conciencious and using the smallest network they sensibly can.
Now, back to the draft.
One of the (several, and mutually exclusive) things he seems to be proposing is a 64-bit address space with the old 8-bit boundaries back on netmasks. This would give more space, but would be exactly as efficient as the classful addressing scheme - i.e. much less efficient than what we do now.
He seems to want to get the extra 32 bits from the netmask. This reveals thinking which is muddled beyond all hope of salvation. He quite clearly doesn't understand how IP routing works in even the most fundamental sense. You see, fundamentally, the netmask is *not* carried around with the IP address. It's a setting on your host only.
His other big idea seems to be that if we do the calculations in decimal instead of in binary, we will get different - and better, no less - answers. He does seem a little confused on this point, but of course, it's all the fault of those bad ole' IP designers for being deliberately obtuse:
"Nonetheless, it should be emphasized, that the authoritative community as a whole; i.e. Authors of IP Addressing or Internetworking Fundamentals, have shown a lack of continuity and consistency regarding the actual methods, determination and or actual explanation of the processes involved in these calculations. Where by, it has been a consistent error regarding the confusion or inability to differentiate between the calculation of the Decimal Number and the Binary Number for their individual determination. Which, to say the very least, has rendered the understanding of the most significant part of the concept of Internetworking ( that of IP Addressing ) almost an impossible undertaking."
(Indeed, an actually impossible one in his case).
He also comments at one point that the failure of the IP architects to consider extending the address range is probably the cause of the Y2K problem.
Oh well. The man's an idiot. He has exactly the understanding of IP addressing you'd expect from someone who attended (and slept through) two lectures on the subject, glanced briefly at RFC791, again at RFC1550, understands neither and thinks he's an expert. The sort of person who tells you about the font size in his
In short, an idiot. Ignore him.