You are correct in that Hydrogen is the only fuel that lets out water vapor as its only by-product. Any other fuel has carbon dioxide (and possibly carbon monoxide) as byproducts. Insert Global Warming debate here. I don't think at these levels you'd have to worry much about the ice caps.
The main problem is that hydrogen has a very low energy/mass ratio. The only way to get anything even close to a decent range is to have massively compressed hydrogen. This in itself is a hazard. If you see a fuel cell in a car, look at how much cladding they have on that hydrogen tank. You're not going to have that kind of hydrogen tank shielding on something meant to be portable. Methanol is the simplest chemical that is liquid (and therefore relatively dense) at room temperature that they can use in a fuel cell.
The other big problem is hydrogen is very reactive - read explosive. Probably not a good idea to have explosives on your laptop.
Also, its easier for you to refuel methanol than to refuel hydrogen. There's no hydrogen infrastructure. Not much of a methanol one either, but you probably could get methanol if you looked for it.
2) methanol is a poison. Low levels of methanol will permanently blind you. At higher levels, you'd be dead. "Denatured" alcohol is ethanol ("normal" drinkable, get drunk on alcohol) with very low levels of methanol. It's used in industrial processes. There's not enough methanol to screw up most reactions that require ethanol, but enough methanol to make it poisonous to drink so people wont use it as a way of avoiding government taxation.
IIRC, the DreamCast was actually OS-less. It had enough firmware to boot from the CD. The development kit that could actually talk to the hardware was only ported to WinCE, and one other platform (netBSD I'm reaching for, but not sure) so essentially you were locked into booting your DreamCast into WinCE or the other platform (again, think it was NetBSD).
> Why couldn't you before? I use text email in > Outlook just fine. It even highlights URLs for me > in text mode which I find nice . Maybe you don't?
Outlook HTML mail has two forms, coming and going. Going is the least evil, coming is the big problem.
Going out, you may have places that won't appreciate HTML email. You may have to turn it off, run through some dialogues to make it permanent, maybe even go to your contact list and say "no HTML ever to this guy/group".
Worse is it coming in. Though HTML mail in general can be bad (HTML spam with webbugs, see who opened it up) a scriptable HTML email client is truly scary. Since Outlook renders things with IE web components, you've just pretty much inherited all IE bugs. "Hey, lets allow random unknown and untraceable people send other people scripts that will run on their computer". That was initially, soon enough they plugged some of the holes, but instead of realizing that the basic idea was flawed (allowing an email to execute things remotely) they decided to have a list that limited what people could do. The problem with such lists is there may be things that got left off. Sure enough, some components were marked "safe for scripting" that shouldn't have. One of these was a component that allowed file system access. Hmm, so an email could run some VBscript, script a component, and erase files on your hard drive. The Good Times virus becomes real. The only reason these bugs never caused widespread panic was that there were much easier ways to achieve the same damage. Why bother climb up to the second floor and break a window when the front door is unlocked and open.
HTML email is just bad. There are a lot of holes. There are privacy requirements and security requirements for email that go above whats required for general web browsing. Trying to close the holes after is hard.
I think you think "baroque instruction encoding" is some official term. It's just Linus' explanation for the BS of x86 instructions and how they seem to be laid out. The way the registers are segmented, and (if I remember, it's been years since any x86 assembler) you have upper byte of the lower word, lower byte of the lower word, and the upper word, because it went from a 16 bit chip to a 32 bit chip. 680x0s were 32 bit registers from day 1, just the address bus wasn't 32 bit initially (24 bit only, but 32 bit address registers). Some x86 instructions only can be used on certain registers (because of space and money constraints on implementing them gloabally in the original 8086 days). Anything you can do in D1 on a 680x0, you can do with D5. Anything you can do with A0, you can do with A6, though you probably don't want to do it with A7 (stack pointer). The 680x0 is a very orthogonal chip, with very few special cases. The x86 is riddled with them.
Citibank allows a 4, 5, or 6 digit PIN. Some networks (most international ones) can't handle anything but 4. Maybe you could get two accounts, one for home, with a 6 digit PIN, and one with 4 digits for international travel, where its a real restriction. Check with your bank.
I think Exchange servers already allow this, we run exchange here at my job (shudder) and I recall "Message has been recalled" notices. So you're going from one Outlook/Exchange proprietary toolset to another Outlook/Exchange toolset - shouldn't affect those guys at all.
Altavista started off (kind of like Yahoo, and Google itself in a way) as a happy accident. They wanted a way to showcase Alpha technology, so they created http://altavista.digital.com. They'd spider the web, and since Alphas were the premiere 64 bit chip, they'd show off "hey we have the Internet indexed on a single server with a single system image". But what was essentially advertising, became useful. Just as a lot of things lucked into, they never really guessed that the search engine would become a profit center, and it exploded in popularity. The old owner of the domain altavista.com (forgot what they did) got massive traffic when people would hear "Altavista" and just typed it in to the browser, and Netscape would do the http://www. and the.com bookends. Eventually Digital saw the site as more than just an ad for Alpha chips and made it a product itself, including selling the code for internal indexing and all that. They bought the altavista.com domain for a hefty fee, and now the site is there. I forgot how the whole Compaq purchase fits into the timeline. Eventually Digital/Compaq realized they were horrible at making money from it, and sold it to CMGI, I forgot who has it now. It's been dying a slow death, though babelfish translations are kinda fun.
At one time they were the best search engine, and their boolean searches - though with a clunky interface - gave the best filtering. Now google can claim that, even though they don't have the same degree of control of boolean searches. No one really has had an idea of what altavista should be, from DEC using it as an ad, then trying to "productize and monetize" it (to use buzzwords I hated from my dot.com dayze) to selling it to CMGI and have ad revenue and popups try to prop it up, to "I'm not sure what they're doing now but pretty sure they don't either."
CGI is pretty much the oldest method of a web server interacting with outside code, and is kind of the only standard way. The server fork/exec's a process and has the CGI process' stdin, stdout, and stderr are pointing back to the server. The web server passes information either through environment variables (for a GET request) or additionally through the process' stdin (for POST and PUT requests). Advantages: very clean, the process goes away after the request, so resource leaks aren't a problem. Very simple interaction, if your programming language understands stdin, stdout, and environment variables (hard to find one that doesn't) you can do CGI with it (though some are better than others obviously). Disadvantages: fork/exec for every request. That has some overhead, sometimes more important is that the process can't use persistent state. Resources have to be acquired on every request. Anything with a great deal of overhead, say opening a database connection, has a HUGE impact on the server.
FastCGI is a pseudo-standard in that it has multiple people implementing it, but it never got approved by, say, the IETF. It's a client server kind of thing, where the first instantiation starts the server up and initializes it. Subsequent requests get sent to the CGI server and get returned. The CGI server never goes away. The cool thing is that there are no startup costs, and you can keep something like a DB pool. Never really used it, so can't comment much.
Some things just get embedded into the server, like Apache modules. You can write C code and it becomes part of the server itself. Advantages: wicked fast. Full access to anything in the server. Disadvantages: if your CGI has a problem, it can bring down your server. The API's can be pretty arcane. Also, it's a different API for each web server (NSAPI vs. ISAPI vs....) and even between variants (it's wildly different from Apache 1.3 and apache 2.0).
mod_perl is kind of like above, it's a perl interpreter bound into Apache. Gives a perl interface to pretty much everything apache has to offer. Not only requests, but configurations. Advantages: perl is very flexible, can do a lot of things and use perl modules from CPAN, including templating systems and the such. You're also insulated a bit from stray pointers and such. mod_perl also precompiles all of the perl code, so you don't have the compiler overhead on every request. Disadvantages: mod_perl can be huge sometimes, and if you have several mod_perl instances running around, you can eat memory pretty quick.
Everything else is kind of "do what you want". Tomcat itself has several protocols to talk to Apache; some are just old, some are supported on certain platforms only, yadda yadda.
That said, the article did confuse a bunch of things, CGI, C, and content management systems. He was pushing an agenda, hopoing that people couldn't see through it.
1) 5.0 isn't considered a stable release yet. I think 5.1, maybe even 5.2 will be the first stable release on the 5.x series. It's considered a test release.
2) Lots of people are just plain conservative. Some people still use the 3.x series because they see no need to upgrade. I'm sure some folks still use the 2.0.x series kernel, and look for updates.
while (reading_slashdot == TRUE) {
++nerdiness;
--social_life; }
Remember to declare reading_slashdot as volatile, or the compile will optimize the comparison out of the loop - it doesn't see anything in the loop that can change the true or falseness of the comparison, so optimize that comparison out of the way. Of course that assumes that someone reading slashdot will at sometime actually get a life and stop reading, which may be assuming a bit much, so maybe having it like that is a better model.
It's been discussed, the big problem with this type of software is updates. Tax tables change, tax laws change. Part of you buying a tax program is buying a subscription for the updates. The companies pretty much have you by the big ones, and they have no problem clamping down if they want to.
SVR4 by definition is a mix of BSD and System V. You're essentially criticising Solaris for being SVR4 compliant. You also have to remember that SunOS4 (and earlier) was BSD. Solaris needed to keep backwards compatibility, at least in the early days of Solaris 2.0 and 2.1. I personally think they did a decent job with it.
You mention the GNU tools - you can already get them for Solaris, install them as needed, from the Sun sponsored www.sunfreeware.com. Solaris 2.8 (I hate Sun's new numbering scheme) ships with bash and zsh. There are POSIX (read: More GNU like) compliant tools in/usr/xpg4/bin. It's a very flexible system. Swapping out all of the Solaris tools for GNU ones would break a lot of things just to spare the inconvenince of a download and a pkgadd, not worth it for most people. I thought they also shipped with a freeware CD, but I might just be thinking of SGI.
I find it slightly odd that you bring up ease of administration on Linux systems, yet criticize Sun for being a hodgepodge of SYSV and BSD. Every distro seems to have it's own tools and pick and choose which standards they wish to follow. Early RedHat shipped with a major variation to the layout of SYSV startup scripts in/etc, which the've sinced kind of corrected. Early Slack (I haven't used it recently) was more BSD userland than SVR4. Linux is too heterogenous to say "Linux admin is better than Solaris" If you picked a distro, and maybe say "RedHat 7.3 admin is better than Solaris" that would be a better argument.
And though it's just prognosticating, I don't think Solaris for x86 will ever do anything, much less save Sun. Solaris x86 was always sold as a low end UNIX for admins to be able to play with at home. You can hone your skills on a cheaper x86 box, know where all the tools are when you come to work and play with the real machines. As such, it's never been really optimized for the x86, and has a (deserved) reputation for being slow. Linux would and does kick it's ass on low resource boxes.
I never really bumped into any BSD/SVR4 problems with Solaris. Though most of the stuff in/usr/ucb sucks (/usr/ucb/cc is a Royal Pain In The Ass and should have been deleted years ago)/usr/ucb/ps has some nice features and complements the SVR4 ps nicely. Keep/usr/ucb out of your PATH, make an alias for/usr/ucb/ps so it's handy when you need it's different feature set, don't link with anything in/usr/ucblib and you're fine.
"FTP Holes" refer to security problems in the ftp daemon. wu-ftpd (from Washungton University - anyone else remember ftp'ing to wuarchive.wustl.edu?) has a particularly bad security history. Some of these holes have allowed shell access, which run as the same user the daemon runs as. Since this is running on UNIX, it's required to run as root (you need to be root to bind() to ports under 1023, which ftp does) you end up giving someone root access on your machine. root has access to the whole machine, not just thenon-sensitive data.
There are some ways of mitigating this. Pretty much everybody chroot's their ftp server, which limits but doesn't eliminate the damage. The problem is root can break out of a chrooted process if they really wanted to.
He's talking authentication schemes, and HTTP has many more options. HTTP Digest authentication allows non-cleatext passwords. There is no such option with FTP, all passwords are cleartext.
And though it's technically HTTPS not HTTP, at least there is a common implementation of HTTP over SSL out there. Everything encrypted, and you can even skip passwords entiredly and do authentication using certificates if you want to go through the trouble. FTP over SSL isn't all that common.
HTTP has authentication as well, in fact it can be more secure - with Digest authentication (which few clients support) there's no password exchange. The one advantage for FTP in authentication here is it's probably easier to set up authentication on an ftp server than an HTTP server - you can authenticate against/etc/passwd easier than most HTTP servers (though this is decidedly a BAD idea).
HTTP also has a well defined SSL implementation (I don't know about FTP over SSL). You can also authenticate with certificates.
HTTP does not encode/decode binary objects. It sends them binary. If anything it should be lower weight than FTP - only one connection, as opposed to FTP's 2, control and data.
The other thing to remember about FTP, the server tries to make a connection to you. This obviously has problems with firewalls, so there's a variation (now pretty much the standard) called Passive FTP where the client makes all connections. Some FTP clients do this automatically, some you have to configure. Every new system I get I need to add the line into ~/.wgetrc to get FTP to work.
UNIX web servers generally have had a much better security record than ftp servers. wu-ftpd has been rooted many times, it's extremely rare for any shell access to be allowed by Apache and if so you run as the user Apache is run under, not as root. Also remember that a lot of the optimization for net services has been centered on the web space, not ftp. For example, has wu-ftpd been rewritten to use sendfile()?
If I had to choose one or the other, I'd choose HTTP. There are command line tools available like cURL and wget if you need to use them, but non-technical folks can always use the web-browser. Why not both? Why can't the ftp server serve the same area as the web-server? I know I've seen this at a lot of big FTP sites.
I have Mozilla with "notify on cookies" turned on. I got nailed on a cross-site cookie. I looked around for what game me the cookie, was a web-bug.
Any website for a top level domain that exists essentially solely to map personal information to an email address that is also clueless enough about privacy concerns to have a cross site web bug on it (from stats.superstats.com) would probably not inspire confidence in me about their willingness to respect my privacy wishes.
Umm, depends on what you mean. If you mean it truly isn't backwards compatible, like Sun moving from 680x0 to SPARC and everything needing a recompile, then that's false, there is IA32 support in Itanium.
If you mean backwards compatible with acceptable performance, well obviously acceptible is subjective but most people say no.
How much spin Intel can put on that "acceptable" and how much IA32 slowness people wil put up with will determine this.
And the basis for most of the UNIXes out there. Sun, NeXT, HP/UX all started on 68K machines, possibly others. MacOS, Atari ST's TOS, the original Amiga also cut their teeth on 68K chips before having to stray or disappear entirely. Kind of ironic to see the UNIX market fracture and everybody goes with their own chips, and now all recombine and settle on a single architecture again, in this case the relatively unappealing Itanium.
Slashdot Mirror
You are correct in that Hydrogen is the only fuel that lets out water vapor as its only by-product. Any other fuel has carbon dioxide (and possibly carbon monoxide) as byproducts. Insert Global Warming debate here. I don't think at these levels you'd have to worry much about the ice caps.
The main problem is that hydrogen has a very low energy/mass ratio. The only way to get anything even close to a decent range is to have massively compressed hydrogen. This in itself is a hazard. If you see a fuel cell in a car, look at how much cladding they have on that hydrogen tank. You're not going to have that kind of hydrogen tank shielding on something meant to be portable. Methanol is the simplest chemical that is liquid (and therefore relatively dense) at room temperature that they can use in a fuel cell.
The other big problem is hydrogen is very reactive - read explosive. Probably not a good idea to have explosives on your laptop.
Also, its easier for you to refuel methanol than to refuel hydrogen. There's no hydrogen infrastructure. Not much of a methanol one either, but you probably could get methanol if you looked for it.
1) you misread this - it's methanol, not menthol.
2) methanol is a poison. Low levels of methanol will permanently blind you. At higher levels, you'd be dead. "Denatured" alcohol is ethanol ("normal" drinkable, get drunk on alcohol) with very low levels of methanol. It's used in industrial processes. There's not enough methanol to screw up most reactions that require ethanol, but enough methanol to make it poisonous to drink so people wont use it as a way of avoiding government taxation.
I'm sorry sir, you must be 21 with 3 IDs to purchase fuel for your laptop.
(eg, I thought the Dreamcast used WinCE?).
IIRC, the DreamCast was actually OS-less. It had enough firmware to boot from the CD. The development kit that could actually talk to the hardware was only ported to WinCE, and one other platform (netBSD I'm reaching for, but not sure) so essentially you were locked into booting your DreamCast into WinCE or the other platform (again, think it was NetBSD).
>> Can I turn of HTML mail in Outlook?
> Why couldn't you before? I use text email in
> Outlook just fine. It even highlights URLs for me
> in text mode which I find nice . Maybe you don't?
Outlook HTML mail has two forms, coming and going. Going is the least evil, coming is the big problem.
Going out, you may have places that won't appreciate HTML email. You may have to turn it off, run through some dialogues to make it permanent, maybe even go to your contact list and say "no HTML ever to this guy/group".
Worse is it coming in. Though HTML mail in general can be bad (HTML spam with webbugs, see who opened it up) a scriptable HTML email client is truly scary. Since Outlook renders things with IE web components, you've just pretty much inherited all IE bugs. "Hey, lets allow random unknown and untraceable people send other people scripts that will run on their computer". That was initially, soon enough they plugged some of the holes, but instead of realizing that the basic idea was flawed (allowing an email to execute things remotely) they decided to have a list that limited what people could do. The problem with such lists is there may be things that got left off. Sure enough, some components were marked "safe for scripting" that shouldn't have. One of these was a component that allowed file system access. Hmm, so an email could run some VBscript, script a component, and erase files on your hard drive. The Good Times virus becomes real. The only reason these bugs never caused widespread panic was that there were much easier ways to achieve the same damage. Why bother climb up to the second floor and break a window when the front door is unlocked and open.
HTML email is just bad. There are a lot of holes. There are privacy requirements and security requirements for email that go above whats required for general web browsing. Trying to close the holes after is hard.
I think you think "baroque instruction encoding" is some official term. It's just Linus' explanation for the BS of x86 instructions and how they seem to be laid out. The way the registers are segmented, and (if I remember, it's been years since any x86 assembler) you have upper byte of the lower word, lower byte of the lower word, and the upper word, because it went from a 16 bit chip to a 32 bit chip. 680x0s were 32 bit registers from day 1, just the address bus wasn't 32 bit initially (24 bit only, but 32 bit address registers). Some x86 instructions only can be used on certain registers (because of space and money constraints on implementing them gloabally in the original 8086 days). Anything you can do in D1 on a 680x0, you can do with D5. Anything you can do with A0, you can do with A6, though you probably don't want to do it with A7 (stack pointer). The 680x0 is a very orthogonal chip, with very few special cases. The x86 is riddled with them.
Yes, but now RMS is a Windows project (Google Cache). Will it now be Windows/RMS/GNU/Linux?
Citibank allows a 4, 5, or 6 digit PIN. Some networks (most international ones) can't handle anything but 4. Maybe you could get two accounts, one for home, with a 6 digit PIN, and one with 4 digits for international travel, where its a real restriction. Check with your bank.
I think Exchange servers already allow this, we run exchange here at my job (shudder) and I recall "Message has been recalled" notices. So you're going from one Outlook/Exchange proprietary toolset to another Outlook/Exchange toolset - shouldn't affect those guys at all.
Java chips? Though thats kind of cheating, since it's just making a Virtual Machine concrete.
Altavista started off (kind of like Yahoo, and Google itself in a way) as a happy accident. They wanted a way to showcase Alpha technology, so they created http://altavista.digital.com. They'd spider the web, and since Alphas were the premiere 64 bit chip, they'd show off "hey we have the Internet indexed on a single server with a single system image". But what was essentially advertising, became useful. Just as a lot of things lucked into, they never really guessed that the search engine would become a profit center, and it exploded in popularity. The old owner of the domain altavista.com (forgot what they did) got massive traffic when people would hear "Altavista" and just typed it in to the browser, and Netscape would do the http://www. and the .com bookends. Eventually Digital saw the site as more than just an ad for Alpha chips and made it a product itself, including selling the code for internal indexing and all that. They bought the altavista.com domain for a hefty fee, and now the site is there. I forgot how the whole Compaq purchase fits into the timeline. Eventually Digital/Compaq realized they were horrible at making money from it, and sold it to CMGI, I forgot who has it now. It's been dying a slow death, though babelfish translations are kinda fun.
At one time they were the best search engine, and their boolean searches - though with a clunky interface - gave the best filtering. Now google can claim that, even though they don't have the same degree of control of boolean searches. No one really has had an idea of what altavista should be, from DEC using it as an ad, then trying to "productize and monetize" it (to use buzzwords I hated from my dot.com dayze) to selling it to CMGI and have ad revenue and popups try to prop it up, to "I'm not sure what they're doing now but pretty sure they don't either."
"It's an 'El Camino.' That's Spanish for 'the camino'."
Maybe they just like Ashton Kutchner?
CGI is pretty much the oldest method of a web server interacting with outside code, and is kind of the only standard way. The server fork/exec's a process and has the CGI process' stdin, stdout, and stderr are pointing back to the server. The web server passes information either through environment variables (for a GET request) or additionally through the process' stdin (for POST and PUT requests).
Advantages: very clean, the process goes away after the request, so resource leaks aren't a problem. Very simple interaction, if your programming language understands stdin, stdout, and environment variables (hard to find one that doesn't) you can do CGI with it (though some are better than others obviously).
Disadvantages: fork/exec for every request. That has some overhead, sometimes more important is that the process can't use persistent state. Resources have to be acquired on every request. Anything with a great deal of overhead, say opening a database connection, has a HUGE impact on the server.
FastCGI is a pseudo-standard in that it has multiple people implementing it, but it never got approved by, say, the IETF. It's a client server kind of thing, where the first instantiation starts the server up and initializes it. Subsequent requests get sent to the CGI server and get returned. The CGI server never goes away. The cool thing is that there are no startup costs, and you can keep something like a DB pool. Never really used it, so can't comment much.
Some things just get embedded into the server, like Apache modules. You can write C code and it becomes part of the server itself.
Advantages: wicked fast. Full access to anything in the server.
Disadvantages: if your CGI has a problem, it can bring down your server. The API's can be pretty arcane. Also, it's a different API for each web server (NSAPI vs. ISAPI vs....) and even between variants (it's wildly different from Apache 1.3 and apache 2.0).
mod_perl is kind of like above, it's a perl interpreter bound into Apache. Gives a perl interface to pretty much everything apache has to offer. Not only requests, but configurations.
Advantages: perl is very flexible, can do a lot of things and use perl modules from CPAN, including templating systems and the such. You're also insulated a bit from stray pointers and such. mod_perl also precompiles all of the perl code, so you don't have the compiler overhead on every request.
Disadvantages: mod_perl can be huge sometimes, and if you have several mod_perl instances running around, you can eat memory pretty quick.
Everything else is kind of "do what you want". Tomcat itself has several protocols to talk to Apache; some are just old, some are supported on certain platforms only, yadda yadda.
That said, the article did confuse a bunch of things, CGI, C, and content management systems. He was pushing an agenda, hopoing that people couldn't see through it.
Wasn't 5.0 released about 3 weeks ago?
1) 5.0 isn't considered a stable release yet. I think 5.1, maybe even 5.2 will be the first stable release on the 5.x series. It's considered a test release.
2) Lots of people are just plain conservative. Some people still use the 3.x series because they see no need to upgrade. I'm sure some folks still use the 2.0.x series kernel, and look for updates.
while (reading_slashdot == TRUE)
{
++nerdiness;
--social_life;
}
Remember to declare reading_slashdot as volatile, or the compile will optimize the comparison out of the loop - it doesn't see anything in the loop that can change the true or falseness of the comparison, so optimize that comparison out of the way. Of course that assumes that someone reading slashdot will at sometime actually get a life and stop reading, which may be assuming a bit much, so maybe having it like that is a better model.
It's been discussed, the big problem with this type of software is updates. Tax tables change, tax laws change. Part of you buying a tax program is buying a subscription for the updates. The companies pretty much have you by the big ones, and they have no problem clamping down if they want to.
Solaris is a heinous kludge of BSD and System V.
/usr/xpg4/bin. It's a very flexible system. Swapping out all of the Solaris tools for GNU ones would break a lot of things just to spare the inconvenince of a download and a pkgadd, not worth it for most people. I thought they also shipped with a freeware CD, but I might just be thinking of SGI.
/etc, which the've sinced kind of corrected. Early Slack (I haven't used it recently) was more BSD userland than SVR4. Linux is too heterogenous to say "Linux admin is better than Solaris" If you picked a distro, and maybe say "RedHat 7.3 admin is better than Solaris" that would be a better argument.
/usr/ucb sucks (/usr/ucb/cc is a Royal Pain In The Ass and should have been deleted years ago) /usr/ucb/ps has some nice features and complements the SVR4 ps nicely. Keep /usr/ucb out of your PATH, make an alias for /usr/ucb/ps so it's handy when you need it's different feature set, don't link with anything in /usr/ucblib and you're fine.
SVR4 by definition is a mix of BSD and System V. You're essentially criticising Solaris for being SVR4 compliant. You also have to remember that SunOS4 (and earlier) was BSD. Solaris needed to keep backwards compatibility, at least in the early days of Solaris 2.0 and 2.1. I personally think they did a decent job with it.
You mention the GNU tools - you can already get them for Solaris, install them as needed, from the Sun sponsored www.sunfreeware.com. Solaris 2.8 (I hate Sun's new numbering scheme) ships with bash and zsh. There are POSIX (read: More GNU like) compliant tools in
I find it slightly odd that you bring up ease of administration on Linux systems, yet criticize Sun for being a hodgepodge of SYSV and BSD. Every distro seems to have it's own tools and pick and choose which standards they wish to follow. Early RedHat shipped with a major variation to the layout of SYSV startup scripts in
And though it's just prognosticating, I don't think Solaris for x86 will ever do anything, much less save Sun. Solaris x86 was always sold as a low end UNIX for admins to be able to play with at home. You can hone your skills on a cheaper x86 box, know where all the tools are when you come to work and play with the real machines. As such, it's never been really optimized for the x86, and has a (deserved) reputation for being slow. Linux would and does kick it's ass on low resource boxes.
I never really bumped into any BSD/SVR4 problems with Solaris. Though most of the stuff in
"FTP Holes" refer to security problems in the ftp daemon. wu-ftpd (from Washungton University - anyone else remember ftp'ing to wuarchive.wustl.edu?) has a particularly bad security history. Some of these holes have allowed shell access, which run as the same user the daemon runs as. Since this is running on UNIX, it's required to run as root (you need to be root to bind() to ports under 1023, which ftp does) you end up giving someone root access on your machine. root has access to the whole machine, not just thenon-sensitive data.
There are some ways of mitigating this. Pretty much everybody chroot's their ftp server, which limits but doesn't eliminate the damage. The problem is root can break out of a chrooted process if they really wanted to.
He's talking authentication schemes, and HTTP has many more options. HTTP Digest authentication allows non-cleatext passwords. There is no such option with FTP, all passwords are cleartext.
And though it's technically HTTPS not HTTP, at least there is a common implementation of HTTP over SSL out there. Everything encrypted, and you can even skip passwords entiredly and do authentication using certificates if you want to go through the trouble. FTP over SSL isn't all that common.
HTTP has authentication as well, in fact it can be more secure - with Digest authentication (which few clients support) there's no password exchange. The one advantage for FTP in authentication here is it's probably easier to set up authentication on an ftp server than an HTTP server - you can authenticate against /etc/passwd easier than most HTTP servers (though this is decidedly a BAD idea).
HTTP also has a well defined SSL implementation (I don't know about FTP over SSL). You can also authenticate with certificates.
HTTP does not encode/decode binary objects. It sends them binary. If anything it should be lower weight than FTP - only one connection, as opposed to FTP's 2, control and data.
The other thing to remember about FTP, the server tries to make a connection to you. This obviously has problems with firewalls, so there's a variation (now pretty much the standard) called Passive FTP where the client makes all connections. Some FTP clients do this automatically, some you have to configure. Every new system I get I need to add the line into ~/.wgetrc to get FTP to work.
UNIX web servers generally have had a much better security record than ftp servers. wu-ftpd has been rooted many times, it's extremely rare for any shell access to be allowed by Apache and if so you run as the user Apache is run under, not as root. Also remember that a lot of the optimization for net services has been centered on the web space, not ftp. For example, has wu-ftpd been rewritten to use sendfile()?
If I had to choose one or the other, I'd choose HTTP. There are command line tools available like cURL and wget if you need to use them, but non-technical folks can always use the web-browser. Why not both? Why can't the ftp server serve the same area as the web-server? I know I've seen this at a lot of big FTP sites.
I have Mozilla with "notify on cookies" turned on. I got nailed on a cross-site cookie. I looked around for what game me the cookie, was a web-bug.
Any website for a top level domain that exists essentially solely to map personal information to an email address that is also clueless enough about privacy concerns to have a cross site web bug on it (from stats.superstats.com) would probably not inspire confidence in me about their willingness to respect my privacy wishes.
Here it is, 50 comments or so, and not one damn Godzilla post. Would Bill Gates be the Smog Monster?
Sun never even released a 68040 based computer, having long committed to SPARC. I doubt 68060 was even considered, delays or not.
I found some info on a website, a Sun 3/60 with a 20MHz 68020 was codenamed "Ferrari". Seems pathetic now in the day of 3GHz desktops.
Itanium isn't backwards compatible...
Umm, depends on what you mean. If you mean it truly isn't backwards compatible, like Sun moving from 680x0 to SPARC and everything needing a recompile, then that's false, there is IA32 support in Itanium.
If you mean backwards compatible with acceptable performance, well obviously acceptible is subjective but most people say no.
How much spin Intel can put on that "acceptable" and how much IA32 slowness people wil put up with will determine this.
The Motorola 68K family were a joy to work with
And the basis for most of the UNIXes out there. Sun, NeXT, HP/UX all started on 68K machines, possibly others. MacOS, Atari ST's TOS, the original Amiga also cut their teeth on 68K chips before having to stray or disappear entirely. Kind of ironic to see the UNIX market fracture and everybody goes with their own chips, and now all recombine and settle on a single architecture again, in this case the relatively unappealing Itanium.