I wonder if anyone thought to save a copy of it? I remember seeing it at the time, and I remember how pissed off people were about it, but I had *no* idea it was going to bring about such a sea change in the Internet.
In looking back, I'd call that message the first real sign of the commercialization of the Net -- sort of the acorn from which a mighty tree grew. Unfortunately, in this case, it was more like kudzu -- has gone EVERYWHERE in EVERYTHING and you can't get RID of the stuff.:-)
[...]
don't forget the obfuscated C contest has been around longer than the obfuscated perl one).
Er, this might have something to do with the fact that C has existed rather longer than has Perl. In fact, I suspect that the Obfuscated C contest itself is older than the entire Perl language.:-)
Security through obscurity is really only a temporary stopgap. It slows down an attacker but it doesn't prevent him/her/it from eventually finding and attacking holes. Worse, most of the proprietary vendors have been quite slow about releasing patches.
I don't have any way of knowing how long it will take, but you are seeing the bugs getting shaken out of the operating systems we depend on. They're very complex creations and there are probably whole classes yet of undiscovered security exploits.
Open source allows people to more effectively find and attack holes. This means that they are both found and fixed faster. It is my belief that eventually, the open source operating systems will come pretty close to being free of security holes. It's unlikely to ever be 100%, but the number of remaining, unfound security flaws should slowly approach 0 without ever quite touching it.
The closed-source operating systems, Microsoft's in particular, are a long way further up that curve. I'm guessing that you're going to be seeing nasty system holes in those operating systems for years and years after they have slowed to a mere trickle on the Unices. You just can't assemble forty million lines of code and put it into production without there being problems. Linux has 1/10th the code size, and because of that probably 1/1000th of the potential security-breaking unforeseen interactions.
The so-far-unstated assumption I have is that systems will eventually get extremely secure. This could be wrong. If new bugs get added as fast as, or faster than, old ones get taken away, then the high number of found bugs in Open Source software will prove to be only a detriment.
I'm *assuming* that we are paying now to have security later. But if we aren't, then the security through obscurity model is probably RIGHT -- because if there will ALWAYS be new security holes, any method of slowing down detection of those holes makes sysadmins' lives a little easier.
We will probably know which of these two models is right within the next 3 or 4 years. In the interim, fight very hard any suggestion to suppress information about hacks/exploits or cracking tools. The ultimate goal is secure systems, and it will take some time for us to find out which way is more secure in actual practice. If one method is hamstrung by legal action, then we may never know the right approach and may forever suffer with buggier software than we needed to.
By the 2004-2005 timeframe, the overall progression in the number of bugs reported on Open Source versus proprietary systems should be much clearer, and we will likely make much more intelligent decisions.
"Reasonable people adapt themselves to the world. Unreasonable people attempt to adapt the world to themselves. All progress, therefore, depends on unreasonable people." -George Bernard Shaw
It's expensive now, but it won't always be. Technology gets cheaper all the time. They can do it to 1 person in 10,000 now -- in ten years it might be 1 in 5. They might be able to lean on keyboard manufacturers to install keystroke monitors on ALL computers.
> Again, you're being paranoid. If you haven't done anything illegal, you have nothing to hide.
This is a very common -- and frighteningly stupid -- argument. Everyone has something to hide.
Do you want to conduct the rest of your life knowing that every single communication you ever send to anyone can be intercepted, taken out of context, and broadcast for the world to see?
Can you imagine anything more restrictive to free expression than the knowledge that you can never again keep any written thought private? If that doesn't scare you, that means you aren't creative and intelligent enough to come up with ideas that frighten the authorities.
Don't you realize that you are talking about thoughtcrime?
I've been around Linux a long, long time. It is just as susceptible to bad drivers as NT is. The simple fact that bad drivers aren't at all common doesn't change the fundamental design.
Get a buggy driver on your NIC and watch how long your server stays up. Been there, done that. Early Intel NIC drivers had real problems.
Linux's drivers are better than many third-party drivers under NT, but that doesn't change the fundamental design. It's still monolithic -- nicely modular, but really just a modifiable monolithic design. There isn't much protection in the kernel against bad drivers. You'd need a microkernel for that.
If I had been running Sendmail on the aforementioned Linux-with-bad-Intel-NIC-driver, I'd have had a system just as unstable as his NT servers. So according to you, Sendmail is poorly written, Linux is shit, or I was incompetent. I know you're going to argue #3 but I'm certainly no less competent than the parent poster here was.
It is entirely possible to run very large and very stable Exchange setups. If Exchange isn't stable for you, chances are that something is wrong with the system on which it is installed. It may be hardware, or it might be an OS issue, but the Exchange software itself is very solid.
Get off the zealot bandwagon and listen to people who have actually lived and worked with this stuff for awhile. Saying things that aren't true (ie., 'exchange is crap', which it isn't) hurts your credibility and makes it much less likely that people will believe you when you tell them Linux is a good choice for something.
You're in a bigger environment (a lot bigger) than I was, but my experience with Exchange was that it was VERY VERY solid if you dedicated machines to it. If you were experiencing constant crashes there was probably something else going on -- maybe a bad driver on the systems.
As I've stated elsewhere, I'm not at all fond of Microsoft, but Exchange is probably their best product.
You need fast CPUs to run Exchange well. PPros never went much past 200Mhz. It would be trivial to support 500 users on a dual P3/800 with a nice SCSI RAID and 512MB or a gig. (better). I haven't done this, so this is a guess, but you could probably hang about 2500 users off a box like that without too much trouble. You would need multiple NICS to drive that much bandwidth, but the basic machine should be able to take that kind of load and maintain acceptable performance.
A lot also depends on whether or not you use the 'mailboxes on server' or 'mailboxes on client' approach. If you put mailboxes on the client you could probably do anywhere from 10K to 20K users on that same machine.
I used their backup and antivirus programs and both were complete and total crap. Somewhere archived on Slashdot is a long rant I wrote about their horrible, horrible backup system. It's utterly broken past a certain number of files and all their workarounds, well, don't.
Avoid ANYTHING by the former Cheyenne. Absolute shit products.
I'm not especially fond of Microsoft as a company, but I've been working with both Open Source and Microsoft solutions for many years now. I'm no apologist for them, but Exchange is one of their best products.
The earlier versions had problems. 4.0 was particularly troublesome, as I recall. I know I had many headaches with it. I was pretty green back then, so I'm not sure if the problems were Exchange or the administrators, but it broke all the damn time. We didn't lose much mail but we were constantly seeing things stick in queues, and every once in awhile something would disappear. That's NOT good in a mail system(!).
In my next company they were running 5.5, which was very solid. We scaled successfully from 50 users to about 400 over the space of about two years, and then merged with another company of about 800 employees. There were little glitches here and there, but we never lost mail due to any mistakes or bobbles in Exchange. There are some maintenance issues in 5.5, and it's not very scriptable, but it's quite trustworthy.
I'm currently doing an Exchange 2000 installation into Windows 2K. (Keep in mind that I'm also installing Linux, BIND, and Sendmail here.) So far I am very impressed.
I don't yet fully understand the implications, but it appears to me that Exchange's integration into Active Directory is going to be a very powerful tool, and not just for administrators. I haven't seen anything equivalent in Open Source at all. I think LDAP may do some of the same things, but my impression is that the LDAP tools aren't anywhere near the maturity of the Win2K tools. (Of all the things I'll say here, this is the area about which I'm most ignorant, and I encourage corrections.)
While I would personally be very comfortable with a Unix solution, the fact that you have to write scripts to do most complex tasks on a regular basis means that junior admins just aren't very good at it. I'm trying to build this system so that junior admins can run it safely but still be able to do powerful things. And I don't have time to write a library of scripts for them. Exchange is really the only reasonable answer in this sort of environment.
Keep in mind that you do not need to standardize on Outlook at all. You do get some nice shared calendaring features if you do that, but you can support IMAP and POP3 through the server quite easily. The server issue and the client issues are different: don't let them confuse the two.
For mail storage, I don't much like the idea of zillions of files on zillions of computers. I prefer the 'keep mail on the server' model, a la IMAP. In a commercial environment I'd call this almost a necessity. It's very difficult to monitor hundreds of NT machines at once. Instead, you put all the eggs in one basket, and watch that basket.:-)
I don't think I'd personally want to do a mail store on a Linux machine quite yet. Ext2 is fragile as hell. ReiserFS looks better but I'm only just now going into testing on it. Solaris or SGI with IMAP would be reasonable solutions, but very expensive and the client would lose a lot of the power of a directory system. (even if Active Directory IS 1.0, it's still a hell of a lot better than NT 4 was!)
To give them some of the scripting power, I'm setting up an external Sendmail (or possibly Postfix, haven't decided yet) relay. That way, they can get most of the Unixy scripting power if they need it -- the sendmail transforms can be done at the relay. And they get the nice solid safety of an NTFS information store, which I like a lot. I also trust Sendmail and/or Postfix more than I do Exchange, as far as security is concerned -- opening an Exchange box directly to the Net frightens me. I much prefer the relay idea. But I don't trust Linux/sendmail to keep the information safe once it's delivered, thus NT/Exchange on the backend.
Keep in mind that Linux's issues with filesystem reliability are being remedied, and that Exchange 2000 is relatively unproven at this point, so don't rely on these comments much past March of 2001. By then the picture may be quite different.
But right now, it sure looks like Exchange is one of your better bets for corporate mail.
Ok, and how do you guarantee that what you saw was real and not synthesized and implanted?
Granted it wouldn't be easy to do this, but with that kind of chip implanted how could you EVER be 100% sure that everything you were seeing was real?
Considering how incredibly insecure most software is these days, I think I'll pass on retina implants. I'd sure hate it if my sight depended on keeping up with and patching against the latest exploits.
(and yes this is exaggeration for effect -- but I am about 75% serious here)
I don't know the lines-per-minute I was getting, but a couple years ago when I was last using Delphi heavily, I do know that the build time was never longer than three or four seconds for even a moderately complex project. And I was on a relatively slow machine!
Delphi is the most amazing piece of technology I've seen in Windows. I remain amazed, years later, that it didn't take over the world.
Delphi is most certainly worth paying for. While I didn't upgrade to the later versions (they were mostly going in a direction that didn't appeal to me), I spent quite a bit of money on it through version 3.
I plan to drop $$$ on this one the instant it ships. I have no argument against paying for good software.. and Delphi is GREAT software. If they can do even 75% as well under Linux as they did under Windows, it'll be worth every penny.
Linux needs this kind of app desperately, and I urge any of you with the financial wherewithal to pay for it as well, if it suits your needs.
For the windows version, $700 was entirely reasonable. The tool is amazing. I consider the $99 version to be an absolute steal.
I know there there is at least one case that addresses this issue. In it, it was determined that the exchange of goods happens as the money changes hands (ie, at the checkout line) and at that point everything you bought is your property and is not subject to search except by a peace officer who has probable cause to believe a crime was committed. (and refusal to allow a search CANNOT BE grounds for a search or the Fourth Amendment goes away.) But I was told verbally about this case by a friend who thinks much the way I do. I have not read it myself, so my assertion should be put in the 'very much unproven' category unless you can do your own research. It's working for me but things may be different where you live!
The other poster in this thread claims that they have the right to search you if you've been in the store before and know about their policy, to which I say 'Balderdash!' I don't give up my rights EVER. Walking into a store doesn't make me subject to search without probable cause no matter what signs they put up. I didn't sign anything. Since it has been proven many times in court that you cannot give away your rights even with your SIGNATURE, how could walking into a store ANYWHERE constitute an agreement to ANYTHING?
Let me put it to you this way: I just say 'no' and walk out. In almost every case they have simply subsided. I believe it must be part of their training: "if a customer refuses to have his/her bags inspected, don't press the issue."
I have gotten crap for this once, from a foreign person who believed he really did have the right to search me. I told him that he didn't and that I was leaving, and did. He didn't chase me.
There have been a couple of other uncomfortable moments -- several staff at one Best Buy exploded out of the store after I left and set up surveillance to see what exactly I put into my car. That was pretty weird, and I was tempted to walk back to them to tell them I knew exactly what they were doing, but I just put my bag (my FULLY PAID FOR bag) in my trunk and drove off. And I have been eyeballed pretty intensely a time or two.
It was quite difficult to do this the first few times, but it gets easier each time. Now I don't CARE what they think or what they do. I'm not a criminal, I didn't do anything even a tiny bit wrong, so they can eye me all they like.
And refusing to submit to search does NOT imply guilt no matter what ANYONE tries to tell you. I don't steal things. I also (politely) refuse to be searched. Just because the other sheeple go along with it doesn't mean I have to.
Stores do not have the right to search you. Say 'no' and leave. I do this all the time -- and I'm entirely honest. I don't steal things, I just refuse to be searched. They can't do a damn thing about it.
The only stores that CAN search you are ones that make membership contingent on you being searched -- I believe they make you sign forms to get the membership. (I am specifically thinking of Costco.) I am thinking that this may be something you could fight, but it would probably be a big scene.
But in any non-membership retailer, just say no and walk out. You're doing everyone a favor.:-)
Don't give up your rights voluntarily to 'be nice' -- if everyone does that they disappear!
Remember MAME? It's a software emulator of very specific hardware characteristics. Now, I don't know just how defined the Amiga architecture is in this new release, but it's certainly possible that you may be able to know clock cycles in this virtual assembly. They're wouldn't be 'real' clock cycles, they would have to be emulated, but for probably 95% of the problem set that's fine.
If you get into needing hard real time, you have to be hand-writing to the bare metal anyway. This virtual assembly wouldn't do the job. This is portable and hard-real time can't really be portable -- you have to recode it to every new hardware environment. This is not TRUE assembly and won't cover all of the bases that the real thing will, but depending on their implementation it could be guaranteed that this demo would always APPEAR TO run at, say, 50fps on any machine that is 'officially supported'. I don't know that this is true, I'm just asserting that it's possible. Again, see MAME.
It's also worth pointing out, as an aside, that this language seems a lot more readable than C.
Looks to me like they could get some pretty good performance out of this beast -- along the lines of C code, but fully portable across any platform that's fast enough.
When I first heard about this new Amiga, it struck me as the stupidest thing I'd ever heard. ("That's not an Amiga, wtf are they thinking??") -- but I'm pretty intrigued by what I'm seeing. Doesn't matter HOW you get where you're going as long as you get there -- and if they can bring the crisp, lightweight, but powerful feel of the Amiga back to modern computing, cool.:-) Hope they get wildly rich.:-)
You need to learn better how to pull out the interesting facts from the crap. I used that same article to discover the existence of www.r3mix.net, where I learned how to encode mp3s well enough that I can barely, barely tell the difference with good quality ($400) headphones. (with a few of my CDs there are 3D-ish effects that are lost in MP3 encoding, for example.)
Ask/. articles are often a great way to get info but you have to be willing to do some reading and thinking for yourself. Often the best articles are the shortest ones -- they are just links to outside sources.
This article is way inferior to www.r3mix.net. You should go back to that old Ask/. article and figure out why you didn't pick up on that web site. The fact that you didn't come away with an answer from the first article was entirely your own responsibility. All the info you needed was there.
I don't even use Linux as a firewall. It's a great router, but in the v2.2 kernel, the firewalling code is pretty weak. It's stateless; that is, you have no context about a packet. You can't (easily) allow, say, all outgoing traffic on port 80 while refusing it inbound.
You can get around this by filtering on particular combinations of SYN/FIN/RST, but that makes it pretty easy for someone using NMAP to get packets in past your filter.
Personally, I use OpenBSD as my firewall/NAT device. Stateful inspection firewall for free -- gotta love it. I even paid for mine.:-)
There are some nice online pages that will walk you through a series of questions and generate an ipchains ruleset for you. It's a lot better than nothing, and it's a good place to start learning about firewalling, but the process is complex enough that any form of automation is likely to make assumptions you may not like. The Checkpoint Firewall-1 product comes to mind. Out of the box, the 4.0 and 4.1 installations are just dreadfully insecure. It's easy to administer but it's got tons of holes in it. That's my biggest fear about automated rulessets.
But doing it by hand isn't very likely, for most folks. I'd say no more than one person in a thousand is really qualified to be writing firewall rulesets. Hell, I've been learning this stuff for three years and I'm still not sure I'm entirely qualified.:-) The whole process is just enormously complex and incredibly prone to error.
I'm not sure what the answer is here -- TCP/IP requires an extraordinary amount of study in order to be used in s 'safe' way. From a security standpoint, I think the protocol may be essentially useless. You CAN get security but it's so difficult as to be impossible for 99.9% of the public.
I'm struck that maybe it's time to toss out the whole mess and start over -- except in the real world, that NEVER happens. Look at COBOL.:-)
About all that would happen that way is a denial-of-service. Default gateway has to be one hop away. A remote attacker can't specify his own IP address as your gateway, he has to specify another machine on your network. So he can shut you down remotely, but that's about all.
Now, this attack is useful once he has control of a machine on your network. There are all SORTS of exploits once you have root access to the wire. This is a lot of the reason for the domino effect -- once you lose one machine, your others usually fall over like dominoes because they trust that machine not to be malicious.
Security is a process, not a state. The more secure you think you are, the less secure you tend to be. Andy Grove would love this field -- 'only the paranoid survive':-)
It would have been really dumb to buy an Amiga instead of a NES if you wanted to play games.
We bought an Amiga 1000 in Christmas of '85. (my parents did actually, I was pretty young back then.:) ) It cost us $3500 for a machine with 512K and two floppy drives (and $50 for our first box of 10 880K 3.5" disks(!)).
It was a great games machine, but it really didn't get any games worth mentioning for nearly two years after its release. That whole first year I think we had two games to play: "Dr. J and Larry Bird Go One on One", and "Archon". Archon was an incredible version and helped tide us over until the next wave of games showed up, like "Arcticfox" (a game I would probably still play today, if I could find a copy to play under WinUAE.)
Compare that utter paucity of games to a NES, which cost 1/35th as much and had 50 times as many games. I'd say buying the NES made a hell of a lot more sense. Some of the Amiga games were amazing, but so were some of the NES games, and the barrier to entry was a lot lower on the console!
That was 98, and 98 isn't exactly known for reliability. You occasionally hear about machines lasting that long, but it's almost unheard of for systems that are actually doing anything. Yes it was a bug, but it was a bug that didn't matter in practical use for 99.9% of the customer base.
A problem is, however, a problem if people notice it. Linux crashing after three weeks *matters*.
You may not believe you should be held to the standards that Microsoft is held. I agree with you: I think you should be held to a higher standard still.
I also agree with you that knowing exactly how bad the bugs are is a blessing. It IS good for us to know if there are problems with a product. And the fact that we have full control of the technology is also a Good Thing; it's the biggest reason to use a distribution like Red Hat.
Whether you like it or not, however, you are in the business of providing many of the same things that Microsoft provides. The software you ship must work. RedHat 7 dies after three weeks. If Microsoft were to ship code like that they would be drawn and quartered in the press. It would literally cost them billions, both directly in stock price, and indirectly in reputation damage, were they to ship a product in that state.
I don't think it's unreasonable to expect Redhat to not only do as well, but to do BETTER than Microsoft does. You have a whole army of people working for you for free that Microsoft does not. Isn't it your job to make sure that the bugs are ironed out? You're starting with some of the most stable code running anywhere, and assembling that code into a system for general consumption. If QA isn't Job 1 for RedHat, what is?
You have frequently compared RedHat to Heinz ketchup. People can make their own ketchup, but Heinz still sells an awful lot of the stuff, because the consumer has come to expect a consistent, quality product. Well, you have just shipped millions of bottles of ketchup that leak. Admittedly, it's good that we know about the problem, but the bottles still leak. What do you think this would do to Heinz' reputation?
Personally, I am firmly in the Eric Raymond corner of the Free Software world -- what I want is software that doesn't suck. I'm willing to pay for it if I need to. I am a professional system administrator. I need to build systems that run and run and never fall over. The control over the technology is important, but it is a secondary goal for me; having access to the source is good, but FIRST it must work. SECOND the source must be open.
The fact that you open source everything is not an excuse to ship bad software. Open Source garbage is still garbage.
Slashdot Mirror
I wonder if anyone thought to save a copy of it? I remember seeing it at the time, and I remember how pissed off people were about it, but I had *no* idea it was going to bring about such a sea change in the Internet.
:-)
In looking back, I'd call that message the first real sign of the commercialization of the Net -- sort of the acorn from which a mighty tree grew. Unfortunately, in this case, it was more like kudzu -- has gone EVERYWHERE in EVERYTHING and you can't get RID of the stuff.
Er, this might have something to do with the fact that C has existed rather longer than has Perl. In fact, I suspect that the Obfuscated C contest itself is older than the entire Perl language. :-)
Other than that, interesting points. :-)
Security through obscurity is really only a temporary stopgap. It slows down an attacker but it doesn't prevent him/her/it from eventually finding and attacking holes. Worse, most of the proprietary vendors have been quite slow about releasing patches.
I don't have any way of knowing how long it will take, but you are seeing the bugs getting shaken out of the operating systems we depend on. They're very complex creations and there are probably whole classes yet of undiscovered security exploits.
Open source allows people to more effectively find and attack holes. This means that they are both found and fixed faster. It is my belief that eventually, the open source operating systems will come pretty close to being free of security holes. It's unlikely to ever be 100%, but the number of remaining, unfound security flaws should slowly approach 0 without ever quite touching it.
The closed-source operating systems, Microsoft's in particular, are a long way further up that curve. I'm guessing that you're going to be seeing nasty system holes in those operating systems for years and years after they have slowed to a mere trickle on the Unices. You just can't assemble forty million lines of code and put it into production without there being problems. Linux has 1/10th the code size, and because of that probably 1/1000th of the potential security-breaking unforeseen interactions.
The so-far-unstated assumption I have is that systems will eventually get extremely secure. This could be wrong. If new bugs get added as fast as, or faster than, old ones get taken away, then the high number of found bugs in Open Source software will prove to be only a detriment.
I'm *assuming* that we are paying now to have security later. But if we aren't, then the security through obscurity model is probably RIGHT -- because if there will ALWAYS be new security holes, any method of slowing down detection of those holes makes sysadmins' lives a little easier.
We will probably know which of these two models is right within the next 3 or 4 years. In the interim, fight very hard any suggestion to suppress information about hacks/exploits or cracking tools. The ultimate goal is secure systems, and it will take some time for us to find out which way is more secure in actual practice. If one method is hamstrung by legal action, then we may never know the right approach and may forever suffer with buggier software than we needed to.
By the 2004-2005 timeframe, the overall progression in the number of bugs reported on Open Source versus proprietary systems should be much clearer, and we will likely make much more intelligent decisions.
It WAS ugly, but damn you could see it. :-)
"Reasonable people adapt themselves to the world. Unreasonable people attempt to adapt the world to themselves. All progress, therefore, depends on unreasonable people." -George Bernard Shaw
It's expensive now, but it won't always be. Technology gets cheaper all the time. They can do it to 1 person in 10,000 now -- in ten years it might be 1 in 5. They might be able to lean on keyboard manufacturers to install keystroke monitors on ALL computers.
Think about it.
This is a very common -- and frighteningly stupid -- argument. Everyone has something to hide.
Do you want to conduct the rest of your life knowing that every single communication you ever send to anyone can be intercepted, taken out of context, and broadcast for the world to see?
Can you imagine anything more restrictive to free expression than the knowledge that you can never again keep any written thought private? If that doesn't scare you, that means you aren't creative and intelligent enough to come up with ideas that frighten the authorities.
Don't you realize that you are talking about thoughtcrime?
I've been around Linux a long, long time. It is just as susceptible to bad drivers as NT is. The simple fact that bad drivers aren't at all common doesn't change the fundamental design.
Get a buggy driver on your NIC and watch how long your server stays up. Been there, done that. Early Intel NIC drivers had real problems.
Linux's drivers are better than many third-party drivers under NT, but that doesn't change the fundamental design. It's still monolithic -- nicely modular, but really just a modifiable monolithic design. There isn't much protection in the kernel against bad drivers. You'd need a microkernel for that.
If I had been running Sendmail on the aforementioned Linux-with-bad-Intel-NIC-driver, I'd have had a system just as unstable as his NT servers. So according to you, Sendmail is poorly written, Linux is shit, or I was incompetent. I know you're going to argue #3 but I'm certainly no less competent than the parent poster here was.
It is entirely possible to run very large and very stable Exchange setups. If Exchange isn't stable for you, chances are that something is wrong with the system on which it is installed. It may be hardware, or it might be an OS issue, but the Exchange software itself is very solid.
Get off the zealot bandwagon and listen to people who have actually lived and worked with this stuff for awhile. Saying things that aren't true (ie., 'exchange is crap', which it isn't) hurts your credibility and makes it much less likely that people will believe you when you tell them Linux is a good choice for something.
You're in a bigger environment (a lot bigger) than I was, but my experience with Exchange was that it was VERY VERY solid if you dedicated machines to it. If you were experiencing constant crashes there was probably something else going on -- maybe a bad driver on the systems.
As I've stated elsewhere, I'm not at all fond of Microsoft, but Exchange is probably their best product.
You need fast CPUs to run Exchange well. PPros never went much past 200Mhz. It would be trivial to support 500 users on a dual P3/800 with a nice SCSI RAID and 512MB or a gig. (better). I haven't done this, so this is a guess, but you could probably hang about 2500 users off a box like that without too much trouble. You would need multiple NICS to drive that much bandwidth, but the basic machine should be able to take that kind of load and maintain acceptable performance.
A lot also depends on whether or not you use the 'mailboxes on server' or 'mailboxes on client' approach. If you put mailboxes on the client you could probably do anywhere from 10K to 20K users on that same machine.
I used their backup and antivirus programs and both were complete and total crap. Somewhere archived on Slashdot is a long rant I wrote about their horrible, horrible backup system. It's utterly broken past a certain number of files and all their workarounds, well, don't.
Avoid ANYTHING by the former Cheyenne. Absolute shit products.
The earlier versions had problems. 4.0 was particularly troublesome, as I recall. I know I had many headaches with it. I was pretty green back then, so I'm not sure if the problems were Exchange or the administrators, but it broke all the damn time. We didn't lose much mail but we were constantly seeing things stick in queues, and every once in awhile something would disappear. That's NOT good in a mail system(!).
In my next company they were running 5.5, which was very solid. We scaled successfully from 50 users to about 400 over the space of about two years, and then merged with another company of about 800 employees. There were little glitches here and there, but we never lost mail due to any mistakes or bobbles in Exchange. There are some maintenance issues in 5.5, and it's not very scriptable, but it's quite trustworthy.
I'm currently doing an Exchange 2000 installation into Windows 2K. (Keep in mind that I'm also installing Linux, BIND, and Sendmail here.) So far I am very impressed.
I don't yet fully understand the implications, but it appears to me that Exchange's integration into Active Directory is going to be a very powerful tool, and not just for administrators. I haven't seen anything equivalent in Open Source at all. I think LDAP may do some of the same things, but my impression is that the LDAP tools aren't anywhere near the maturity of the Win2K tools. (Of all the things I'll say here, this is the area about which I'm most ignorant, and I encourage corrections.)
While I would personally be very comfortable with a Unix solution, the fact that you have to write scripts to do most complex tasks on a regular basis means that junior admins just aren't very good at it. I'm trying to build this system so that junior admins can run it safely but still be able to do powerful things. And I don't have time to write a library of scripts for them. Exchange is really the only reasonable answer in this sort of environment.
Keep in mind that you do not need to standardize on Outlook at all. You do get some nice shared calendaring features if you do that, but you can support IMAP and POP3 through the server quite easily. The server issue and the client issues are different: don't let them confuse the two.
For mail storage, I don't much like the idea of zillions of files on zillions of computers. I prefer the 'keep mail on the server' model, a la IMAP. In a commercial environment I'd call this almost a necessity. It's very difficult to monitor hundreds of NT machines at once. Instead, you put all the eggs in one basket, and watch that basket. :-)
I don't think I'd personally want to do a mail store on a Linux machine quite yet. Ext2 is fragile as hell. ReiserFS looks better but I'm only just now going into testing on it. Solaris or SGI with IMAP would be reasonable solutions, but very expensive and the client would lose a lot of the power of a directory system. (even if Active Directory IS 1.0, it's still a hell of a lot better than NT 4 was!)
To give them some of the scripting power, I'm setting up an external Sendmail (or possibly Postfix, haven't decided yet) relay. That way, they can get most of the Unixy scripting power if they need it -- the sendmail transforms can be done at the relay. And they get the nice solid safety of an NTFS information store, which I like a lot. I also trust Sendmail and/or Postfix more than I do Exchange, as far as security is concerned -- opening an Exchange box directly to the Net frightens me. I much prefer the relay idea. But I don't trust Linux/sendmail to keep the information safe once it's delivered, thus NT/Exchange on the backend.
Keep in mind that Linux's issues with filesystem reliability are being remedied, and that Exchange 2000 is relatively unproven at this point, so don't rely on these comments much past March of 2001. By then the picture may be quite different.
But right now, it sure looks like Exchange is one of your better bets for corporate mail.
Ok, and how do you guarantee that what you saw was real and not synthesized and implanted?
Granted it wouldn't be easy to do this, but with that kind of chip implanted how could you EVER be 100% sure that everything you were seeing was real?
Considering how incredibly insecure most software is these days, I think I'll pass on retina implants. I'd sure hate it if my sight depended on keeping up with and patching against the latest exploits.
(and yes this is exaggeration for effect -- but I am about 75% serious here)
I don't know the lines-per-minute I was getting, but a couple years ago when I was last using Delphi heavily, I do know that the build time was never longer than three or four seconds for even a moderately complex project. And I was on a relatively slow machine!
Delphi is the most amazing piece of technology I've seen in Windows. I remain amazed, years later, that it didn't take over the world.
Maybe it will under Linux?
I plan to drop $$$ on this one the instant it ships. I have no argument against paying for good software .. and Delphi is GREAT software. If they can do even 75% as well under Linux as they did under Windows, it'll be worth every penny.
Linux needs this kind of app desperately, and I urge any of you with the financial wherewithal to pay for it as well, if it suits your needs.
For the windows version, $700 was entirely reasonable. The tool is amazing. I consider the $99 version to be an absolute steal.
I know there there is at least one case that addresses this issue. In it, it was determined that the exchange of goods happens as the money changes hands (ie, at the checkout line) and at that point everything you bought is your property and is not subject to search except by a peace officer who has probable cause to believe a crime was committed. (and refusal to allow a search CANNOT BE grounds for a search or the Fourth Amendment goes away.) But I was told verbally about this case by a friend who thinks much the way I do. I have not read it myself, so my assertion should be put in the 'very much unproven' category unless you can do your own research. It's working for me but things may be different where you live!
The other poster in this thread claims that they have the right to search you if you've been in the store before and know about their policy, to which I say 'Balderdash!' I don't give up my rights EVER. Walking into a store doesn't make me subject to search without probable cause no matter what signs they put up. I didn't sign anything. Since it has been proven many times in court that you cannot give away your rights even with your SIGNATURE, how could walking into a store ANYWHERE constitute an agreement to ANYTHING?
Let me put it to you this way: I just say 'no' and walk out. In almost every case they have simply subsided. I believe it must be part of their training: "if a customer refuses to have his/her bags inspected, don't press the issue."
I have gotten crap for this once, from a foreign person who believed he really did have the right to search me. I told him that he didn't and that I was leaving, and did. He didn't chase me.
There have been a couple of other uncomfortable moments -- several staff at one Best Buy exploded out of the store after I left and set up surveillance to see what exactly I put into my car. That was pretty weird, and I was tempted to walk back to them to tell them I knew exactly what they were doing, but I just put my bag (my FULLY PAID FOR bag) in my trunk and drove off. And I have been eyeballed pretty intensely a time or two.
It was quite difficult to do this the first few times, but it gets easier each time. Now I don't CARE what they think or what they do. I'm not a criminal, I didn't do anything even a tiny bit wrong, so they can eye me all they like.
And refusing to submit to search does NOT imply guilt no matter what ANYONE tries to tell you. I don't steal things. I also (politely) refuse to be searched. Just because the other sheeple go along with it doesn't mean I have to.
Stores do not have the right to search you. Say 'no' and leave. I do this all the time -- and I'm entirely honest. I don't steal things, I just refuse to be searched. They can't do a damn thing about it.
:-)
The only stores that CAN search you are ones that make membership contingent on you being searched -- I believe they make you sign forms to get the membership. (I am specifically thinking of Costco.) I am thinking that this may be something you could fight, but it would probably be a big scene.
But in any non-membership retailer, just say no and walk out. You're doing everyone a favor.
Don't give up your rights voluntarily to 'be nice' -- if everyone does that they disappear!
Well, I'd amend that a bit, myself.
:-) Hope they get wildly rich. :-)
Remember MAME? It's a software emulator of very specific hardware characteristics. Now, I don't know just how defined the Amiga architecture is in this new release, but it's certainly possible that you may be able to know clock cycles in this virtual assembly. They're wouldn't be 'real' clock cycles, they would have to be emulated, but for probably 95% of the problem set that's fine.
If you get into needing hard real time, you have to be hand-writing to the bare metal anyway. This virtual assembly wouldn't do the job. This is portable and hard-real time can't really be portable -- you have to recode it to every new hardware environment. This is not TRUE assembly and won't cover all of the bases that the real thing will, but depending on their implementation it could be guaranteed that this demo would always APPEAR TO run at, say, 50fps on any machine that is 'officially supported'. I don't know that this is true, I'm just asserting that it's possible. Again, see MAME.
It's also worth pointing out, as an aside, that this language seems a lot more readable than C.
Looks to me like they could get some pretty good performance out of this beast -- along the lines of C code, but fully portable across any platform that's fast enough.
When I first heard about this new Amiga, it struck me as the stupidest thing I'd ever heard. ("That's not an Amiga, wtf are they thinking??") -- but I'm pretty intrigued by what I'm seeing. Doesn't matter HOW you get where you're going as long as you get there -- and if they can bring the crisp, lightweight, but powerful feel of the Amiga back to modern computing, cool.
Ask /. articles are often a great way to get info but you have to be willing to do some reading and thinking for yourself. Often the best articles are the shortest ones -- they are just links to outside sources.
This article is way inferior to www.r3mix.net. You should go back to that old Ask /. article and figure out why you didn't pick up on that web site. The fact that you didn't come away with an answer from the first article was entirely your own responsibility. All the info you needed was there.
I don't even use Linux as a firewall. It's a great router, but in the v2.2 kernel, the firewalling code is pretty weak. It's stateless; that is, you have no context about a packet. You can't (easily) allow, say, all outgoing traffic on port 80 while refusing it inbound.
:-)
:-) The whole process is just enormously complex and incredibly prone to error.
:-)
You can get around this by filtering on particular combinations of SYN/FIN/RST, but that makes it pretty easy for someone using NMAP to get packets in past your filter.
Personally, I use OpenBSD as my firewall/NAT device. Stateful inspection firewall for free -- gotta love it. I even paid for mine.
There are some nice online pages that will walk you through a series of questions and generate an ipchains ruleset for you. It's a lot better than nothing, and it's a good place to start learning about firewalling, but the process is complex enough that any form of automation is likely to make assumptions you may not like. The Checkpoint Firewall-1 product comes to mind. Out of the box, the 4.0 and 4.1 installations are just dreadfully insecure. It's easy to administer but it's got tons of holes in it. That's my biggest fear about automated rulessets.
But doing it by hand isn't very likely, for most folks. I'd say no more than one person in a thousand is really qualified to be writing firewall rulesets. Hell, I've been learning this stuff for three years and I'm still not sure I'm entirely qualified.
I'm not sure what the answer is here -- TCP/IP requires an extraordinary amount of study in order to be used in s 'safe' way. From a security standpoint, I think the protocol may be essentially useless. You CAN get security but it's so difficult as to be impossible for 99.9% of the public.
I'm struck that maybe it's time to toss out the whole mess and start over -- except in the real world, that NEVER happens. Look at COBOL.
About all that would happen that way is a denial-of-service. Default gateway has to be one hop away. A remote attacker can't specify his own IP address as your gateway, he has to specify another machine on your network. So he can shut you down remotely, but that's about all.
:-)
Now, this attack is useful once he has control of a machine on your network. There are all SORTS of exploits once you have root access to the wire. This is a lot of the reason for the domino effect -- once you lose one machine, your others usually fall over like dominoes because they trust that machine not to be malicious.
Security is a process, not a state. The more secure you think you are, the less secure you tend to be. Andy Grove would love this field -- 'only the paranoid survive'
It would have been really dumb to buy an Amiga instead of a NES if you wanted to play games.
:) ) It cost us $3500 for a machine with 512K and two floppy drives (and $50 for our first box of 10 880K 3.5" disks(!)).
We bought an Amiga 1000 in Christmas of '85. (my parents did actually, I was pretty young back then.
It was a great games machine, but it really didn't get any games worth mentioning for nearly two years after its release. That whole first year I think we had two games to play: "Dr. J and Larry Bird Go One on One", and "Archon". Archon was an incredible version and helped tide us over until the next wave of games showed up, like "Arcticfox" (a game I would probably still play today, if I could find a copy to play under WinUAE.)
Compare that utter paucity of games to a NES, which cost 1/35th as much and had 50 times as many games. I'd say buying the NES made a hell of a lot more sense. Some of the Amiga games were amazing, but so were some of the NES games, and the barrier to entry was a lot lower on the console!
That was 98, and 98 isn't exactly known for reliability. You occasionally hear about machines lasting that long, but it's almost unheard of for systems that are actually doing anything. Yes it was a bug, but it was a bug that didn't matter in practical use for 99.9% of the customer base.
A problem is, however, a problem if people notice it. Linux crashing after three weeks *matters*.
You may not believe you should be held to the standards that Microsoft is held. I agree with you: I think you should be held to a higher standard still.
I also agree with you that knowing exactly how bad the bugs are is a blessing. It IS good for us to know if there are problems with a product. And the fact that we have full control of the technology is also a Good Thing; it's the biggest reason to use a distribution like Red Hat.
Whether you like it or not, however, you are in the business of providing many of the same things that Microsoft provides. The software you ship must work. RedHat 7 dies after three weeks. If Microsoft were to ship code like that they would be drawn and quartered in the press. It would literally cost them billions, both directly in stock price, and indirectly in reputation damage, were they to ship a product in that state.
I don't think it's unreasonable to expect Redhat to not only do as well, but to do BETTER than Microsoft does. You have a whole army of people working for you for free that Microsoft does not. Isn't it your job to make sure that the bugs are ironed out? You're starting with some of the most stable code running anywhere, and assembling that code into a system for general consumption. If QA isn't Job 1 for RedHat, what is?
You have frequently compared RedHat to Heinz ketchup. People can make their own ketchup, but Heinz still sells an awful lot of the stuff, because the consumer has come to expect a consistent, quality product. Well, you have just shipped millions of bottles of ketchup that leak. Admittedly, it's good that we know about the problem, but the bottles still leak. What do you think this would do to Heinz' reputation?
Personally, I am firmly in the Eric Raymond corner of the Free Software world -- what I want is software that doesn't suck. I'm willing to pay for it if I need to. I am a professional system administrator. I need to build systems that run and run and never fall over. The control over the technology is important, but it is a secondary goal for me; having access to the source is good, but FIRST it must work. SECOND the source must be open.
The fact that you open source everything is not an excuse to ship bad software. Open Source garbage is still garbage.