Again, the purpose of IETF is to create standards, not to fight evil corporate types on the behalf of Slashdotters. Getting involved with litigation is a good way to make enemies and would likely undermine the needed industry support and participation for the stanards to carry any weight in the real world.
Better, imho, for them to route around the problem like the net does w/ censorship. Leave the legal battles to someone who specialize in it, since that sort of activity would not compromise their primary mission.
(Otherwise I can't think of any good reason they don't take thesee people to court.)
I can. IETF doesn't have monetery assets and is an engineering task force, not a legal one.
Eg.,
Participating in the efforts of the IETF
The IETF is not a membership organization (no cards, no dues, no secret handshakes:-)
The IETF is a large open international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet
architecture and the smooth operation of the Internet. It is open to any interested individual.
Anyway, it's not that the IETF would be legally prevented from recommending this as a standard because of the patent. It would just put anyone implementing that standard at risk of patent fees or litigation.
Interesting - I had never submitted a link to Altavista personally to see how the whole process works. After seeing your description of the GIF mechanism, I've tried it and see what you mean.
Apparently this is an attempt at foiling script-based ping and if down, submit as dead type attacks on other people's entries.
I think a more reasonable way of handling this would be to, eg., check the site for 2 days in 12 hour increments (to allow for, eg., eBay's Sunday maintenance Windows and such). If no positive response during that period then drop the link.
In any case, I was only using that mechanism as an example of a saner way than having 100 votes to automatically mark a site as dead. I don't personally use Altavista's search engine or condone it, and how this mechanism could be linked to a browser button (which could work with Altavista if they used my method instead of requireing a multi-submit + enter text from a GIF reporting process)
Sounds like a good title for a trivial patent, even..
Method of verifying URL availabity for a database of URL's
"What if a user falsely claims a site to be dead?"
Well, what if it took 100 different IPs to claiming it to be dead before it really was considered dead?
Actually, it is trivial to maliciously get 100 IP's to claim a site to be dead. All you need is a page that gets 100 hits/day and an IMG tag embedding the URL to the dead link reporting page w/ the target URL embedded. Whoever hits the page will unwittingly make a request to mark your target dead from their own IP. Or, script kiddies could create botnets for the purpose of submitting dead links to get high-profile sites delinked, etc.
The correct way to handle this situation is how the search engines already do - when a link is reported dead, they just make a request to the link. If it generates an HTTP 404 response code, or the site is down, it's marked actually dead.
I'm not convinced this is always a good idea, though - I've worked for a guy who would battle for top positioning on the search engine with a few competitors. When either of them noticed that the other's site was down, they'd submit the other site as a dead link. I like google's Cached page mechanism, which allows you to view sites that are currently unreachable. Great for when you need docs from a site which happens to be down at the time.
How about a button in browsers that enables you to mark a page as a dead link?
Of course, you'd need to use this technique with a search engine who takes dead link submissions. Eg., Altavista and its "Add or Remove a Page" link here: http://web.altavista.com/cgi-bin/query?pg=addurl
It's commonly used for books which are released both in print and on a free basis on-line, eg.,
Linux Administration Made Easy, and all the content at Linux.Com.
If you want a truly solid Free Unix for Alpha, I suggest NetBSD. I've been using it there for a couple years after finding that Linux was a bit too rough for my tastes for a production machine. It has been a good couple years for that alpha.:)
Apparently you missed the first half of the show.;) The CueCat scanners were reverse engineered which means they can be used for personal barcode scanning uses (not involving Digital Convergence). The business model was: give "free" barcode scanning hardware to radio shack customers and magazine buyers, and make the money back from advertisers with the on-line service. With the hardware reverse-engineered, this turned what they were doing into: Give out lots of free hardware to use as you will.
Anyway, Digital Convergence tried suing people who ran websites hosting drivers and software for the CueCat claiming IP violations, which led to a great deal of ill will toward them. On top of it all, their site was cracked, and customer information was leaked.
People can already choose between Pocket Windoze and Linux. We could make Linux a stronger choice, or we could make the two Unices be weaker choices.
I just don't understand *BSD*. No part of it.
There was a time when Linus was billing Linux as "probably only ever going to run on x86". With this in mind, why would the BSD developers want to abandon their cross-platform base for something intended to be x86-only? Why would we want them to?
Further, a big advantage of NetBSD (_especially_ on non-x86) is that it's maintained such that commonly shareable parts (eg, device drivers) are coded in a cross-platform manner. Each port has an individual responsible for it, who makes sure that the platform-specific stuff gets into CVS for that port. Once that occurs, future releases of NetBSD have the code already integrated. The alternative with Linux? Maintain a seperate source tree, and get the joy of needing to fold in updates upon each new kernel release. Maybe if your political skills are good enough and you jump through the right hoops, you can get your changes and additions integrated into the upstream release. Maybe not.
The point is - duplication of effort of maintaining a seperate tree of Linux is undertaken for many non-x86 platforms. From what I can tell, there is much less duplication of effort resulting from applying these efforts to a single, unified tree in NetBSD.
In my personal experience (on Alpha), the Linux distribution support was dodgy. NetBSD, on the other hand, is solid. It really shows that the Alpha port is a first-class citizen. Needless to say, I am very pleased with NetBSD's handling of cross-platform releases.
The reaon we need more than one free Unix is that we have different ideas of what's important. Linux wants to focus on x86 (and possibly on transmeta), and being able support every filesystem and PCI card known to man on that platform. FreeBSD aims to be a hardcore x86 server OS (and has succeeded, IMHO). NetBSD wants to run (and run well) on every platform under the sun. OpenBSD wants security w/o compromise. Who gets to decide which group is wrong, and who decides what the One True Way is?
Btw, I'm not knocking Linux - I use Linux Mandrake on my workstation and love it. I use NetBSD, OpenBSD and FreeBSD on servers and love them too. Each has its own strengths, and I am quite happy to have luxury of applying them accordingly.
We had our gun rights restricted because a lot of us wanted it to be that way.
Unlike the United States, we see little need to "bear arms" as individuals - and the history of our country is one of reasonable peace and stability.
Hmm, just like most people have little need for source code as individuals? I wonder if there's any correlation between the rise in violent crime in the UK since they banned guns, and the relative buginess of Windows vs. FreeBSD...
The first amendment doesn't deal with forcing people to publish something or to provide connectivity to your website. What it does do is restrict government so that it doesn't prevent people from doing those things.
What I, and the author of this article were referring to were specifically government interference with people and organiziations who do want to share information.
The Internet sells itself as, and in fact is, so very much more than a mere entertainment or news medium: it is also a research library, a marketplace, and a schoolroom. Given these additional roles, there is no reason to maintain that the Internet is entitled to the same First Amendment protection as print or even radio and television.
The Internet should therefore cease to be governed by such undeniably loose rules and instead be overseen by an agency that would more closely resemble the FCC but have even broader power, specifically the power of prior restraint.
It therefore requires unprecedented attempts to assure the veracity of the content it purveys and to protect those who use it. And if that means suspending full First Amendment protection from the Internet, so be it.
The power of prior restraint he speaks of essentially means that the government can choose to review each document that goes on-line, and prevent posting "because it said so" (I'm the mommy, that's why).
It should be fairly obvious after the parade of censorware blocks on legitimate sites, that any organization who gets that type of power will immediately procede to misuse it. And, were the net not protected by the first amendment, there would be no real way of defending against such things.
The odd thing is that the author appears to view the net as a read-only medium controlled by a few corporate interests. This is especially absurd considering TV and radio, being limited by the small number of channels available are necessarily controlled by corporate interests, while the Net is the great equalizer.
If I recall correctly, the reason for "balanced reporting" requirements and "operating in the public interest" broadcasters are helded were put in place for the very reason of limited bandwidth and corporate monopoly over what is transmitted on said bandwidth.
1)Windows apps on Linux means that Linux apps
are not developed. People don't use Linux,
because the native performance of these apps in
Windows if of course superior. Wine leads to a
catch 22 situation.
Regarding preventing the development of Linux apps, there is evidence to the contrary. For instance, Word Perfect has been ported to Linux, yet the Free office projects are stronger than ever. Also, Wine is supporting more Windows games than ever. Meanwhile, Loki keeps cranking out native ports.
Regarding performance, there is no reason why Windows would perform inherently better. Wine Is Not an Emulator. It is a native unix implementation of the Windows API's, which basically amounts to a set of libraries and a glorified linker.
2) WINE means that software developers don't need to worry about porting their apps to Linux at all.
Winelib means that initial porting can be as simple as a recompile.
3) WINE reenforces the Windows blinders, if anything. The users are never escaping from the Windows environment at all. How is this good for Linux?
Users are ecaping from their Windows environment. If I use 99 applications on my Linux box which are native to Linux, and 1 that is native to windows, I'd say I've successfully escaped the Windows environment. Legacy support does not mean you're trapped in the legacy environment. On the contrary, it's a powerful tool to free you of that environment while not losing access to a specific application.
Historically, lack of applications, or lack of one specific application on Linux has been a major obstacle preventing people from becoming full-time Linux users. Once Wine can reliably run most Windows applications, the barrier against change becomes much smaller. And, as the user becomes more familiar with Linux, apps mature and are ported, the legacy Windows applications used under Wine can be phased out.
5. USAGE RESTRICTIONS
LICENSEE may not modify, adapt, translate, reverse engineer, decompile, or disassemble the Licensed Software. LICENSEE may not create derivative works of the Licensed Software with the exception of the right granted in Paragraph 3 herein to modify the sample source code. LICENSEE may not defeat, or attempt to defeat, the licensing mechanism in the Licensed Software which restricts use of the Licensed Software with a single merchant account number, nor may LICENSEE use the Licensed Software with more than one merchant account number.
Now, who needs to write "freedom & personal responsibility good, serfdom & tyrannical control bad" on the blackboard?
For a good corporate-suported Free UNIX on sparc, NetBSD + Wasabi Systems http://www.wasabisystems.com/ would seem to fit the bill. I've always had much better results on non-x86 hardware with NetBSD, too. It Just Works [tm] instead of being a constant uphill battle because most kernel coders, distro maintainers, etc. don't use that hardware.
Actually, Solaris doesn't have/dev/random or/dev/urandom
You can use methods such as egd.pl (as described and linked for download at http://www.lothar.com/tech/crypto/) to gather entropy for random seeds and a third party/dev/random device driver such as the one at http://www.cosy.sbg.ac.at/~andi/ though. Also, OpenSSH has its own internal method of gathering entropy - such as running netstat and viewing the ps table.
You're not *that* dependent on the OS for randomness, it just takes a bit more work if you start with a hobbled one.
I had to make 3 servers, and I just got online and searched around and got the parts. Made sure the SCSI controllers worked with FreeBSD (We are a FreeBSD shop). Looked around a few places, got some killer deals on good hardware and found a couple places that I could recommend to others.
I recently set up 3 servers for a free unix shop. One of them got OpenBSD, and two others FreeBSD. All three of those machines were bought on my recommentation from ASLab, and with an external RAID unit built by Enhance Technologies. I went on to buy my own rackmount system (for NetBSD) from ASLab as well.
The reason for doing this -
To build even those 4 machines, quite a few components are involved. Sometimes components don't work when they're delivered, and sometimes troubleshooting exactly which component is at fault can be a lengthy process. Having a hardware vendor build it weeds out all the DOA and defective components up front.
When choosing hardware and getting the latest and greatest of everything, sometimes components will have compatibility issues. Since the vendors specialize in hardware and do burn-in testing, they typically can give you good insight as to what combinations to avoid and will let you know if something isn't working how it should.
Not everyone is familiar with all aspects of building a system properly. For instance, I may be able to pick excellent motherboards, hard-drives and SCSI controllers, but I may not be aware of the subtleties involved with proper cooling for the system. When a vendor by default uses all the components I would have chosen anyway, it builds confidence that they'll do a good job on subtle issues I'm not so familiar with.
I'm personally more interested in working with the software side of a server. Slotting, cabling and such are necessities to get to that point, but not something I really enjoy doing.
The systems I mentioned are all Athlon rackmounts. At the time (I haven't checked recently), I was unable to locate any rackmount cases with Athlon-compliant power supplies. The vendor was able to build to this specification.
In this case, tech support and blame shifting are not part of the equation at all. It's just a matter of effectively using finite time and getting the best system I can out in production. I did build my home system from components from a several different on-line vendors, though.:)
Of course, in all cases, I specified the parts to be used, and all of my requirements were met with the exception of ASLab and I disagreeing on which vendor's RAM should be used for the NetBSD box. They were nice enough to ship it with everything but the RAM, though, which I ordered from Mushkin and dropped in without issue.
Why are people buying prebuild crap from companies that treat them like crap.
Presumably because they think they'll get all the advantages I listed. Or the PHB's are calling the shots.;)
I would still demote or fire someone who bought a bad product or built a crappy server.
Shit happens. Picking one bad product doesn't make an incompetent. Of course, unveiling the new mission critical database server on a brand new Packard Bell may be an exception.;)
ASLab ships Mandrake by default. I've bought several systems from them, and all have performed nicely and have been running solidly. I can't comment on their tech support, since I've never needed it.
Some other good points of ASLab is that they'll also build systems (including rackmount) with Athlon CPU's, which, along with price, was a critical factor in my choosing them.
Check them out at http://www.aslab.com if these are the sorts of things you're interested in.:)
I'm not a firewall expert, but, the basic idea is that IPFilter can be configured to only allow packets in from the outside if they're in response to a previously made connection request from the internal network (or part of the resulting session)
Packet state filtering can be used for any TCP flow to short-cut later filtering. The "short-cuts" are kept in a table, with no alterations to the packet filter list made. Subsequent packets, if a matching packet is found in the table, are not passed through the list. For TCP flows, the filter will follow the ack/sequence numbers of packets and only allow packets through which fall inside the correct window.
# # Keep state for all outgoing telnet connections # and disallow all other TCP traffic. # pass out on le1 proto tcp from any to any port = telnet keep state block out on le1 all
For UDP packets, packet exchanges are effectively stateless. However, if a packet is first sent out from a given port, a reply is usually expected in answer, in the `reverse' direction.
# # allow UDP replies back from name servers # pass out on le1 proto udp from any to any port = domain keep state
Held UDP state is timed out, as is TCP state for entries added which do not have the SYN flag set. If an entry is created with the SYN flag set, any subsequent matching packet which doesn't have this flag set (ie a SYN-ACK) will cause it to be "timeless" (actually, the timeout defaults to 5 days), until either a FIN or RST is seen.
This sort of thing is also possible using the ipfw facility in FreeBSD:
# Allow TCP through if setup succeeded $fwcmd add pass tcp from any to any established
# Allow setup of incoming email $fwcmd add pass tcp from any to ${ip} 25 setup
# Allow setup of outgoing TCP connections only $fwcmd add pass tcp from ${ip} to any setup
# Disallow setup of all other TCP connections $fwcmd add deny tcp from any to any setup
Regarding Linux, it can kind of do that sort of thing currently, but only if you use IP Masquerading in conjunction with your firewalling. The idea there is that the only way to get a TCP packet past your Masquerading proxy is for it to be in response to a packet generated from inside your network. Of course, since you'd be doing many-to-one NAT in that scenario, the usual complications apply eg., since there is only 1 externally visible IP, you can't choose to allow specific incoming ports for multiple clients.
From what I understand, netfilter, which will be available in a stable release as of Linux 2.4.x, will make a more elegant method of doing this possible.
That's what the perl module Penguin does. You can find it on any CPAN mirror in the modules/by-module/Penguin directory. Eg., at ftp.freesoftwar e.com in the/pub/perl/CPAN/modules/by-module/Penguin/ directory. Here's a snippet of the FAQ in its tarball explaning how it works:
'Saaaay, what _is_ the design of Penguin?'
Glad you asked.
Consider two machines, foo and bar. A user on foo (or perhaps a program on foo) wishes to execute a program on machine bar. However, imagine that the people running bar don't want just anyone running code on their machine for security reasons. This is the normal case on the Internet, and one which the World Wide Web attempts to emulate with HTTP and CGI.
Normally, there is no well-known channel for foo to transmit code to bar. Further, there is no provision for the code to undergo verification after transmission. Too, there is no well-defined way for bar to ensure that foo's code does not attempt to perform insecure or damaging operations.
Penguin attempts to solve these issues while making sure the code language maintains some acceptable degree of sufficiency and power. Using Penguin, the user/program on foo 'digitally signs' the code that's earmarked for delivery to bar. The signature encodes the code in such a way that it is impossible to alter the code or deny that the signer signed it.
The code is then wrapped up into a packet and transmitted through a 'channel' to a Penguin process running on machine bar. The channel's protocol layer is abstracted away enough that it becomes unimportant; Penguin code can just as easily be delivered through SMTP or AOL Mail as through TCP/IP, DECNet, AppleTalk, whatever.
The Penguin process on bar unwraps the packet, which contains further verification and checksum information, and then 'digitally unsigns' the code, a process which provides the code in 'clear' form while telling the receiver who digitally signed it.
The receiver then cross-references the signer's identity with a list of rights that the receiver associates with the signer, reverting to a set of default rights if the signer is unknown or unlisted.
A safe compartment is then created, populated with the functions allowed to the signer, and told to limit the operations it can perform to only those permitted to the signer.
The code is then compiled within that safe compartment. If it attempts to do something which the signer is not allowed to do, or if it attempts to call a function not permitted to the signer, the compartment immediately traps the operation and throws the code away before it can execute. If the code uses no unsafe or illegal operations, then it executes and produces a result.
The code executing side then becomes the master in the transaction, and can send code to the original sender, send the return value back in a data packet, and so forth. The process repeats as necessary until both parties are done; the channel then closes, and the Penguin transaction is complete. The basic sentiment behind the idea of 'identity' being correlated to 'rights' in the receiver is that in signing the code, the signer commits her identity and her reputation on the correct operation of the code. 'highly trustable' signers (as one might imagine Larry Wall, Randal Schwartz, and Tom Christiansen to be) might be assigned very high levels of trust and equivalent degrees of 'rights', so that programs they sign can perform very complex and interesting operations on your computer. By the same token, paranoid sites or those wishing isolation could assign zero rights to everyone except for a select (perhaps internal) few.
Part of the 'rights' given to signers include possibly specialized functions that encapsulate the functionality of extremely dangerous operations. For instance, a store opening up on the Internet might put up a Penguin server which put functions called 'list_items' and 'buy_item()' into the limited compartments all users get. 'list_items' might open up a file on the store's machine, read the contents, and spit them out -- an operation which, if allowed in the general case, would clearly breach security. However, by creating a specialized function, the security concern is removed, and by letting potential customers know of the function, the power and ease of use are kept high.
Niggling but important technical issues currently being wrestled with include the way that foreign functions are registered into the namespace, the construction of a foreign function framework so that the names and function of the functions are well-known, and a superior-than-current 'digital signature' method.
During the December quarter 1999, Cobalt established several strategic relationships including NTT DoCoMo, France Telecom and Gateway. The company began shipments of products to Gateway, which Gateway is marketing under the name Gateway Microserver.
So, the processor would appear to be SGI MIPS-based. StrongArm is 32-bit (and what Netwinders use)
Re:You can get these for MySQL.
on
Why Not MySQL?
·
· Score: 2
Nothing like good old-fashioned IRC support: "My database is down, my company is going down the drain, the users can't work, what do I do!?!?!?" Typical IRC reply: "Go fsck yourself".
And you think you'll get better support on IRC for a proprietary database? Were it Oracle instead of mySQL in question, I think the statement you mentioned would be followed by several minutes of hearty belly-laughing.
If you want to be sure that you'll get an answer to your support request, you pay for it, just like with a proprietary app.
Mandrake's primary strong point is that they seriously push the envelope when it comes to "Real User" stuff. The linked download instructions to 7.1 provide some details of what's in 7.1 -
Some highlights:
If Windows is also on the computer, DrakFont gives the user access to his Windows fonts under Linux.
Enhanced USB support for modems, printers, Zip drives
i810 based video cards now supported
ATA 66 (UDMA 66) interface
For professional environments, now shipping ReiserFS, a new journalized file system
All Helix Code GNOME improvements incorporated
Some of the stuff in the previous version (7.0), was framebuffer support, SuperMount (which automatically mounts removable media), security levels (eg., 4 & 5 default to no externally accessible services - you have to turn them on yourself), and DiskDrake, which allows you to resize fat/fat32 partitions at install time (and is FREE!).
They've always been pentium-compiled and have always had a strong focus on shipping with a slick KDE desktop. They also appear to have more solid releases than Red Hat, and release often, so you can run stable-but-recent (as opposed to Debian, where you've got a years-old stable release system or recent unstable system).
Slashdot Mirror
Again, the purpose of IETF is to create standards, not to fight evil corporate types on the behalf of Slashdotters. Getting involved with litigation is a good way to make enemies and would likely undermine the needed industry support and participation for the stanards to carry any weight in the real world.
Better, imho, for them to route around the problem like the net does w/ censorship. Leave the legal battles to someone who specialize in it, since that sort of activity would not compromise their primary mission.
Eg.,
Participating in the efforts of the IETF The IETF is not a membership organization (no cards, no dues, no secret handshakes :-)
The IETF is a large open international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet
architecture and the smooth operation of the Internet. It is open to any interested individual.
Anyway, it's not that the IETF would be legally prevented from recommending this as a standard because of the patent. It would just put anyone implementing that standard at risk of patent fees or litigation.
Apparently this is an attempt at foiling script-based ping and if down, submit as dead type attacks on other people's entries.
I think a more reasonable way of handling this would be to, eg., check the site for 2 days in 12 hour increments (to allow for, eg., eBay's Sunday maintenance Windows and such). If no positive response during that period then drop the link.
In any case, I was only using that mechanism as an example of a saner way than having 100 votes to automatically mark a site as dead. I don't personally use Altavista's search engine or condone it, and how this mechanism could be linked to a browser button (which could work with Altavista if they used my method instead of requireing a multi-submit + enter text from a GIF reporting process)
Sounds like a good title for a trivial patent, even..
Method of verifying URL availabity for a database of URL's
The correct way to handle this situation is how the search engines already do - when a link is reported dead, they just make a request to the link. If it generates an HTTP 404 response code, or the site is down, it's marked actually dead.
I'm not convinced this is always a good idea, though - I've worked for a guy who would battle for top positioning on the search engine with a few competitors. When either of them noticed that the other's site was down, they'd submit the other site as a dead link. I like google's Cached page mechanism, which allows you to view sites that are currently unreachable. Great for when you need docs from a site which happens to be down at the time.
This is actually trivial to implement, as shown in Google's toolbar page: http://www.google.com/options/toolbar.htmlOf course, you'd need to use this technique with a search engine who takes dead link submissions. Eg., Altavista and its "Add or Remove a Page" link here: http://web.altavista.com/cgi-bin/query?pg=addurl
http://nicse.hlrz.kfa-juelich.de/~cbest/postdoc.ht ml
There are also legends about how TSO sure is hard to use, but it's slow...
That was one of the concerns which lead to the creation of the Open Content License back in 1998:
http://www.opencontent.org/opl.shtml
It's commonly used for books which are released both in print and on a free basis on-line, eg., Linux Administration Made Easy, and all the content at Linux.Com.
If you want a truly solid Free Unix for Alpha, I suggest NetBSD. I've been using it there for a couple years after finding that Linux was a bit too rough for my tastes for a production machine. It has been a good couple years for that alpha. :)
Anyway, Digital Convergence tried suing people who ran websites hosting drivers and software for the CueCat claiming IP violations, which led to a great deal of ill will toward them. On top of it all, their site was cracked, and customer information was leaked.
About.Com covers both here: http://it.about.com/compute/it/library/weekly/aa09 2300a.htm
There was a time when Linus was billing Linux as "probably only ever going to run on x86". With this in mind, why would the BSD developers want to abandon their cross-platform base for something intended to be x86-only? Why would we want them to?
Further, a big advantage of NetBSD (_especially_ on non-x86) is that it's maintained such that commonly shareable parts (eg, device drivers) are coded in a cross-platform manner. Each port has an individual responsible for it, who makes sure that the platform-specific stuff gets into CVS for that port. Once that occurs, future releases of NetBSD have the code already integrated. The alternative with Linux? Maintain a seperate source tree, and get the joy of needing to fold in updates upon each new kernel release. Maybe if your political skills are good enough and you jump through the right hoops, you can get your changes and additions integrated into the upstream release. Maybe not.
The point is - duplication of effort of maintaining a seperate tree of Linux is undertaken for many non-x86 platforms. From what I can tell, there is much less duplication of effort resulting from applying these efforts to a single, unified tree in NetBSD.
In my personal experience (on Alpha), the Linux distribution support was dodgy. NetBSD, on the other hand, is solid. It really shows that the Alpha port is a first-class citizen. Needless to say, I am very pleased with NetBSD's handling of cross-platform releases.
The reaon we need more than one free Unix is that we have different ideas of what's important. Linux wants to focus on x86 (and possibly on transmeta), and being able support every filesystem and PCI card known to man on that platform. FreeBSD aims to be a hardcore x86 server OS (and has succeeded, IMHO). NetBSD wants to run (and run well) on every platform under the sun. OpenBSD wants security w/o compromise. Who gets to decide which group is wrong, and who decides what the One True Way is?
Btw, I'm not knocking Linux - I use Linux Mandrake on my workstation and love it. I use NetBSD, OpenBSD and FreeBSD on servers and love them too. Each has its own strengths, and I am quite happy to have luxury of applying them accordingly.
That's not what the US Supreme court says in their decision to strike down the CDA: http://www.eff.org/pub/Legal/Cases/EFF_ACLU_v_DoJ/ 19970626_cda.decision
The first amendment doesn't deal with forcing people to publish something or to provide connectivity to your website. What it does do is restrict government so that it doesn't prevent people from doing those things.
What I, and the author of this article were referring to were specifically government interference with people and organiziations who do want to share information.
The power of prior restraint he speaks of essentially means that the government can choose to review each document that goes on-line, and prevent posting "because it said so" (I'm the mommy, that's why).
It should be fairly obvious after the parade of censorware blocks on legitimate sites, that any organization who gets that type of power will immediately procede to misuse it. And, were the net not protected by the first amendment, there would be no real way of defending against such things.
The odd thing is that the author appears to view the net as a read-only medium controlled by a few corporate interests. This is especially absurd considering TV and radio, being limited by the small number of channels available are necessarily controlled by corporate interests, while the Net is the great equalizer.
If I recall correctly, the reason for "balanced reporting" requirements and "operating in the public interest" broadcasters are helded were put in place for the very reason of limited bandwidth and corporate monopoly over what is transmitted on said bandwidth.
The default install of Gnome Chess on my laptop running Linux Mandrake 7.2 works fine playing against the computer, even from KDE. :)
Regarding preventing the development of Linux apps, there is evidence to the contrary. For instance, Word Perfect has been ported to Linux, yet the Free office projects are stronger than ever. Also, Wine is supporting more Windows games than ever. Meanwhile, Loki keeps cranking out native ports.
Regarding performance, there is no reason why Windows would perform inherently better. Wine Is Not an Emulator. It is a native unix implementation of the Windows API's, which basically amounts to a set of libraries and a glorified linker.
Winelib means that initial porting can be as simple as a recompile.
Users are ecaping from their Windows environment. If I use 99 applications on my Linux box which are native to Linux, and 1 that is native to windows, I'd say I've successfully escaped the Windows environment. Legacy support does not mean you're trapped in the legacy environment. On the contrary, it's a powerful tool to free you of that environment while not losing access to a specific application.Historically, lack of applications, or lack of one specific application on Linux has been a major obstacle preventing people from becoming full-time Linux users. Once Wine can reliably run most Windows applications, the barrier against change becomes much smaller. And, as the user becomes more familiar with Linux, apps mature and are ported, the legacy Windows applications used under Wine can be phased out.
Even more amusing, IMHO, is a patent it lists in its references:
Browser having automatic URL generation
For a good corporate-suported Free UNIX on sparc, NetBSD + Wasabi Systems http://www.wasabisystems.com/ would seem to fit the bill. I've always had much better results on non-x86 hardware with NetBSD, too. It Just Works [tm] instead of being a constant uphill battle because most kernel coders, distro maintainers, etc. don't use that hardware.
You can use methods such as egd.pl (as described and linked for download at http://www.lothar.com/tech/crypto/) to gather entropy for random seeds and a third party /dev/random device driver such as the one at http://www.cosy.sbg.ac.at/~andi/ though. Also, OpenSSH has its own internal method of gathering entropy - such as running netstat and viewing the ps table.
You're not *that* dependent on the OS for randomness, it just takes a bit more work if you start with a hobbled one.
The reason for doing this -
In this case, tech support and blame shifting are not part of the equation at all. It's just a matter of effectively using finite time and getting the best system I can out in production. I did build my home system from components from a several different on-line vendors, though. :)
Of course, in all cases, I specified the parts to be used, and all of my requirements were met with the exception of ASLab and I disagreeing on which vendor's RAM should be used for the NetBSD box. They were nice enough to ship it with everything but the RAM, though, which I ordered from Mushkin and dropped in without issue.
Presumably because they think they'll get all the advantages I listed. Or the PHB's are calling the shots.Some other good points of ASLab is that they'll also build systems (including rackmount) with Athlon CPU's, which, along with price, was a critical factor in my choosing them.
Check them out at http://www.aslab.com if these are the sorts of things you're interested in. :)
From the IP Filter site here:
This sort of thing is also possible using the ipfw facility in FreeBSD:
Regarding Linux, it can kind of do that sort of thing currently, but only if you use IP Masquerading in conjunction with your firewalling. The idea there is that the only way to get a TCP packet past your Masquerading proxy is for it to be in response to a packet generated from inside your network. Of course, since you'd be doing many-to-one NAT in that scenario, the usual complications apply eg., since there is only 1 externally visible IP, you can't choose to allow specific incoming ports for multiple clients.
From what I understand, netfilter, which will be available in a stable release as of Linux 2.4.x, will make a more elegant method of doing this possible.
So, the processor would appear to be SGI MIPS-based. StrongArm is 32-bit (and what Netwinders use)
If you want to be sure that you'll get an answer to your support request, you pay for it, just like with a proprietary app.
For mySQL, from the source:
https://www.mysql.com/license.htmy
Or, from a consultant:
http://mysql.com/consultants_search.htmy
And, similarly, for PostgreSQL:
http://www.pgsql.com/support.html
Of course, expecting good results on any business-critical system without a backup & recovery plan or competent staff is a bit naive, anyway.
Some highlights:
Some of the stuff in the previous version (7.0), was framebuffer support, SuperMount (which automatically mounts removable media), security levels (eg., 4 & 5 default to no externally accessible services - you have to turn them on yourself), and DiskDrake, which allows you to resize fat/fat32 partitions at install time (and is FREE!).
They've always been pentium-compiled and have always had a strong focus on shipping with a slick KDE desktop. They also appear to have more solid releases than Red Hat, and release often, so you can run stable-but-recent (as opposed to Debian, where you've got a years-old stable release system or recent unstable system).
There's a good article at LWN - http://lwn.net/2000/features/Linux Mandrake.phtml and, of course, information all over Linux Mandrake's website. ;)