"See, the job consists of money (and benefits) in exchange for services."
No, sir, it isn't.
You said it: the *job*... It's a job, not a services contract. You are an employee, not a services company. So the proper sentence, as it has always been on a employer/employee relationship, is: "see, the job consists of money (and benefits) in exchange of *labour*". So, if the employer wants your labour, it must pay for it and no payment means no labour.
Offering services and products (to third parties also known as "clients") is the bussiness of your employing company; your bussiness is offering labour so your company can build up services (or products). Your contracting company is not at any rate your client; that's not the relationship built up by means of a job contract. It's astounding how many americans can forget about such obvious facts.
"Document flux management is great, but only if you reverse the polarity of the protocol suite and arfle barfle gloop."
Yeah, well, mock all you want, but the truth is you can do quite complex and useful things with it, and currently the Exchange environment and Lotus are the only kids in the block about this (not that I'm glad with such situation).
"Um, doesn't everyone do this?"
Nope. Probably it is not "notizing" the word I was looking for (sorry, but I'm not English); I'm meaning what IMAP IDLE brings to the table (but most mail clients still don't support) and Exchange seems to have from day zero.
"than "pops up an irritating focus-stealing dialog box"?"
You seem to forget that there's no need for pop ups or ringing bells but, anyway, pushing mail advertising instead of pulling means quite a lot of load avoided on servers.
Surely you are not one of those that thinks that can emulate Exchange functionality just with Postfix and Courier IMAP, do you?
"Little bit of playing the Devil's advocate here..."
Quite badly, I must add.
"but can you name me another enterprise solution that lets you send and receive emails, delegate access to mailboxes (R, R/W), share calendars and delegate access to calendars with reasonable granularity?"
Basically... everyone?
You should have asked about the Exchange's really making difference features like complex document flux management, seemless integration with desktop office suite or instantly notizing new message arrival, but ACLs and shared mailboxes? That's so 90's...
"just providing an easy to install package just as they do for Windows"
I always find awesome that kind of stupidness and how it can be so prevalent among windows zealots.
What is the "multiplatformness" of Windows? Zero, nada. You can seemlessly install binary packages designed for Windows on Windows... because, heck, it's Windows! Installing Debian-designed packages on Debian is even easier than installing Windows-designed packages on Windows. On the other hand, installing Debian-designed packages on Windows is as much impossible as installing Windows-based packages on Debian (and even then, on Debian you have Wine).
Why people rise so utterly different expectations between Windows and any given Linux distribution is absolutly beyond me.
"It's perfectly possible that the recipient refuses delivery"
Yes, of course.
But the problem is that: 1) The recipient is *NOT* recieving the delivery to begin with, but someone else. "Hey, Mike, did you read my e-mail? No, I didn't recieve an email from you". 2) The recipient is *NOT* refusing my delivery, someone else is doing it on his behalf.
Again, were it be snail mail, it is not as if the recipient rejects the delivery but as if the chief postal officer from Wellington, Alabama said: -So this for John Doe, Wellington, Alabama? But it comes from Dunkerk, North Carolina, *I* won't accept mail from Dunkerk, North Carolina. -But John Doe is expecting this letter; won't you pass it to him so *he* is the one that accepts or rejects it? -No, I won't. You may phone him instead.
"The point is, you cant reasonable expect your letter to be delivered."
I think this resumes your whole point. And I'd better won't tell what I think about the sensibleness of your point.
"Microsoft knows this; it's what prevents people from leaving Windows."
But Microsoft is a 'de facto' monopoly. Of course it neither needs nor wants choices. What for?
But then, on an already diverse market, like it's the case for Linux, specially if you are in front for a head, as it's the case for Red Hat, you truly want to seem like you interoperate and then fail to do so in subtle manners (Microsoft knows that too and so it proves when trying to go into a new market): your apparent cooperation makes easy for the users from your competitors to migrate to your solution; your subtle incompatibilities retain those already in the net (have you seen those nets that have an ample entry but once you are in, the exit way is just a tiny hole?) so (hopefully) you grow your userbase at a exponential rate.
"Victor thinks he's so important that he can demand people not extend the courtesy of saying thank you in exactly the way he wants it"
Viktor thinks nothing.
It has been the norm for ages not to waste both time and bandwith with a "just to say thank you" response that benefits to no one (the same goes with the plain "me too" message) and so he says on his signature. True, I think it's quite pretentious (and against another known-for-ages Internet tradition) to have such a long signature specially when just a link to the old (but still maintained) "How to ask questions the smart way" or the RFC 1855 would have been enough but I'm sure he would be glad with an answer *to the list* recouping the question, the failed attempts and the working solution (or lack of it) so it can be easily spoted on the archives or even making its way to the FAQ.
Maybe it's rude but it certainly it's common sense too.
"You misunderstand the term "reliable" as it applies to networking."
You misunderstand in that you think we are talking about networking.
Not.
We are talking about the electronic mail service. And Venema is quite rigth about saying that today the electronic mail service is less reliable than in 1998.
"So, the key is to block at the SMTP level, which guarantees that the real sending server gets an error message."
So what? 1) My [Big ISP] is not going to tell me some e-mail has been rejected 550 because [whatever]. It might even put it on/dev/null. 2) Even if my [Big ISP] returns me its SMTP chat regarding something about inverse resolution jabba-dabba I won't understand it unless I'm considerably knowledgeable about the SMTP. Good luck trying to get a working solution from the [Big ISP] helpdesk service....Oh, but it happens *I* am knowledgeable about the SMTP. So indeed I can manage my own server. 3) But then, I "just" have to make an international phone call in the middle of the night to try to talk to the f* postmaster that decided that I'm a spammer because my IP address belonged some years ago to my provider's residential DHCP pool just to learn that... 3.1) Is their [another Big ISP] policy not to accept mail from my IP and there's nothing they can do or... 3.2) They are using [spamhouse du jour] and they are very glad using it since it in fact reduces there spam volume, the hell with whatever legit mail they are thrasing out unless hard pressed by the high C*Os, which is not the case.
The fact is that if you were talking about snail mail instead of email you would say "the heck with your damn lame excuses regarding international post agencies, delayed deliveries due to revolution at Toofarynstan or internal comdex regurgitation over the ultraviolet scam filter in Dunkerk: I put the letter on the postal box and it reliably ends up in the hands of its intended receptor or it doesn't". That's the only working meaning for reliability.
"As long as YOUR email admin handles error messages in any sane way, you'll get a phone number to call and talk to the guy who set up the system that rejected your email."
Well, I hope you will accept my reverted-payment phone call from Spain... in Spanish then.
"I note that Debian Etch is listed as planning to become LSB"
Well, AFAIK is mostly compliant if not completly compliant but for the paper. But this compliancy is basically of the kind of POSIX compliance on Windows NT: good to put it on a brochure and almost nothing else. Installing a LSB-compliant package on Linux means basically forget about the whole distribution (since it'll be a RPM package that won't integrate on the standard package database) or lose both compliancy and working ability since alienize a RPM will almost surely fail in subtle manners. It's as simply as that if I, as a user and sysadmin, wanted to install RPMs, I'd be using a RPM-base Linux distribution.
And then, the only packages I've seen that LSB compliancy made sense were privative-licensed and binary-only distributed, so no amount of LSB-compliancy would make me happy to use them.
"The idea is that it will no longer matter what distro you use"
Almost true but then, if it makes no difference why should I use any other? That's why Red Hat is the strongest pusher of the LSB among distributions: they hope that if they can convince enough people that indeed it makes no difference their dominant position and the network effect will sweep out rivals eventually. Then it won't be that it doesn't matter what distribution you use but that there will be just one distribution to choose from.
"Yet none of this stops Oracle RAC from installing on Debian or Ubuntu"
True. Yet no ammount of LSB stops Oracle to only certify this or that platform (like RHEL 4u2 or Ubuntu Strange Scarab, or SUSE 10 or whatever) instead of, say, LSB 2.0.
So, the LSB is mainly aimed at attracting privative software like Oracle to Linux (who else need guaranteed ABI compatibility when you can recompile?), no wonder so many distributions don't care so much (especially when the "middle ground" that it's the basis of the standard looks so much like "whatever is shipped on current RHEL"); but then, privative software vendors feel they need much more confidence in order to certify to a platform than a "of a kind" standard, so they are not strongly pushing for it either.
End result? Well, it's been -how many? six years? and LSB it's only known to a bunch of freaks.
"you don't have to worry about things like slammer or code red on Xandros."
I didn't have to worry about slammer on Windows, either back when I was sysadmining Microsoft systems (I'm not one of those that leave a SQL server wide open to the Internet, neither on Windows nor Linux) and, while code red was indeed and issue on Windows, so was Ramen on Red Hat (I indeed show Ramen-infected boxes back in the day due to sloppy practices just as I saw slammer or code red -I already stated my point: if Linux is a "minor" system in your shop and it is opened to the Internet, as I expect a mail server to be, it will be pwned).
"If you have a guy that really knows his way around Linux CLI,you don't need it."
The point is that even with the Linux guru in place, there is no good solution for groupware that can compete against Exchange functionally wise; not at least one soundedly engineered.
"Unfortunately a lot of companies,especially SMBs,have some guy that "kinda sorta" knows Winserver [...] and when it comes to securing a running server or enforcing good security policies are sorely lacking."
And that's the kind of guy that is most able to wreak havoc with a Linux server: Linux expects more than Windows from the chair side (it can offer more to that expert, but I don't think that's the point in case).
"the Xandros wizards make it really easy to add and activate a new server role when needed."
And again to square one. That's trying to fight Windows on its own grounds. SMB offers no less easy wizards to activate the box that *seem* to do the job. That, and the fact of Windows being Windows makes sure to win that battle.
"So in those cases Xandros gives them an easy way to switch a server to Linux [...] many an SMB and there is a great majority of users that simply don't need Windows,same with the servers."
That I will admit (while in true, quite a lot SMBs are tied to Windows, not because the OS by itself, but because those Visual Basic niche applications they depend upon), but I don't see it being the point: that they don't need windows, doesn't mean they want or need to go away from Windows.
"Why risk a virus or malware infection exposing your customer's data and your business to unnecessary risk"
But then, as I already stated, you are not talking about Windows server-side, but client-side: you won't get out the risk of malware by moving your servers, but by moving your servers *and* your clients.
Anyway, good luck to Xandros and any other initiative that make people more aware that there are other ways to professional SMB IT.
"If you are stupid enough to have sex in public and get photographed doing it, then you absolutely deserve any and all negative consequences you get."
Just remember this if you ever need help from police. If you are stupid enough to walk on the street you deserve whatever will happen (robbery, assassination...). If you are stupid enough not to protect your houme like a bank you diserve somebody "cleaning" it inside out. If you are stupid enough to drive your car, you diserve somebody crashing at you. Etc.
"Behave well, and you have nothing to fear..."
That's one of the stupidest things I read for ages.
"The context here is 17-year-olds holding up a beer can and posing for the camera. There is a difference between not drinking and not drinking under-age: only one is illegal."
But there some more context too.
The context is that on the USA it is considered that a 17 year old boy is not mature enough to drink responsibly, thus he is banned to do it (on the other hand, wtf? He is mature enough to drive over one tonn of steel 60mph, he can be held responsible enough to be killed because of his actions in some states, but still he's not considered mature enough to have a beer or cast a vote??? but I'm disgressing).
The point is that we are talking about high school, a place were people goes to enhance his knowledge, culture and maturity and because of a mild sign of lack of maturity he is banned from the very site this could be corrected? That's insane, not to talk about the deep effect this underthought decision from somebody that probably just had better luck (not that he didn't drink if even a beer when minor, but he is just not online) will probably have for his whole life.
"No viruses,spyware,and a lot harder to hack sounds like vastly superior to me."
What do you mean? I do use exclusively Linux from quite a lot of years and my inbox is still full of viruses and spyware. The fact that they don't affect me doesn't mean they are not coming in; and since you talked about a "windows shop", I'll bet clients are Windows-based, and being so, you cannot go without antivirus and antispyware, both server and client-side, no matter if you are using Exchange or Scalix or whatever.
And about "a lot harder to hack", that I'd have to see with my own eyes. It's quite a lot of years that Bellovin wisely said that the thoughest platform is the one you are most experienced with, and on a "windows shop" that means... Windows.
"And if you need something that just works out of the box with no fussing or CLI,then Xandros is the way to go."
And Windows is much better if that's your consideration. Not only that, but it's Windows the one that stablish the mark regarding what's "not fussing or CLI"... specially on a "windows shop".
"It plays nice with AD, it plays nice with login scripts,and the desktop(Xandros Business) even has a "Behave like Windows" button"
Not better than native windows, and windows behave like Windows without the need of any button.
"If you need a drop in replacement for Winserver+Exchange"
And, again, that's the very failure of their bussiness case: nobody needs a "Winserver+Exchange" replacement, when they can get "the original" almost for peanuts (locally-wise). And, hey!, you'll never get fired by choosing Microsoft (specially in an already "windows shop").
"But everyone looks to be bumping heads. If someone in the community would just use Postfix, Cyrus or Dovecot and other open source technologies instead of writing their own, maybe there would be a decent groupware solution for linux."
You surely are not doing your homework. Kolab has its own share of defects, but reinventing the wheel is certainly not one of them using OpenLDAP, Postfix, Cyrus IMAP, Apache, SASL and OpenSSL.
"freedom 1 guarentees *me* that I can study *your* changes when I run *your* code on my computer, or my phone, or my dvr or my tivo, or whatever. If I get a *modified* copy of it from your server in binary format to run on my device I want the freedom to get the code as well."
That's quite questionable.
On one hand, if I get from your server, say, a Java applet, I think that would be considered redistribution even by the "standard" GPL, so you should provide me the applet's source code. Would that mean that you should provide me whatever code for your backend server, say the code for the servlets? Probably you would agree that the server side code is not needed to be distributed in this case. By the way, that's exactly how Red Hat understands it when they provide the source code for the RHN client but won't publish their server solution (RHN satellite notwithstanding).
On the other hand, if we are talking about "pure" script output, which seems to be the case you are referring to, what does indeed run on the client computer? The modified server? No, I say that's not what runs on the client machine. All that runs on the client machine is a bunch of human readeable HTML and Javascript code -and you already have the source code for this; just ask your browser to show the source code for the current page. And what about the server-side code that produced the output you recieved? No sir, that code never run on a client, only on my server and, obviously, code running on *my* server and only on *my* server can't be considered to be distributed, right?
I'm not trying to make a point about which is the "proper" way to go or if the AGPL is more "on the Stallman way" than the GPLv3 or not, but that certainly the server-side code for a SaaS environment is quite a different beast than a "typical" binary regarding distribution and its implications.
"Basically, there are a class of changes you can't make: ones that remove a link to your source tarball."
You are wrong. You can indeed change or remove that link *provided* you produced your own alternate means for the user to remotely download the sources too.
"how up to date does the source you offer have to be?"
There's only one kind of "currency" regarding that kind of cases and it's "there's no currency". On the standard GPL you must provide the source that made up to the binaries you distributed; on the AGPL it's just the same: which sources? heck, the ones needed to build the application I interact with.
"If so, then the only way to handle that is pretty much be offering dynamic tarballs of your production code - being very, very careful to strip out your config files"
That wouldn't be a license problem: "do you want to use this code? These are the constraints that I, as the coder, want to exercise, take it or leave it". On the other hand, it is not a technical problem either. It is you the one that talk about using vim to edit a production-live environment; it is *you* the technical problem and liability, not the license. In order to provide the source code to match your production environment, you just need to mildly adapt your code promotion procedures so your ready-to-production codebase is just copied to an end-user reacheable environment at the same time it moves into production.
I haven't read the AGPL except for the paragraphs found in this thread, since I haven't find a case of me using software under such license but, to me it seems it honors just the same phylosophy that moved GPL from version 2 to 3. The tivoization case was found by Stallman to be so against GPL's phylosophy as to adapt it; AGPL seems to target exactly the same kind of problem only on a different environment (the ASPs).
"What most irks me is that..."
Is that it irks you, nothing more, nothing less. You are in exactly the same case than the BSD vs GPL discussions: one side will state that they prefer what BSD offers, and the other will find the GPL "ideal" to be highly preferable. Well, you find that having to offer the sources for an application you happen to allow by remote X is not the way you want it; others find they don't want to offer their valuable modifications to a codebase just because they happen to distribute binaries of the modified result.
On my humble opinion, I think that *if* you accept the GPL because of the underlying ideal, you should accept both GPLv3 and/or AGPL as a natural evolution of the ideal that created the GPL on first place.
"I won't have an Outlook replacement until I can create a weekly MWF recurring appointment, or something of that nature, without creating a separate recurring appointment for each occurrence during the week."
WFT is a MWF recurring appointment? And don't tell me RTFM or you will be KIA ASAP.
On the other hand, in my opinion Kontact (the KDE groupware client-side solution) is vastly superior to Evolution for a PIM. Just in this case, I've been able to appoint recurrent events on Kontact for ages. I can define if the recurring event will be daily, weekly, monthly or yearly; I can tell, for instance, it'll be recurring each three weeks monday, tuesday and friday and, of course, I can make exceptions. To me, the only lacking (but weird) facility is that I can't define a protocol for a recurrent working-day event to be automatically moved if a day happens to be a holiday (say a repetition happens to be on december 25, which is a national holiday on my country; this kind of ocurrences I would want to be able to define either as an automatic exception or automatically moved to the next -or previous, working day; maybe to Dec26 or to the next monday if Dec25 happens to be friday).
"An IT Professional, is someone who is concerned about IT's relationship to the overall business, understands the difference between IT being simply a cost-center, or a profit enhancer."
Sorry sir, but no sir. What you have defined is a CTO (or depending of circumnstances, a CIO or an IT manager). We (hopefully) expect a CTO to be an IT professional but CTOs are only a subset of all IT professionals.
"That attitude is how we got the San Francisco fiasco. That dude was less concerned for the REASON for that network, than for the network itself."
Which certainly doesn't mean that guy not being an IT professional; it meant he wasn't an IT manager. And it meant that his manager, who should have been an IT manager wasn't an IT professional. *THIS* was the reason for the SF fiasco.
"There are too many pasty-fat bastards with poor social skills managing networks and scripting Excel macros"
That might be true, but I don't see were the social skills are needed for a "managing networks and scripting Excel macros" professional profile. Their managers? Sure, but not the doers.
"A professional does whatever it takes to become more effective at their job. If you work in IT, and have never done a cost analysis, never done a P&L document, or a gap analysis, than you are a mere technician"
Surely you use quite a weird definition for a professional since you think a "mere technician" not being one. My bet is that you bought an "IT management for dummies" book last week and you are just full of it. Don't worry, eventually it'll fade away.
"did you present your management with a cost/benefit analysis, supporting your request for additional hardware?"
Since he tells how bad is his management, we can infere his is not a manager. Then it is not his job to provide a cost analysis, that's the job for someone... in management. Even more: since he is not in management, he is probably not in a position to make a sensible cost analysis even if he tried. Does he know the costs involved with someone not working for an hour in a different department? Is he even *allowed* to gain knowledge of such costs?
On the other hand, he was not talking about some esotheric IT subsystem. The problem here is an obvious one: you have a system that loads up linearly at best with the number of people accesing it (one user one mailbox; two users two mailboxes, three users, etc.); the number of people has suddenly grown by 40%; you don't need a genious to understand you will need to grow your hardware by 40% too (indeed you might need a genious that will find a way to cope with the higher load without growing the supporting structure, but that's a different issue). That management won't understand that simple issue means management is idiotic. That it's probably not the case that they don't understand it but that they run out of money after the aquisition because they didn't consider associated structural costs for the migration show -again, that management is idiotic.
Slashdot Mirror
"See, the job consists of money (and benefits) in exchange for services."
No, sir, it isn't.
You said it: the *job*... It's a job, not a services contract. You are an employee, not a services company. So the proper sentence, as it has always been on a employer/employee relationship, is: "see, the job consists of money (and benefits) in exchange of *labour*". So, if the employer wants your labour, it must pay for it and no payment means no labour.
Offering services and products (to third parties also known as "clients") is the bussiness of your employing company; your bussiness is offering labour so your company can build up services (or products). Your contracting company is not at any rate your client; that's not the relationship built up by means of a job contract. It's astounding how many americans can forget about such obvious facts.
"Document flux management is great, but only if you reverse the polarity of the protocol suite and arfle barfle gloop."
Yeah, well, mock all you want, but the truth is you can do quite complex and useful things with it, and currently the Exchange environment and Lotus are the only kids in the block about this (not that I'm glad with such situation).
"Um, doesn't everyone do this?"
Nope. Probably it is not "notizing" the word I was looking for (sorry, but I'm not English); I'm meaning what IMAP IDLE brings to the table (but most mail clients still don't support) and Exchange seems to have from day zero.
"than "pops up an irritating focus-stealing dialog box"?"
You seem to forget that there's no need for pop ups or ringing bells but, anyway, pushing mail advertising instead of pulling means quite a lot of load avoided on servers.
Surely you are not one of those that thinks that can emulate Exchange functionality just with Postfix and Courier IMAP, do you?
"The only downside is that this doesn't sync"
And do you really think that's an "only"? A client for a groupware server that "only" lacks groupware support?
"Little bit of playing the Devil's advocate here..."
Quite badly, I must add.
"but can you name me another enterprise solution that lets you send and receive emails, delegate access to mailboxes (R, R/W), share calendars and delegate access to calendars with reasonable granularity?"
Basically... everyone?
You should have asked about the Exchange's really making difference features like complex document flux management, seemless integration with desktop office suite or instantly notizing new message arrival, but ACLs and shared mailboxes? That's so 90's...
"just providing an easy to install package just as they do for Windows"
I always find awesome that kind of stupidness and how it can be so prevalent among windows zealots.
What is the "multiplatformness" of Windows? Zero, nada. You can seemlessly install binary packages designed for Windows on Windows... because, heck, it's Windows! Installing Debian-designed packages on Debian is even easier than installing Windows-designed packages on Windows. On the other hand, installing Debian-designed packages on Windows is as much impossible as installing Windows-based packages on Debian (and even then, on Debian you have Wine).
Why people rise so utterly different expectations between Windows and any given Linux distribution is absolutly beyond me.
"It's perfectly possible that the recipient refuses delivery"
Yes, of course.
But the problem is that:
1) The recipient is *NOT* recieving the delivery to begin with, but someone else. "Hey, Mike, did you read my e-mail? No, I didn't recieve an email from you".
2) The recipient is *NOT* refusing my delivery, someone else is doing it on his behalf.
Again, were it be snail mail, it is not as if the recipient rejects the delivery but as if the chief postal officer from Wellington, Alabama said:
-So this for John Doe, Wellington, Alabama? But it comes from Dunkerk, North Carolina, *I* won't accept mail from Dunkerk, North Carolina.
-But John Doe is expecting this letter; won't you pass it to him so *he* is the one that accepts or rejects it?
-No, I won't. You may phone him instead.
"The point is, you cant reasonable expect your letter to be delivered."
I think this resumes your whole point. And I'd better won't tell what I think about the sensibleness of your point.
"I believe the opposite is true."
It truly depends on moment and situation.
"Microsoft knows this; it's what prevents people from leaving Windows."
But Microsoft is a 'de facto' monopoly. Of course it neither needs nor wants choices. What for?
But then, on an already diverse market, like it's the case for Linux, specially if you are in front for a head, as it's the case for Red Hat, you truly want to seem like you interoperate and then fail to do so in subtle manners (Microsoft knows that too and so it proves when trying to go into a new market): your apparent cooperation makes easy for the users from your competitors to migrate to your solution; your subtle incompatibilities retain those already in the net (have you seen those nets that have an ample entry but once you are in, the exit way is just a tiny hole?) so (hopefully) you grow your userbase at a exponential rate.
"Victor thinks he's so important that he can demand people not extend the courtesy of saying thank you in exactly the way he wants it"
Viktor thinks nothing.
It has been the norm for ages not to waste both time and bandwith with a "just to say thank you" response that benefits to no one (the same goes with the plain "me too" message) and so he says on his signature. True, I think it's quite pretentious (and against another known-for-ages Internet tradition) to have such a long signature specially when just a link to the old (but still maintained) "How to ask questions the smart way" or the RFC 1855 would have been enough but I'm sure he would be glad with an answer *to the list* recouping the question, the failed attempts and the working solution (or lack of it) so it can be easily spoted on the archives or even making its way to the FAQ.
Maybe it's rude but it certainly it's common sense too.
"You misunderstand the term "reliable" as it applies to networking."
You misunderstand in that you think we are talking about networking.
Not.
We are talking about the electronic mail service. And Venema is quite rigth about saying that today the electronic mail service is less reliable than in 1998.
"So, the key is to block at the SMTP level, which guarantees that the real sending server gets an error message."
So what? /dev/null. ...Oh, but it happens *I* am knowledgeable about the SMTP. So indeed I can manage my own server.
1) My [Big ISP] is not going to tell me some e-mail has been rejected 550 because [whatever]. It might even put it on
2) Even if my [Big ISP] returns me its SMTP chat regarding something about inverse resolution jabba-dabba I won't understand it unless I'm considerably knowledgeable about the SMTP. Good luck trying to get a working solution from the [Big ISP] helpdesk service.
3) But then, I "just" have to make an international phone call in the middle of the night to try to talk to the f* postmaster that decided that I'm a spammer because my IP address belonged some years ago to my provider's residential DHCP pool just to learn that...
3.1) Is their [another Big ISP] policy not to accept mail from my IP and there's nothing they can do or...
3.2) They are using [spamhouse du jour] and they are very glad using it since it in fact reduces there spam volume, the hell with whatever legit mail they are thrasing out unless hard pressed by the high C*Os, which is not the case.
The fact is that if you were talking about snail mail instead of email you would say "the heck with your damn lame excuses regarding international post agencies, delayed deliveries due to revolution at Toofarynstan or internal comdex regurgitation over the ultraviolet scam filter in Dunkerk: I put the letter on the postal box and it reliably ends up in the hands of its intended receptor or it doesn't". That's the only working meaning for reliability.
"As long as YOUR email admin handles error messages in any sane way, you'll get a phone number to call and talk to the guy who set up the system that rejected your email."
Well, I hope you will accept my reverted-payment phone call from Spain... in Spanish then.
"I note that Debian Etch is listed as planning to become LSB"
Well, AFAIK is mostly compliant if not completly compliant but for the paper. But this compliancy is basically of the kind of POSIX compliance on Windows NT: good to put it on a brochure and almost nothing else. Installing a LSB-compliant package on Linux means basically forget about the whole distribution (since it'll be a RPM package that won't integrate on the standard package database) or lose both compliancy and working ability since alienize a RPM will almost surely fail in subtle manners. It's as simply as that if I, as a user and sysadmin, wanted to install RPMs, I'd be using a RPM-base Linux distribution.
And then, the only packages I've seen that LSB compliancy made sense were privative-licensed and binary-only distributed, so no amount of LSB-compliancy would make me happy to use them.
"The idea is that it will no longer matter what distro you use"
Almost true but then, if it makes no difference why should I use any other? That's why Red Hat is the strongest pusher of the LSB among distributions: they hope that if they can convince enough people that indeed it makes no difference their dominant position and the network effect will sweep out rivals eventually. Then it won't be that it doesn't matter what distribution you use but that there will be just one distribution to choose from.
"Yet none of this stops Oracle RAC from installing on
Debian or Ubuntu"
True. Yet no ammount of LSB stops Oracle to only certify this or that platform (like RHEL 4u2 or Ubuntu Strange Scarab, or SUSE 10 or whatever) instead of, say, LSB 2.0.
So, the LSB is mainly aimed at attracting privative software like Oracle to Linux (who else need guaranteed ABI compatibility when you can recompile?), no wonder so many distributions don't care so much (especially when the "middle ground" that it's the basis of the standard looks so much like "whatever is shipped on current RHEL"); but then, privative software vendors feel they need much more confidence in order to certify to a platform than a "of a kind" standard, so they are not strongly pushing for it either.
End result? Well, it's been -how many? six years? and LSB it's only known to a bunch of freaks.
No wonder, did I say that yet?
"you don't have to worry about things like slammer or code red on Xandros."
I didn't have to worry about slammer on Windows, either back when I was sysadmining Microsoft systems (I'm not one of those that leave a SQL server wide open to the Internet, neither on Windows nor Linux) and, while code red was indeed and issue on Windows, so was Ramen on Red Hat (I indeed show Ramen-infected boxes back in the day due to sloppy practices just as I saw slammer or code red -I already stated my point: if Linux is a "minor" system in your shop and it is opened to the Internet, as I expect a mail server to be, it will be pwned).
"If you have a guy that really knows his way around Linux CLI,you don't need it."
The point is that even with the Linux guru in place, there is no good solution for groupware that can compete against Exchange functionally wise; not at least one soundedly engineered.
"Unfortunately a lot of companies,especially SMBs,have some guy that "kinda sorta" knows Winserver [...] and when it comes to securing a running server or enforcing good security policies are sorely lacking."
And that's the kind of guy that is most able to wreak havoc with a Linux server: Linux expects more than Windows from the chair side (it can offer more to that expert, but I don't think that's the point in case).
"the Xandros wizards make it really easy to add and activate a new server role when needed."
And again to square one. That's trying to fight Windows on its own grounds. SMB offers no less easy wizards to activate the box that *seem* to do the job. That, and the fact of Windows being Windows makes sure to win that battle.
"So in those cases Xandros gives them an easy way to switch a server to Linux [...] many an SMB and there is a great majority of users that simply don't need Windows,same with the servers."
That I will admit (while in true, quite a lot SMBs are tied to Windows, not because the OS by itself, but because those Visual Basic niche applications they depend upon), but I don't see it being the point: that they don't need windows, doesn't mean they want or need to go away from Windows.
"Why risk a virus or malware infection exposing your customer's data and your business to unnecessary risk"
But then, as I already stated, you are not talking about Windows server-side, but client-side: you won't get out the risk of malware by moving your servers, but by moving your servers *and* your clients.
Anyway, good luck to Xandros and any other initiative that make people more aware that there are other ways to professional SMB IT.
"If someone posted a picture of himself having sex on the Internet, that may reflect on his judgment."
It reflects much more on this society' illness and hypocresy. What's the problem about having sex?
"If you are stupid enough to have sex in public and get photographed doing it, then you absolutely deserve any and all negative consequences you get."
Just remember this if you ever need help from police. If you are stupid enough to walk on the street you deserve whatever will happen (robbery, assassination...). If you are stupid enough not to protect your houme like a bank you diserve somebody "cleaning" it inside out. If you are stupid enough to drive your car, you diserve somebody crashing at you. Etc.
"Behave well, and you have nothing to fear..."
That's one of the stupidest things I read for ages.
"The context here is 17-year-olds holding up a beer can and posing for the camera. There is a difference between not drinking and not drinking under-age: only one is illegal."
But there some more context too.
The context is that on the USA it is considered that a 17 year old boy is not mature enough to drink responsibly, thus he is banned to do it (on the other hand, wtf? He is mature enough to drive over one tonn of steel 60mph, he can be held responsible enough to be killed because of his actions in some states, but still he's not considered mature enough to have a beer or cast a vote??? but I'm disgressing).
The point is that we are talking about high school, a place were people goes to enhance his knowledge, culture and maturity and because of a mild sign of lack of maturity he is banned from the very site this could be corrected? That's insane, not to talk about the deep effect this underthought decision from somebody that probably just had better luck (not that he didn't drink if even a beer when minor, but he is just not online) will probably have for his whole life.
"It's not out of the ordinary for a network administrator to ban an entire domain to help secure his network."
Yes. I think this has a lot to do with Sturgeon's law: network administrators are not an exception for the 90% law.
"An appointment that occurs every Monday, Wednesday, and Friday. That's how college classes are typically scheduled."
And your point is?
"No viruses,spyware,and a lot harder to hack sounds like vastly superior to me."
What do you mean? I do use exclusively Linux from quite a lot of years and my inbox is still full of viruses and spyware. The fact that they don't affect me doesn't mean they are not coming in; and since you talked about a "windows shop", I'll bet clients are Windows-based, and being so, you cannot go without antivirus and antispyware, both server and client-side, no matter if you are using Exchange or Scalix or whatever.
And about "a lot harder to hack", that I'd have to see with my own eyes. It's quite a lot of years that Bellovin wisely said that the thoughest platform is the one you are most experienced with, and on a "windows shop" that means... Windows.
"And if you need something that just works out of the box with no fussing or CLI,then Xandros is the way to go."
And Windows is much better if that's your consideration. Not only that, but it's Windows the one that stablish the mark regarding what's "not fussing or CLI"... specially on a "windows shop".
"It plays nice with AD, it plays nice with login scripts,and the desktop(Xandros Business) even has a "Behave like Windows" button"
Not better than native windows, and windows behave like Windows without the need of any button.
"If you need a drop in replacement for Winserver+Exchange"
And, again, that's the very failure of their bussiness case: nobody needs a "Winserver+Exchange" replacement, when they can get "the original" almost for peanuts (locally-wise). And, hey!, you'll never get fired by choosing Microsoft (specially in an already "windows shop").
"But everyone looks to be bumping heads. If someone in the community would just use Postfix, Cyrus or Dovecot and other open source technologies instead of writing their own, maybe there would be a decent groupware solution for linux."
You surely are not doing your homework. Kolab has its own share of defects, but reinventing the wheel is certainly not one of them using OpenLDAP, Postfix, Cyrus IMAP, Apache, SASL and OpenSSL.
"freedom 1 guarentees *me* that I can study *your* changes when I run *your* code on my computer, or my phone, or my dvr or my tivo, or whatever. If I get a *modified* copy of it from your server in binary format to run on my device I want the freedom to get the code as well."
That's quite questionable.
On one hand, if I get from your server, say, a Java applet, I think that would be considered redistribution even by the "standard" GPL, so you should provide me the applet's source code. Would that mean that you should provide me whatever code for your backend server, say the code for the servlets? Probably you would agree that the server side code is not needed to be distributed in this case. By the way, that's exactly how Red Hat understands it when they provide the source code for the RHN client but won't publish their server solution (RHN satellite notwithstanding).
On the other hand, if we are talking about "pure" script output, which seems to be the case you are referring to, what does indeed run on the client computer? The modified server? No, I say that's not what runs on the client machine. All that runs on the client machine is a bunch of human readeable HTML and Javascript code -and you already have the source code for this; just ask your browser to show the source code for the current page. And what about the server-side code that produced the output you recieved? No sir, that code never run on a client, only on my server and, obviously, code running on *my* server and only on *my* server can't be considered to be distributed, right?
I'm not trying to make a point about which is the "proper" way to go or if the AGPL is more "on the Stallman way" than the GPLv3 or not, but that certainly the server-side code for a SaaS environment is quite a different beast than a "typical" binary regarding distribution and its implications.
"Basically, there are a class of changes you can't make: ones that remove a link to your source tarball."
You are wrong. You can indeed change or remove that link *provided* you produced your own alternate means for the user to remotely download the sources too.
"how up to date does the source you offer have to be?"
There's only one kind of "currency" regarding that kind of cases and it's "there's no currency". On the standard GPL you must provide the source that made up to the binaries you distributed; on the AGPL it's just the same: which sources? heck, the ones needed to build the application I interact with.
"If so, then the only way to handle that is pretty much be offering dynamic tarballs of your production code - being very, very careful to strip out your config files"
That wouldn't be a license problem: "do you want to use this code? These are the constraints that I, as the coder, want to exercise, take it or leave it". On the other hand, it is not a technical problem either. It is you the one that talk about using vim to edit a production-live environment; it is *you* the technical problem and liability, not the license. In order to provide the source code to match your production environment, you just need to mildly adapt your code promotion procedures so your ready-to-production codebase is just copied to an end-user reacheable environment at the same time it moves into production.
I haven't read the AGPL except for the paragraphs found in this thread, since I haven't find a case of me using software under such license but, to me it seems it honors just the same phylosophy that moved GPL from version 2 to 3. The tivoization case was found by Stallman to be so against GPL's phylosophy as to adapt it; AGPL seems to target exactly the same kind of problem only on a different environment (the ASPs).
"What most irks me is that..."
Is that it irks you, nothing more, nothing less. You are in exactly the same case than the BSD vs GPL discussions: one side will state that they prefer what BSD offers, and the other will find the GPL "ideal" to be highly preferable. Well, you find that having to offer the sources for an application you happen to allow by remote X is not the way you want it; others find they don't want to offer their valuable modifications to a codebase just because they happen to distribute binaries of the modified result.
On my humble opinion, I think that *if* you accept the GPL because of the underlying ideal, you should accept both GPLv3 and/or AGPL as a natural evolution of the ideal that created the GPL on first place.
"I won't have an Outlook replacement until I can create a weekly MWF recurring appointment, or something of that nature, without creating a separate recurring appointment for each occurrence during the week."
WFT is a MWF recurring appointment? And don't tell me RTFM or you will be KIA ASAP.
On the other hand, in my opinion Kontact (the KDE groupware client-side solution) is vastly superior to Evolution for a PIM. Just in this case, I've been able to appoint recurrent events on Kontact for ages. I can define if the recurring event will be daily, weekly, monthly or yearly; I can tell, for instance, it'll be recurring each three weeks monday, tuesday and friday and, of course, I can make exceptions. To me, the only lacking (but weird) facility is that I can't define a protocol for a recurrent working-day event to be automatically moved if a day happens to be a holiday (say a repetition happens to be on december 25, which is a national holiday on my country; this kind of ocurrences I would want to be able to define either as an automatic exception or automatically moved to the next -or previous, working day; maybe to Dec26 or to the next monday if Dec25 happens to be friday).
"An IT Professional, is someone who is concerned about IT's relationship to the overall business, understands the difference between IT being simply a cost-center, or a profit enhancer."
Sorry sir, but no sir. What you have defined is a CTO (or depending of circumnstances, a CIO or an IT manager). We (hopefully) expect a CTO to be an IT professional but CTOs are only a subset of all IT professionals.
"That attitude is how we got the San Francisco fiasco. That dude was less concerned for the REASON for that network, than for the network itself."
Which certainly doesn't mean that guy not being an IT professional; it meant he wasn't an IT manager. And it meant that his manager, who should have been an IT manager wasn't an IT professional. *THIS* was the reason for the SF fiasco.
"There are too many pasty-fat bastards with poor social skills managing networks and scripting Excel macros"
That might be true, but I don't see were the social skills are needed for a "managing networks and scripting Excel macros" professional profile. Their managers? Sure, but not the doers.
"A professional does whatever it takes to become more effective at their job. If you work in IT, and have never done a cost analysis, never done a P&L document, or a gap analysis, than you are a mere technician"
Surely you use quite a weird definition for a professional since you think a "mere technician" not being one. My bet is that you bought an "IT management for dummies" book last week and you are just full of it. Don't worry, eventually it'll fade away.
"did you present your management with a cost/benefit analysis, supporting your request for additional hardware?"
Since he tells how bad is his management, we can infere his is not a manager. Then it is not his job to provide a cost analysis, that's the job for someone... in management. Even more: since he is not in management, he is probably not in a position to make a sensible cost analysis even if he tried. Does he know the costs involved with someone not working for an hour in a different department? Is he even *allowed* to gain knowledge of such costs?
On the other hand, he was not talking about some esotheric IT subsystem. The problem here is an obvious one: you have a system that loads up linearly at best with the number of people accesing it (one user one mailbox; two users two mailboxes, three users, etc.); the number of people has suddenly grown by 40%; you don't need a genious to understand you will need to grow your hardware by 40% too (indeed you might need a genious that will find a way to cope with the higher load without growing the supporting structure, but that's a different issue). That management won't understand that simple issue means management is idiotic. That it's probably not the case that they don't understand it but that they run out of money after the aquisition because they didn't consider associated structural costs for the migration show -again, that management is idiotic.