Having both firewalls in the same Enterprise, I have to say that I prefer the Linux one.
Symantec's firewall tries to do too much, IMHO. Firstly, it tries to do a great deal of reporting to make management types happy. Typically, this is the reason it gets bought. Unfortunately, to get this reporting to work right in most enterprises, it is necessary to use the "login" page on the firewall (else you can't track by user, only machine). I have never been able to get it to automagically authenticate to the logged in Windows user, so I get complaints about logins ALL THE TIME! So, often you end up turning off the "transparent proxy" stuff.
Related to the above is a bad idea you must nip in the bud. These batty salespeople will claim they can track how much time employees spend "browsing the web". These firewalls have "sophisticated algorithms" to do this. I've tested it. They are bogus and misleading. We had one guy that had the Weather Channel up all day (the page would refresh every 5 minutes). He showed almost constant browsing even though it was minimized (regrettably we had to prove this to the boss by spying with VNC). Another guy had a systray application installed that polled a website for news information. It showed him as browsing all day. We also had a guy that brought up a game web page and played Java games all day. He showed 5 minutes of browsing when he was playing nonstop for hours. It doesn't work. It doesn't even come close to working. It's a flawed method and your boss is only going to make a fool of himself with it.
Secondly, Squid on Linux does a bang-up job of transparent proxying for HTTP. Seriously. Although I recommend running an opaque proxy (it handles some situations better). Transparent Proxying doesn't save so much work as you'd think.
For anyone with really special needs, Dante makes an excellent SOCKS server (makes ICQ and the like work like a charm--especially when the CEO wants it to just *work*). Squidguard, Dan's Guardian, and the like make an excellent site (and content if necessary) filter. Also, being in the NLANR world cache hierarchy has saved me about 25% of my requests that would have gone directly to a destination.
Thirdly, the Linux machine is much faster, gives better diagnostics, and doesn't require the same resources (in my experience).
Linux has been a VERY good firewall for me. Armed with tools like Snort, Ethereal, and iptables I can generally do about anything.
In the spirit of Slashdot overkill, I'll ramble about our sophisticated home-grown reporting database that blows Symantic Security Center in the weeds. We have a custom SQL database (PostgreSQL) the is fed by a Python script. That Python script associates sites browsed with users. We've used two options for this. Since most of our clients use Windows, we had to find some way to pick up the login names. At first, we used identd. Squid would hit this directly. The drawbacks were that it took time/resources for each request, the daemon could be killed in Win98 and such, and it didn't work outside the squid (although it could have with an iplogger that used ident, but we didn't feel like sucking this out of the syslog). Now, we have the Win2000 domain servers audit to their event log. Go to ntsyslog.sourceforge.net and get the eventlog to syslog logger (damn useful in its own right). Use your favorite syslog daemon (we like syslog-ng but the stock syslog is probably more reliable) to dump the audit data into a file (or a pipe). Now we have python cook the log (via file or pipe) and dump to the database to determine who was logged in to which machine when the request came through. Very slick, works for all protocols, nearly bulletproof. We're even experimenting with tracking machines going wierd (crashing or losing connectivity) by watching for logins without logouts.
If you want something similar, we work at $70/hr.:)
Actually, all true arrays are fixed size. I think you mean a sparse array. About the only useful properties of a vanilla array are constant-time indexing and a fixed footprint. You probably are thinking of the Standard Template Library (STL) implementation of a sparse array. While this is nominally part of the C++ standard now, it is not a silver bullet.
C++ with the STL can still be a pain even if you're careful. Try playing with the STL in large amounts of code. Now try it with no free memory. When you run out of memory, it can get really dicey. Truthfully, it can be very tough to tell when you are allocating memory in C++ (or in what order it happened). Copy constructors can be deceptively well hidden. Same for type conversion functions.
There're always the infamous bugs involving not being able allocate memory to append two string objects to print an error message. That sort of thing is tough to ferret out. I mean, unit testing is one thing but how do you check to see if your program handles running out of RAM well in all situations? Very few languages (or OS's) handle that very gracefully. The hoops that you jump through to correctly through an out-of-memory exception are staggering (pre-allocated RAM, stripped down/in-place string processing, emergency garbage-collection runs, that sort of thing).
I don't disagree that a #define is pretty lame, but you see a lot of this sort of thing and it's not all that bad of a practice. It says:
I acknowledge this is an important problem. This is a stopgap measure. It doesn't solve the problem--it only brings it to light later so that it may be solved appropriately when more fundamental issues have been solved.
I used to think about how call linked lists were because they "never ran out of space" like arrays. Debugging code that failed to allocate new nodes during critical operations changed that.
Since I feel it is relavant, let me relate a little story. I found the same sort of limit awhile back with HylaFAX. You can, nominally, upload a single.tif file of a fax and then use it in any number of fax jobs. Well, it topped out at 32,000 faxes exactly. Turns out, they arbitrarily limited the job number to this. Interestingly, it was a #define and they coded it so I only changed it one place and it worked. Then I found out that Ext2 supports no more than than 32,768 hard links for a single file (hylafax hard links the.tifs to unique filenames for each job). Even ReiserFS limited me similarly (although it was around 64k). Turns out, until Linux has a 64-bit VFS, this will always be a problem. And backwards compatiblity will be a b*tch when that day comes!
Arbitrary limitations like this may be annoying and lame, but they have a very important purpose. They allow you to keep coding on functionality before worrying about scalability. While using a scalable design from the beginning is important, "premature optimization is the root of all evil" (Dr. Knuth).
Five years ago, I would have agreed wholeheartedly. Now, I view this kind of thing to be a fairly good practice. I must be getting old.:(
Python Rocks for Development
on
.NET or CORBA?
·
· Score: 1
Not only is there CORBA support, but it is really good about running everything everywhere.
For this project in particular:
Upsides:
It has UI bindings for Windows, Linux, etc. It has solid platform support. It has OpenGL bindings (although what you expect to use it for is a mystery). It has CORBA bindings. It's fairly platform independent (bytecode). It is strongly serializable. Very Simple but Very Working Threading Development can be rapid as all hell Introspection (more on that later)
Downsides:
Long Term maintainability depends on user discipline. Chances are if Clearcase and WebSphere are "a necessity" for you guys, then you don't have the quality of programmers required to pull of a real programming project and will need "management tools".
--
I use Python extensively due to it's introspection features. Nothing in Python is sacred. Need to create a class that pretends to be a map? A sequence? No problem! What about having special attribute handling (having a function handle attribute hits)? Not an issue.
It can be very powerful. Most of my major server programs actually load to a Python prompt with the real stuff threading in the background. That way I can interrogate/modify the stuff--in realtime. Debugging anyone?
Check out the xmlrpclib module for a taste of the adaptability. That code creates an object. Calling various methods on the object actually translates into HTTP XMLRPC calls. Looking at the code, it is mind-bogglingly concise and simple. The CORBA support is done similarly.
<preamble> RMS makes a lot of people unhappy. They often don't understand him. He's very clever and if the original gcc/binutils and EMACS aren't enough to show his genius (or at least raw cleverness) the GPL should manage. </preamble>
The GPL is nothing more or less than a legal nuke. Seriously, it's all about mutually assured destruction.
EULAs are weapons in big corporations war with each other. They help keep that pesky revenue stream coming (users). They are a method of "control"--a legal leash. They don't have to force you to accept it--they make "good-enough" software, convince you the EULA is harmless, apply peer pressure (everybody does it!), and then let your other needs push you over the precipice.
RMS turned the tables. His EULA (the GPL) is targetted at *their* abuses, not our "abuses". Or rather, it's targeted as an unfair legal tool to maximize *our* gain, not theirs. It is very much a perfectly matched imperfect solution to their imperfect problem. Perfectly matched because if they legally undermine it (like they have everything else), they undermine their own EULAs--Mutually Assured Destruction. Kill us and you kill yourself. It's really a legal Mexican Standoff (lo siento para Mexicanos, no quiero insultarse). Brilliant!
This could be the real test. If they are forced to comply with the license, their whole product would likely become GPL'd (according to its terms). It has nothing to do with Copyright and everything to do with Breach of Contract (OBIANAL).
Compliance would be a b*tch. I suspect some shareholders would sue for the loss of their stock value (their product would really become MORE valuable, but the company would likely tank).
To get back to the analogy, it's the Cold War with the Communists having real solidarity, dedication, and the upper hand with respect to resources (the Open Source community really has unmatched manpower). Socialism succumbed to Democracy for economic reasons. Communism ate the financial infrastructure of the county--partially from the forces of Capitalism. Socialism was not necessarily flawed (nor is it 100% incompatible with Democracy). This time, the Socialists are putting the financial crunch on the Imperialist Pigs (these guys are actually really Imperialist; I liken their economics to Mercantilism) and they just fell into the trap.
NOTE: IANAC. I Am Not A Communist; despite what Larry Niven says (if you want to know, ask).
Everyone can agree that there is a certain amount of embarrassment with some of our decisions in previous decades. One that always gets me is your musical escapades (Lucy in the Sky with Diamonds, anyone?). Obviously you're not alone (notably Leonard Nimoy's Bilbo Baggins song and the like). I guess the question is:
Why? Would you do it again? Would it be different? Do you still get royalties?
Re:Per Transaction Fees Suck...
on
Add-Ons Add Up
·
· Score: 2
Clarification:
Get this, after consulting with my boss, we don't charge a 3% fee for using a VISA. Instead, we mark up everything 3% and give a DISCOUNT for cash and check payments! HA! Don't know if this would matter, as the law has provisions for "looks like an apple, smells like an apple, tastes like and apple--it's an apple". But it certainly gives the lawyers something to talk about (plausable deniability at least: "I *THOUGHT* it was legal!" Although, IANAL).
As for the "fees for clearinghouses"-BS, I don't pay a fee for accessing websites on another backbone? I mean, the entire checking system (MICR Routing and Account numbers) takes place with no fees. Why does a paper check not require any "other bank" fees, but somehow ATM and Credit do. I don't buy it.
Per Transaction Fees Suck...
on
Add-Ons Add Up
·
· Score: 5, Interesting
My boss gets lots of complaints because we pass the 3% credit card charge on directly. Like somehow people who pay with cash or check should subsidize the credit industry.
I hate that sort of thing. It first really hit me when I got an unexpected $1 fee for using an ATM. Not the fee from the ATM's owner--a fee from MY OWN BANK for not using a preferred ATM network! After that I just came unglued (switched banks too).
In the end, I think it's all just part of the game. Most people are so jaded about "the value of service" anymore that the only way to sell something is with the lowest price. A lot of these fees serve no other function than to allow the price to represent the real value of whatever it is you're paying for. No longer do we live in an age where many aspects of the transaction are rolled into an "overhead account". Everything seems to be billed in excruciating detail!
While it largely makes sense, I long for the days when bills were simpler.
I *sooooo* hope the Hans gets off his butt and gets ReiserFS 4 in this one. If you follow the LKML closely (or just read the Kernel Traffic, http://kt.zork.net/kernel-traffic/latest.html) then you may have heard he's sweating a bit on getting it in.
Reiser4 may just revolutionize the way the some people do stuff. I mean, next system I want to be able to do:
I have to agree here. I think people really like Debian for the same reasons people really like the BSDs. It has power *AND* is consistent.
I started on Slackware. Every system seemed to have weird frontends that just insulated you from the real thing. That is one thing that Debian does *NOT* have.
On the other hand, Rock Linux and the like give the same raw access, but their lack of consistency still drives me back to Debian.
It is also nice to generally be able to count on things functioning the way the developer intended them to function (a few crazy applications usually developed at RedHat aside).
I mean, even Interchange (RedHat's e-Commerce solution, used to be Tallyman/Minivend) installs and works find as a Debian archive. Then there's alien... I just don't find myself fighting against the system, I just end up working with it. A lot of distros and other OS vendors miss the mark of having a base system that works well before slapping an interface on it. Debian very rarely feels like the developer was "trying to get it out the door". It's the kind of software that gets developed when there are no deadlines. I like that.
It's consistent, solid, and I have the right mixture of bare metal with finished interface.
I think a lot of these complaints will disappear when Debconf really takes off and a lot of the silly messages disappear.
Why does this crap bother everyone so much? For anyone who cares, try the following science experiment:
Hypothesis: Microsoft software is buggier and less secure than Linux software.
Experiment: Debian 3.0 and Internet Explorer 6 SP1 are recent releases (i.e. good examples of respective software packages). Test each one's security needs by updating each from their respective security archives. The one with the most fixes is the most buggy (this assumes bugs are the norm and fixes indicate their prevalence in the code, history bears this out).
Results: Debian has about 8 updates. IE6 SP1 has about 15 critical updates. The IE updates are five times the size of the Debian ones.
Analysis: IE should have the advantage here. It is only a web browser against an entire distribution. It also was released noticibly later, giving less time to discover bugs.
Conclusion: Hypothesis is supported.
Any other experiments? How about a histogram of bugtraq notices? How about one weighted by severity?
Software is software. It all has bugs. The only way to combat it is good development practices--things like rigor, testing, attention to detail, lots of review, and careful design.
MS has shown (and still shows) that it puts these goals second to political maneuvering, time to market, and (sometimes underhanded) competition.
I damn well will bash a business that is only after my pocketbook (MS) every time they screw up. I also will vehemently defend people developing code for all to use (OSS). Even if they were equally buggy, I'll pick goodwill over greedy corporation any day.
Sorry, but Open Source and Microsoft (a.k.a. good versus evil:) is not Tommy Hilfigger versus Ralph Lauren. If you want to argue fashion go read Cosmo or Vogue. I care about nothing less or more than solving problems with computers in an open, useful, honest, secure way that doesn't make me a corporate whore.
I just wish that "Visual Basic" and the like hadn't convinced a bunch of second rate graphic artists that they were "programmers". There's nothing more disheartening than being surrounded and outnumbered by loud idiots desparate to cling to the greedy corporate teat that enabled them do something other than flip burgers.
Have you ever tried programming for Linux? If the removal of a plugin from XMMS hindered you, you're probably some sort of XMMS hacker. No one touches that code except for XMMS people. Sounds more off-the-hip than a real observation.
I have three big products I often deploy:
1. An LDAP Directory w/ Pretty Frontend 2. A "Windows Printer" That E-mails PDFs 3. An Industrial Remote I/O Controller
All three run happily on Redhat, Debian, SuSE, and even Sorcerer. No tweaking. Standard install materials. Not to mention all of these have package systems (albeit a bit rudimentary for Sorcerer) which makes the above problem little more than whining. I also pose the question "as opposed to what?". If different versions of Windows with varying levels of driver support aren't a moving target, I don't know what is. The only platforms I can think of that guarantees this kind of support stability are Sun, IBM, and maybe Apple.
Since you're a "developer who wants to write applications", where's your example? Which distro removed which precious component that stymied your project?
That's an important point. There *are* cons to Open Source. However, they typically have nothing to do with Open Source software and have everything to do with corporate politics. Those that do have technical problems tend to not be any worse off that commercial programs in the same state of development.
I apologize about this. I somehow managed to completely miss this. Where I operate, a few large phone vendors are extremely misinformative about requirements with respect to VoIP.
The vovida.org stuff appears to be good code. My only beef is that vendors threaten me when I try to use stuff like this. We're considering taking a vendor to court right. They won't support their own keyset units because we have an Asterisk PBX between their phone system and the CO.
As you can imagine, I hesitate to do anything but buy a Cisco controller after this nightmare. The legal fees alone make it worth it.
That being said, I hadn't seen this before. Thank you Cisco.
I hate to say it, but I don't mind this so much. What happens the first time someone registers billyg@microsoft.com? Can we say lawsuit? I think reinforcing the existing naming scheme resolves a lot of headaches about who "owns" a domain. It could be implemented, but I don't think developing a massive directory and major authentication/verification framework (and associated paperwork) is "the answer".
Any identification system needs to be clear. If your e-mail is bob@asdf.com, you can be sure that if your ISP doesn't support Jabber, at least it won't be anyone else impersonating you. Thus the onus is on the ISP, not the protocol, for problems that might arise. If ISPs are responsible for delivering your e-mail, I don't see it to be a big step for IM traffic (and the routing is a heck of a lot more distributed).
If your ISP doesn't support IMs (a few actually blocked ICQ for a while), I don't see it to be any worse than not supporting e-mail. Both are a service to your customer that require modest (per user) computing and bandwidth requirements.
I've used Jabber on and off from the beginning and I can safely agree that the user end is a bit rough.
However, here are the reasons you want it:
XML: Now I'm sure by the time this is posted, there will be tons of "XML is the future, adopt it and DESPAIR" posts, but in this case, it is a clear benefit. Bascially, due to XML, the message format allows trivial extension of the protocol. Really, you can just make up an XML element, stick it in the right place and *poof*.
"Is it really this trivial?", you ask. Well, one of my pet projects was writing a Jabber bot for pen/paper RPGs (think Dungeons and Dragons). It took about six hours and I added a element (use the sides property to specify type of dice) that would message you back with a dice roll. I never completely finished the client, but it worked.
Keep in mind all I did to do this was hack two copies of the command-line client--no server changes whatsoever. The key here is that any Jabber server will pass custom XML--so protocol content changes *DO NOT* require server changes and are completely client implementable. Freedom for the masses, anyone?
The possibility of custom clients is huge. Unfortunately, the ability for large companies (AOL, MSFT) to control the state-of-the-art and to make sure that, despite interacting with all IM clients, theirs offers better proprietary functionality on their network (i.e. everyone can message, but AOL partnered with newgame.com so only AOL users can use IM to launch NewGame netgames).
Transparency: This is a big win. It is always possible to pull apart the protocol. Heck, the protocol is designed to be human-readable. This has the added benefit of making obfuscation really obvious (why is AOL using elements named option1, option2, and option3? What is the nsakey element for?...).
OpenSource: You read Slashdot, you know the pros and cons. The less obvious side of this is how it compares to the corporate offerings--specifically SIP. SIP is great, but try to find a free implementation. If you're using SIP for VoIP (which is pretty much the norm) you probably have had to drop a chunk of change on a nasty Cisco CallManager server.
Loosely Connected: Perhaps the most intelligent Jabber decision was to make it just like e-mail. There's no longer a global hostname, but rather a user@host naming scheme. If you're Internet savvy you can get your e-mail address and jabber address to be the same (exercise left to the reader, think about it).
Existing Gateways: Jabber's weirdest appeal is that it already has gateways to access existing services. The docs have the specifics, but the gateways servers can hit AOL and about everybody else.
Good Standards: Practically all of the corporate offerings are standards that were thrown together (Mirabilis ICQ grew like a Frankenstein's monster, see the procotol specs, they're scary http://www.d.kth.se/~d95-mih/icq/). A ground-up thoughtful implementation like Jabber is a Good Thing(TM) compared to some of the messes.
There are other reasons but I'm tired of typing. You get the idea--Jabber stays crunchy in milk. It's nummy. Get some.
I'm seeing quite a few threads about Americans being "paranoid" about the whole identified by a number thing.
Well, old habits die hard. Look at the courts in any Western country and you'll see influences (and often everyday terms) that are thousands of years old (Rome anyone?).
To be direct, America was founded by Protestants. It may not reflect that today (I'm about as far from Puritan as you can get) the undercurrent still permeates the culture. There's a nasty stigma on pornography, the "Protestant work ethic" is still alive and well, and--due to some passages in Revelations--people object with religious fervor to being identified by a "number of the beast" if you will; even if they don't realise why...
> Full use of your upstream should NOT be > crippling your downstream so much, that's not > how it works. TCP should adjust accordingly. TCP normally piggybacks ACKs. That is, an ACK is sent out on traffic going the other way on the TCP connection. So, if there were only one connection, this isn't a problem.
The problem lies in asymetric TCP sessions (huge data-filled going upstream with virtually data-less ACK packets coming back) over a congested upstream link. When your upstream gets saturated, the ACKs get caught between huge packets from whatever other traffic). Cable and DSL modems, for example, have a huge queue, so it is easy for your entire TCP window of ACKs to be waiting in queue. The lack of ACKs causes the remote end of the stream to pause sending and kills your throughput.
In short, TCP is tuned for lower bandwidth links. Applications like satellite connections (where there is huge bandwidth but huge latency) could really benefit from insanely large windows, but you just don't see it much yet.
I don't know if anyone else noticed this (and not that a different OS would always respond any better), but the Slashdot effect created the "final words" on this subject.
The maximum amount of time for a script to execute was exceeded. You can change this limit by specifying a new value for the property Server.ScriptTimeOut or by changing the value in the IIS administration tools.
I mean, I really don't want to see the GPL thrown out or anything, but it's got to go to court eventually. Then, somehow, the world will change.
I remember reading that the FSF encourages people to license with the specification that newer versions of the GPL will apply. I know lots of people purposefully exclude that out of distrust for the FSF's motives. It would be ironic, albeit sucky, if being able to update the GPL would save a lot of code from badness.
I mean, usually that "future changes apply" clause usually bites people in the butt. It seems about time that it got used for something beneficial.
Has anyone ever considered a sort of "future updates to the GPL apply if a) the author is dead or b) the author files an agreement to update form with the FSF"?
It seems that would protect against fears that the FSF may sell them out in the future. At least then users would be safe unless both the FSF *and* the author wanted to sell out. Seems much less likely.
Also, does the redistribution clause of the GPL apply when it's distributed embedded or just as a software package. If I build a USB widget and distribute the widget running the Linux kernel with scheduler changes to accomodate my widget's real-time foobazzle, does it need to be GPL? Even if it is only allowing my widget to simply run? I don't have a problem with that (I actually kind of like it), but a lot of the less committed to free software would.
The multiple pages per file is the real killer here.
I support a blueprint/reprographics company and that would make/break the acceptance of an application here.
Before MTIFFs (as our Canon copiers call them), we would have 1600 page spec books as 1600 files!!! Very ugly and difficult to manage when you can have six volumes of specs per project, twenty projects per customer, and hundreds of customers.
That being said, perhaps a directory can do it, but I don't think networked filesystems are up to the task of handling that as efficiently yet. I pray for the day when the world supports some happy network fs on top of Reiser5 with a Specbook/PlanSet directory handler...
OpenGL is "ONLY" 2D. Seriously, all of the magic of OpenGL occurs in 2D buffers:
* a color buffer (where all of the display colors are drawn)
* a depth buffer (used to effectively handle most of the "3D" work by magically doing all of the intersections and stuff for us)
* a host of other useful buffers (accumulation buffers, generic buffers that you can do whatever you want to with).
All 3D functions work by drawing the 3D object in 2D in a buffer. All of the 3D magic happens due to the depth buffer (each pixel has it's distance from the camera stored in a depth buffer, thus you magically get hidden face removal, intersection, yada yada yada). Heck, you can even control how the new drawing gets composited into the buffer.
Still, the point is that you have all of the 2D functions you could need (well, between GL and GLU).
If you can find them on the net, SGI has some OpenGL manpages. They are quite useful.
Basically, you get high speed line drawing/filling, accelerated blit operations (including things like XOR, and other weird ones), and you upload pictures by dumping uncompressed RGBA (note the ALPHA channel, this is supremely useful, it's even 8-bit!). For the masochist-optimizer, there are even various types of curve functions (bezier anyone?). All of this makes it a really good GL (graphics library?). Oh, and there is also support (although it's in GLU or maybe even the GLUT) for text (scalable vector and raster!).
Not only is the 2D good, but it looks really cool when you overlay 2D graphics (some with alpha) on top of your 3D . . . but I digress . . .
Mmmmmmmm. I can't find the pages anymore. I found that tidbit in a link off of an old topic on/. (remember when MS was about to release 5.5 with little to no CSS1 and DOM support and the W3C raised hell?). I can't seem to find it anymore. After more thinking, I think it was just the rendering engine, and they may have slid it in a Service Pack (SP1?).
You can find a few articles around the web about IE 5.5 for Mac doing it right, but I can't find the explicit reference to the codebase being ported.
Well, there are 3 options: 1) I'm wrong (very possible) 2) I heard it on the Internet so it must be true (see #1) 3) The Microsoft Censorship Conspiracy (possible, but paranoid) 4) It really happened that way.
Pick the one you like, but that's what my memory recalls.
It does not take a rocket scientist to see why MS is doing this.
1. MS releases example code under contract that excludes most competitors. 2. This gives MS grounds for a lawsuit against anyone who implements an interoperable product -- regardless of merit. 3. MS abuses this to use the legal system to drain opposition funds.
I do not question MS's right to choose a license for anything. I do, however, assert that there is not really any other compelling reasoning behind this.
If a MS rep were to testify to this in court, MS would get nailed. Seriously, filing meritless lawsuits as a financial gambit (really, does anyone think there is any other reason for this?) is the height of contempt of court at the least and full scale barratry at worst--and it's a *crime*!
Furthermore, MS is a convicted monopoly--which makes the quashing competition part also very much illegal.
In short, MS is violating the law, has violated the law, and shows no regard for it as anything but a financial tool.
Now, think of it this way, corporations are given equivalent rights to people, but there are no equivalent punishments. There is no death penalty or even "life in prison".
MS needs either a corporate death penalty or a corporate "life in prison".
Finally, whilst I rant, let me address all of the people that say "we can't nail MS because of the economy". Let me remind you that a court shows no mercy to a murderer or theif because they're important. How many of you that say MS should deserve special treatment because of it's "central importance to business" were outraged when President Clinton was extended massive immunity and priviledge during the Lewinsky scandal? In short, MS is the powerful official, and you know what the industry has been sucking for the last 15 years. Law is law--and flagrant violations deserve strict punishments. No exceptions.
Not that I want the Windows source (you can keep it), but don't tell me opening Windows will destabilize "standards" either. Show me the massive destandardization that open source has caused. Look, standards are key to computing being viable. If corporations are allowed to force a standard to be vendor-limiting, then competition is impossible. Preventing that is at the heart of anti-trust law.
Slashdot Mirror
Having both firewalls in the same Enterprise, I have to say that I prefer the Linux one.
:)
Symantec's firewall tries to do too much, IMHO. Firstly, it tries to do a great deal of reporting to make management types happy. Typically, this is the reason it gets bought. Unfortunately, to get this reporting to work right in most enterprises, it is necessary to use the "login" page on the firewall (else you can't track by user, only machine). I have never been able to get it to automagically authenticate to the logged in Windows user, so I get complaints about logins ALL THE TIME! So, often you end up turning off the "transparent proxy" stuff.
Related to the above is a bad idea you must nip in the bud. These batty salespeople will claim they can track how much time employees spend "browsing the web". These firewalls have "sophisticated algorithms" to do this. I've tested it. They are bogus and misleading. We had one guy that had the Weather Channel up all day (the page would refresh every 5 minutes). He showed almost constant browsing even though it was minimized (regrettably we had to prove this to the boss by spying with VNC). Another guy had a systray application installed that polled a website for news information. It showed him as browsing all day. We also had a guy that brought up a game web page and played Java games all day. He showed 5 minutes of browsing when he was playing nonstop for hours. It doesn't work. It doesn't even come close to working. It's a flawed method and your boss is only going to make a fool of himself with it.
Secondly, Squid on Linux does a bang-up job of transparent proxying for HTTP. Seriously. Although I recommend running an opaque proxy (it handles some situations better). Transparent Proxying doesn't save so much work as you'd think.
For anyone with really special needs, Dante makes an excellent SOCKS server (makes ICQ and the like work like a charm--especially when the CEO wants it to just *work*). Squidguard, Dan's Guardian, and the like make an excellent site (and content if necessary) filter. Also, being in the NLANR world cache hierarchy has saved me about 25% of my requests that would have gone directly to a destination.
Thirdly, the Linux machine is much faster, gives better diagnostics, and doesn't require the same resources (in my experience).
Linux has been a VERY good firewall for me. Armed with tools like Snort, Ethereal, and iptables I can generally do about anything.
In the spirit of Slashdot overkill, I'll ramble about our sophisticated home-grown reporting database that blows Symantic Security Center in the weeds. We have a custom SQL database (PostgreSQL) the is fed by a Python script. That Python script associates sites browsed with users. We've used two options for this. Since most of our clients use Windows, we had to find some way to pick up the login names. At first, we used identd. Squid would hit this directly. The drawbacks were that it took time/resources for each request, the daemon could be killed in Win98 and such, and it didn't work outside the squid (although it could have with an iplogger that used ident, but we didn't feel like sucking this out of the syslog). Now, we have the Win2000 domain servers audit to their event log. Go to ntsyslog.sourceforge.net and get the eventlog to syslog logger (damn useful in its own right). Use your favorite syslog daemon (we like syslog-ng but the stock syslog is probably more reliable) to dump the audit data into a file (or a pipe). Now we have python cook the log (via file or pipe) and dump to the database to determine who was logged in to which machine when the request came through. Very slick, works for all protocols, nearly bulletproof. We're even experimenting with tracking machines going wierd (crashing or losing connectivity) by watching for logins without logouts.
If you want something similar, we work at $70/hr.
Actually, all true arrays are fixed size. I think you mean a sparse array. About the only useful properties of a vanilla array are constant-time indexing and a fixed footprint. You probably are thinking of the Standard Template Library (STL) implementation of a sparse array. While this is nominally part of the C++ standard now, it is not a silver bullet.
.tif file of a fax and then use it in any number of fax jobs. Well, it topped out at 32,000 faxes exactly. Turns out, they arbitrarily limited the job number to this. Interestingly, it was a #define and they coded it so I only changed it one place and it worked. Then I found out that Ext2 supports no more than than 32,768 hard links for a single file (hylafax hard links the .tifs to unique filenames for each job). Even ReiserFS limited me similarly (although it was around 64k). Turns out, until Linux has a 64-bit VFS, this will always be a problem. And backwards compatiblity will be a b*tch when that day comes!
:(
C++ with the STL can still be a pain even if you're careful. Try playing with the STL in large amounts of code. Now try it with no free memory. When you run out of memory, it can get really dicey. Truthfully, it can be very tough to tell when you are allocating memory in C++ (or in what order it happened). Copy constructors can be deceptively well hidden. Same for type conversion functions.
There're always the infamous bugs involving not being able allocate memory to append two string objects to print an error message. That sort of thing is tough to ferret out. I mean, unit testing is one thing but how do you check to see if your program handles running out of RAM well in all situations? Very few languages (or OS's) handle that very gracefully. The hoops that you jump through to correctly through an out-of-memory exception are staggering (pre-allocated RAM, stripped down/in-place string processing, emergency garbage-collection runs, that sort of thing).
I don't disagree that a #define is pretty lame, but you see a lot of this sort of thing and it's not all that bad of a practice. It says:
I acknowledge this is an important problem. This is a stopgap measure. It doesn't solve the problem--it only brings it to light later so that it may be solved appropriately when more fundamental issues have been solved.
I used to think about how call linked lists were because they "never ran out of space" like arrays. Debugging code that failed to allocate new nodes during critical operations changed that.
Since I feel it is relavant, let me relate a little story. I found the same sort of limit awhile back with HylaFAX. You can, nominally, upload a single
Arbitrary limitations like this may be annoying and lame, but they have a very important purpose. They allow you to keep coding on functionality before worrying about scalability. While using a scalable design from the beginning is important, "premature optimization is the root of all evil" (Dr. Knuth).
Five years ago, I would have agreed wholeheartedly. Now, I view this kind of thing to be a fairly good practice. I must be getting old.
Not only is there CORBA support, but it is really good about running everything everywhere.
For this project in particular:
Upsides:
It has UI bindings for Windows, Linux, etc.
It has solid platform support.
It has OpenGL bindings (although what you expect to use it for is a mystery).
It has CORBA bindings.
It's fairly platform independent (bytecode).
It is strongly serializable.
Very Simple but Very Working Threading
Development can be rapid as all hell
Introspection (more on that later)
Downsides:
Long Term maintainability depends on user discipline. Chances are if Clearcase and WebSphere are "a necessity" for you guys, then you don't have the quality of programmers required to pull of a real programming project and will need "management tools".
--
I use Python extensively due to it's introspection features. Nothing in Python is sacred. Need to create a class that pretends to be a map? A sequence? No problem! What about having special attribute handling (having a function handle attribute hits)? Not an issue.
It can be very powerful. Most of my major server programs actually load to a Python prompt with the real stuff threading in the background. That way I can interrogate/modify the stuff--in realtime. Debugging anyone?
Check out the xmlrpclib module for a taste of the adaptability. That code creates an object. Calling various methods on the object actually translates into HTTP XMLRPC calls. Looking at the code, it is mind-bogglingly concise and simple. The CORBA support is done similarly.
I love that language.
I mean the following very seriously.
<preamble>
RMS makes a lot of people unhappy. They often don't understand him. He's very clever and if the original gcc/binutils and EMACS aren't enough to show his genius (or at least raw cleverness) the GPL should manage.
</preamble>
The GPL is nothing more or less than a legal nuke. Seriously, it's all about mutually assured destruction.
EULAs are weapons in big corporations war with each other. They help keep that pesky revenue stream coming (users). They are a method of "control"--a legal leash. They don't have to force you to accept it--they make "good-enough" software, convince you the EULA is harmless, apply peer pressure (everybody does it!), and then let your other needs push you over the precipice.
RMS turned the tables. His EULA (the GPL) is targetted at *their* abuses, not our "abuses". Or rather, it's targeted as an unfair legal tool to maximize *our* gain, not theirs. It is very much a perfectly matched imperfect solution to their imperfect problem. Perfectly matched because if they legally undermine it (like they have everything else), they undermine their own EULAs--Mutually Assured Destruction. Kill us and you kill yourself. It's really a legal Mexican Standoff (lo siento para Mexicanos, no quiero insultarse). Brilliant!
This could be the real test. If they are forced to comply with the license, their whole product would likely become GPL'd (according to its terms). It has nothing to do with Copyright and everything to do with Breach of Contract (OBIANAL).
Compliance would be a b*tch. I suspect some shareholders would sue for the loss of their stock value (their product would really become MORE valuable, but the company would likely tank).
To get back to the analogy, it's the Cold War with the Communists having real solidarity, dedication, and the upper hand with respect to resources (the Open Source community really has unmatched manpower). Socialism succumbed to Democracy for economic reasons. Communism ate the financial infrastructure of the county--partially from the forces of Capitalism. Socialism was not necessarily flawed (nor is it 100% incompatible with Democracy). This time, the Socialists are putting the financial crunch on the Imperialist Pigs (these guys are actually really Imperialist; I liken their economics to Mercantilism) and they just fell into the trap.
NOTE: IANAC. I Am Not A Communist; despite what Larry Niven says (if you want to know, ask).
Everyone can agree that there is a certain amount of embarrassment with some of our decisions in previous decades. One that always gets me is your musical escapades (Lucy in the Sky with Diamonds, anyone?). Obviously you're not alone (notably Leonard Nimoy's Bilbo Baggins song and the like). I guess the question is:
Why? Would you do it again? Would it be different? Do you still get royalties?
Clarification:
Get this, after consulting with my boss, we don't charge a 3% fee for using a VISA. Instead, we mark up everything 3% and give a DISCOUNT for cash and check payments! HA! Don't know if this would matter, as the law has provisions for "looks like an apple, smells like an apple, tastes like and apple--it's an apple". But it certainly gives the lawyers something to talk about (plausable deniability at least: "I *THOUGHT* it was legal!" Although, IANAL).
As for the "fees for clearinghouses"-BS, I don't pay a fee for accessing websites on another backbone? I mean, the entire checking system (MICR Routing and Account numbers) takes place with no fees. Why does a paper check not require any "other bank" fees, but somehow ATM and Credit do. I don't buy it.
My boss gets lots of complaints because we pass the 3% credit card charge on directly. Like somehow people who pay with cash or check should subsidize the credit industry.
I hate that sort of thing. It first really hit me when I got an unexpected $1 fee for using an ATM. Not the fee from the ATM's owner--a fee from MY OWN BANK for not using a preferred ATM network! After that I just came unglued (switched banks too).
In the end, I think it's all just part of the game. Most people are so jaded about "the value of service" anymore that the only way to sell something is with the lowest price. A lot of these fees serve no other function than to allow the price to represent the real value of whatever it is you're paying for. No longer do we live in an age where many aspects of the transaction are rolled into an "overhead account". Everything seems to be billed in excruciating detail!
While it largely makes sense, I long for the days when bills were simpler.
Well, perhaps that was a bit mis-stated.
He's supposedly in the first major "cleaning-up" stage with basic stability already reasonably taken care of.
That being said, I think Hans has always been pretty good about limiting what he tries to do to small bite-size chunks, so I don't worry too much.
I *sooooo* hope the Hans gets off his butt and gets ReiserFS 4 in this one. If you follow the LKML closely (or just read the Kernel Traffic, http://kt.zork.net/kernel-traffic/latest.html) then you may have heard he's sweating a bit on getting it in.
Reiser4 may just revolutionize the way the some people do stuff. I mean, next system I want to be able to do:
All that *and* have transactional data commits with a very small performance hit!
(ReiserFS Trolls: Go ahead, bring it on!)
I have to agree here. I think people really like Debian for the same reasons people really like the BSDs. It has power *AND* is consistent.
I started on Slackware. Every system seemed to have weird frontends that just insulated you from the real thing. That is one thing that Debian does *NOT* have.
On the other hand, Rock Linux and the like give the same raw access, but their lack of consistency still drives me back to Debian.
It is also nice to generally be able to count on things functioning the way the developer intended them to function (a few crazy applications usually developed at RedHat aside).
I mean, even Interchange (RedHat's e-Commerce solution, used to be Tallyman/Minivend) installs and works find as a Debian archive. Then there's alien... I just don't find myself fighting against the system, I just end up working with it. A lot of distros and other OS vendors miss the mark of having a base system that works well before slapping an interface on it. Debian very rarely feels like the developer was "trying to get it out the door". It's the kind of software that gets developed when there are no deadlines. I like that.
It's consistent, solid, and I have the right mixture of bare metal with finished interface.
I think a lot of these complaints will disappear when Debconf really takes off and a lot of the silly messages disappear.
Why does this crap bother everyone so much? For anyone who cares, try the following science experiment:
:) is not Tommy Hilfigger versus Ralph Lauren. If you want to argue fashion go read Cosmo or Vogue. I care about nothing less or more than solving problems with computers in an open, useful, honest, secure way that doesn't make me a corporate whore.
Hypothesis: Microsoft software is buggier and less secure than Linux software.
Experiment: Debian 3.0 and Internet Explorer 6 SP1 are recent releases (i.e. good examples of respective software packages). Test each one's security needs by updating each from their respective security archives. The one with the most fixes is the most buggy (this assumes bugs are the norm and fixes indicate their prevalence in the code, history bears this out).
Results: Debian has about 8 updates. IE6 SP1 has about 15 critical updates. The IE updates are five times the size of the Debian ones.
Analysis: IE should have the advantage here. It is only a web browser against an entire distribution. It also was released noticibly later, giving less time to discover bugs.
Conclusion: Hypothesis is supported.
Any other experiments?
How about a histogram of bugtraq notices? How about one weighted by severity?
Software is software. It all has bugs. The only way to combat it is good development practices--things like rigor, testing, attention to detail, lots of review, and careful design.
MS has shown (and still shows) that it puts these goals second to political maneuvering, time to market, and (sometimes underhanded) competition.
I damn well will bash a business that is only after my pocketbook (MS) every time they screw up. I also will vehemently defend people developing code for all to use (OSS). Even if they were equally buggy, I'll pick goodwill over greedy corporation any day.
Sorry, but Open Source and Microsoft (a.k.a. good versus evil
I just wish that "Visual Basic" and the like hadn't convinced a bunch of second rate graphic artists that they were "programmers". There's nothing more disheartening than being surrounded and outnumbered by loud idiots desparate to cling to the greedy corporate teat that enabled them do something other than flip burgers.
Have you ever tried programming for Linux? If the removal of a plugin from XMMS hindered you, you're probably some sort of XMMS hacker. No one touches that code except for XMMS people. Sounds more off-the-hip than a real observation.
I have three big products I often deploy:
1. An LDAP Directory w/ Pretty Frontend
2. A "Windows Printer" That E-mails PDFs
3. An Industrial Remote I/O Controller
All three run happily on Redhat, Debian, SuSE, and even Sorcerer. No tweaking. Standard install materials. Not to mention all of these have package systems (albeit a bit rudimentary for Sorcerer) which makes the above problem little more than whining. I also pose the question "as opposed to what?". If different versions of Windows with varying levels of driver support aren't a moving target, I don't know what is. The only platforms I can think of that guarantees this kind of support stability are Sun, IBM, and maybe Apple.
Since you're a "developer who wants to write applications", where's your example? Which distro removed which precious component that stymied your project?
That's an important point. There *are* cons to Open Source. However, they typically have nothing to do with Open Source software and have everything to do with corporate politics. Those that do have technical problems tend to not be any worse off that commercial programs in the same state of development.
I apologize about this. I somehow managed to completely miss this. Where I operate, a few large phone vendors are extremely misinformative about requirements with respect to VoIP.
The vovida.org stuff appears to be good code. My only beef is that vendors threaten me when I try to use stuff like this. We're considering taking a vendor to court right. They won't support their own keyset units because we have an Asterisk PBX between their phone system and the CO.
As you can imagine, I hesitate to do anything but buy a Cisco controller after this nightmare. The legal fees alone make it worth it.
That being said, I hadn't seen this before. Thank you Cisco.
-K
I hate to say it, but I don't mind this so much. What happens the first time someone registers billyg@microsoft.com? Can we say lawsuit? I think reinforcing the existing naming scheme resolves a lot of headaches about who "owns" a domain. It could be implemented, but I don't think developing a massive directory and major authentication/verification framework (and associated paperwork) is "the answer".
Any identification system needs to be clear. If your e-mail is bob@asdf.com, you can be sure that if your ISP doesn't support Jabber, at least it won't be anyone else impersonating you. Thus the onus is on the ISP, not the protocol, for problems that might arise. If ISPs are responsible for delivering your e-mail, I don't see it to be a big step for IM traffic (and the routing is a heck of a lot more distributed).
If your ISP doesn't support IMs (a few actually blocked ICQ for a while), I don't see it to be any worse than not supporting e-mail. Both are a service to your customer that require modest (per user) computing and bandwidth requirements.
I've used Jabber on and off from the beginning and I can safely agree that the user end is a bit rough.
...).
However, here are the reasons you want it:
XML: Now I'm sure by the time this is posted, there will be tons of "XML is the future, adopt it and DESPAIR" posts, but in this case, it is a clear benefit. Bascially, due to XML, the message format allows trivial extension of the protocol. Really, you can just make up an XML element, stick it in the right place and *poof*.
"Is it really this trivial?", you ask. Well, one of my pet projects was writing a Jabber bot for pen/paper RPGs (think Dungeons and Dragons). It took about six hours and I added a element (use the sides property to specify type of dice) that would message you back with a dice roll. I never completely finished the client, but it worked.
Keep in mind all I did to do this was hack two copies of the command-line client--no server changes whatsoever. The key here is that any Jabber server will pass custom XML--so protocol content changes *DO NOT* require server changes and are completely client implementable. Freedom for the masses, anyone?
The possibility of custom clients is huge. Unfortunately, the ability for large companies (AOL, MSFT) to control the state-of-the-art and to make sure that, despite interacting with all IM clients, theirs offers better proprietary functionality on their network (i.e. everyone can message, but AOL partnered with newgame.com so only AOL users can use IM to launch NewGame netgames).
Transparency: This is a big win. It is always possible to pull apart the protocol. Heck, the protocol is designed to be human-readable. This has the added benefit of making obfuscation really obvious (why is AOL using elements named option1, option2, and option3? What is the nsakey element for?
OpenSource: You read Slashdot, you know the pros and cons. The less obvious side of this is how it compares to the corporate offerings--specifically SIP. SIP is great, but try to find a free implementation. If you're using SIP for VoIP (which is pretty much the norm) you probably have had to drop a chunk of change on a nasty Cisco CallManager server.
Loosely Connected: Perhaps the most intelligent Jabber decision was to make it just like e-mail. There's no longer a global hostname, but rather a user@host naming scheme. If you're Internet savvy you can get your e-mail address and jabber address to be the same (exercise left to the reader, think about it).
Existing Gateways: Jabber's weirdest appeal is that it already has gateways to access existing services. The docs have the specifics, but the gateways servers can hit AOL and about everybody else.
Good Standards: Practically all of the corporate offerings are standards that were thrown together (Mirabilis ICQ grew like a Frankenstein's monster, see the procotol specs, they're scary http://www.d.kth.se/~d95-mih/icq/). A ground-up thoughtful implementation like Jabber is a Good Thing(TM) compared to some of the messes.
There are other reasons but I'm tired of typing. You get the idea--Jabber stays crunchy in milk. It's nummy. Get some.
I'm seeing quite a few threads about Americans being "paranoid" about the whole identified by a number thing.
Well, old habits die hard. Look at the courts in any Western country and you'll see influences (and often everyday terms) that are thousands of years old (Rome anyone?).
To be direct, America was founded by Protestants. It may not reflect that today (I'm about as far from Puritan as you can get) the undercurrent still permeates the culture. There's a nasty stigma on pornography, the "Protestant work ethic" is still alive and well, and--due to some passages in Revelations--people object with religious fervor to being identified by a "number of the beast" if you will; even if they don't realise why...
> Full use of your upstream should NOT be
> crippling your downstream so much, that's not
> how it works. TCP should adjust accordingly.
TCP normally piggybacks ACKs. That is, an ACK is sent out on traffic going the other way on the TCP connection. So, if there were only one connection, this isn't a problem.
The problem lies in asymetric TCP sessions (huge data-filled going upstream with virtually data-less ACK packets coming back) over a congested upstream link. When your upstream gets saturated, the ACKs get caught between huge packets from whatever other traffic). Cable and DSL modems, for example, have a huge queue, so it is easy for your entire TCP window of ACKs to be waiting in queue. The lack of ACKs causes the remote end of the stream to pause sending and kills your throughput.
In short, TCP is tuned for lower bandwidth links. Applications like satellite connections (where there is huge bandwidth but huge latency) could really benefit from insanely large windows, but you just don't see it much yet.
I don't know if anyone else noticed this (and not that a different OS would always respond any better), but the Slashdot effect created the "final words" on this subject.
/sections/News/breakingnews.asp
Following the text of the article was:
error 'ASP 0113'
Script timed out
The maximum amount of time for a script to execute was exceeded. You can change this limit by specifying a new value for the property Server.ScriptTimeOut or by changing the value in the IIS administration tools.
I'd say go for it.
I mean, I really don't want to see the GPL thrown out or anything, but it's got to go to court eventually. Then, somehow, the world will change.
I remember reading that the FSF encourages people to license with the specification that newer versions of the GPL will apply. I know lots of people purposefully exclude that out of distrust for the FSF's motives. It would be ironic, albeit sucky, if being able to update the GPL would save a lot of code from badness.
I mean, usually that "future changes apply" clause usually bites people in the butt. It seems about time that it got used for something beneficial.
Has anyone ever considered a sort of "future updates to the GPL apply if a) the author is dead or b) the author files an agreement to update form with the FSF"?
It seems that would protect against fears that the FSF may sell them out in the future. At least then users would be safe unless both the FSF *and* the author wanted to sell out. Seems much less likely.
Also, does the redistribution clause of the GPL apply when it's distributed embedded or just as a software package. If I build a USB widget and distribute the widget running the Linux kernel with scheduler changes to accomodate my widget's real-time foobazzle, does it need to be GPL? Even if it is only allowing my widget to simply run? I don't have a problem with that (I actually kind of like it), but a lot of the less committed to free software would.
The multiple pages per file is the real killer here.
I support a blueprint/reprographics company and that would make/break the acceptance of an application here.
Before MTIFFs (as our Canon copiers call them), we would have 1600 page spec books as 1600 files!!! Very ugly and difficult to manage when you can have six volumes of specs per project, twenty projects per customer, and hundreds of customers.
That being said, perhaps a directory can do it, but I don't think networked filesystems are up to the task of handling that as efficiently yet. I pray for the day when the world supports some happy network fs on top of Reiser5 with a Specbook/PlanSet directory handler...
When disposal is properly handled, nuclear gives the best energy per environmental impact per dollar.
Even with that, it doesn't have a huge lifetime (a few generations?) due to limited quantities of uranium.
And before you brush me aside over the disposal issue, think about the yearly environmental impact of improperly disposed motor oil and the like.
Face it, disposal of nuclear waste, even if it leaks, is hardly Chernobyl. How many bad radition leaks have there been? How may bad oil spills?
I'll be the first to embrace fusion when it gets here, but for now, the nuclear track record looks good enough for me.
Not designed for 2D? VGL maybe.
OpenGL is "ONLY" 2D. Seriously, all of the magic of OpenGL occurs in 2D buffers:
* a color buffer (where all of the display colors are drawn)
* a depth buffer (used to effectively handle most of the "3D" work by magically doing all of the intersections and stuff for us)
* a host of other useful buffers (accumulation buffers, generic buffers that you can do whatever you want to with).
All 3D functions work by drawing the 3D object in 2D in a buffer. All of the 3D magic happens due to the depth buffer (each pixel has it's distance from the camera stored in a depth buffer, thus you magically get hidden face removal, intersection, yada yada yada). Heck, you can even control how the new drawing gets composited into the buffer.
Still, the point is that you have all of the 2D functions you could need (well, between GL and GLU).
If you can find them on the net, SGI has some OpenGL manpages. They are quite useful.
Basically, you get high speed line drawing/filling, accelerated blit operations (including things like XOR, and other weird ones), and you upload pictures by dumping uncompressed RGBA (note the ALPHA channel, this is supremely useful, it's even 8-bit!). For the masochist-optimizer, there are even various types of curve functions (bezier anyone?). All of this makes it a really good GL (graphics library?). Oh, and there is also support (although it's in GLU or maybe even the GLUT) for text (scalable vector and raster!).
Not only is the 2D good, but it looks really cool when you overlay 2D graphics (some with alpha) on top of your 3D . . . but I digress . . .
Mmmmmmmm. I can't find the pages anymore. I found that tidbit in a link off of an old topic on /. (remember when MS was about to release 5.5 with little to no CSS1 and DOM support and the W3C raised hell?). I can't seem to find it anymore. After more thinking, I think it was just the rendering engine, and they may have slid it in a Service Pack (SP1?).
You can find a few articles around the web about IE 5.5 for Mac doing it right, but I can't find the explicit reference to the codebase being ported.
Well, there are 3 options:
1) I'm wrong (very possible)
2) I heard it on the Internet so it must be true (see #1)
3) The Microsoft Censorship Conspiracy (possible, but paranoid)
4) It really happened that way.
Pick the one you like, but that's what my memory recalls.
Let's make this a bit simpler:
It does not take a rocket scientist to see why MS is doing this.
1. MS releases example code under contract that excludes most competitors.
2. This gives MS grounds for a lawsuit against anyone who implements an interoperable product -- regardless of merit.
3. MS abuses this to use the legal system to drain opposition funds.
I do not question MS's right to choose a license for anything.
I do, however, assert that there is not really any other compelling reasoning behind this.
If a MS rep were to testify to this in court, MS would get nailed. Seriously, filing meritless lawsuits as a financial gambit (really, does anyone think there is any other reason for this?) is the height of contempt of court at the least and full scale barratry at worst--and it's a *crime*!
Furthermore, MS is a convicted monopoly--which makes the quashing competition part also very much illegal.
In short, MS is violating the law, has violated the law, and shows no regard for it as anything but a financial tool.
Now, think of it this way, corporations are given equivalent rights to people, but there are no equivalent punishments. There is no death penalty or even "life in prison".
MS needs either a corporate death penalty or a corporate "life in prison".
Finally, whilst I rant, let me address all of the people that say "we can't nail MS because of the economy". Let me remind you that a court shows no mercy to a murderer or theif because they're important. How many of you that say MS should deserve special treatment because of it's "central importance to business" were outraged when President Clinton was extended massive immunity and priviledge during the Lewinsky scandal? In short, MS is the powerful official, and you know what the industry has been sucking for the last 15 years. Law is law--and flagrant violations deserve strict punishments. No exceptions.
Not that I want the Windows source (you can keep it), but don't tell me opening Windows will destabilize "standards" either. Show me the massive destandardization that open source has caused. Look, standards are key to computing being viable. If corporations are allowed to force a standard to be vendor-limiting, then competition is impossible. Preventing that is at the heart of anti-trust law.