For the past year, about 15% of all spam I see comes out of AS4766 - KORnet. The of the top 4-5 rest bounce around Chinese IISPs, Telstra, SBC, Tiscali, AT&T Worldnet, and account for 25% of all spam received. The problem is highly concentrated.
You can also check postings to NANAS (news.admin.net-abuse.sightings). Or just check at Spamhaus for ROKSO spammers and their ISPs.
Unfortunately, for some people (and the ISPs they run), there is no shame.
Joe runs network ops for University of Oregon, and has a good set of for-the-public articles at his website.
These days, however, how your mail gets routed is a very important issue for one simple reason: deliverability.
"Deliverability" is a term that has been coined to capture the problem that sites increasingly face trying to get legitimate mail through anti-spam measures. Trying to send mail that includes bad keywords? You may have "deliverability issues" at sites that use content-based filters. Had an accidental configuration problem that resulted in spammers exploiting your system for a while? You may be listed on one or more DNSBLs, and have "deliverability problems" as a result.
Deliverability is particularly closely tied to reputation. Every piece of mail that gets sent from your campus, whether created by a local user or forwarded by that user to another account using a dot forward forwarding entry, "counts" against your reputation at a growing number of providers. As far as they can tell (and remember, this is all automated because of the hundreds of millions of messages that are involved), when you hand their mail servers a message, "you" sent them those messages, even if all you did was innocently and dutifully forward the mail on behalf of one of your users, as instructed by that user's.forward file.
If you're going to emit it (allow.forward), then you're going to have to own it, and if you own it, you're going to have to deal with incoming spam. Unfiltered.forward is a dying breed. Either find an alternate solution, or filter the mail.
Document stylesheet trumps user. Unless the user specifies the "!important" modifier, in which case user trumps document. I find this very useful, and use it to override a lot of b0rkeness on the Web.
Also, in some browsers (Galeon among them) it's possible to create a set of stylesheets which can be applied to any arbitrary page, only when specified. I actually use this to tweak the "light" Slash code to format it more like the default. Fun thing is you can apply it to default websites. Screenshots linked from http://lists.svlug.org/pipermail/svlug/2005-Januar y/048897.html
This and other userContent.css tricks at UserContentCSS TWikIWeThey page.
There's also the greasemonkey Firefox extension, which extends this concept somewhat.
Elsewhere Nielsen advises designers to hide low-level error messages from users. Completely misguided.
One thing I've noticed adminning both GNU/Linux and legacy MS Windows boxes is how much easier it is to research issues in Linux. Plug the command and error output (command output, logs, etc.) into Google, and find the solution. That's GNU/Linux.
Windows. Well.... Is it "The Internet", or "Internet Explorer", or "MSIE", or "IE"? Since you can't copy and paste from an error dialog, what exactly was the error message? (Aside: I hate GNOME, but damned if they didn't get this right: popup error dialogs are copyable as text). Even program names are amazingly un-Googleable. "Um. Let's see if there's anything in Google for 'Word'". Almost as bad as Mission Impossible (the movie) where Cruise searches the Internet for "Job" (from the Bible)...and turns up zero hits. Um. Yeah. Nobody's ever posted a job listing.... Long and short of it: it's bloody difficult to Google for solutions. Also seems to be a cultural difference where people don't post their Windows issues (or at least not meaningfully).
Back to our story: yes, being able to identify the specific program, feature, and location of the error, and if at all possible, the precise error text. Succinctly. But specific.
Though frankly, I think I don't like the new window-circulation-navigation GUI, hope a disable option will go into WPrefs.
WinXP virtual desktop (powertoys) *bites*
on
Xfce 4.2.0 Released
·
· Score: 1
Yawn.
No window/workspace association. Open app A in workspace 2. Switch to workspace 1. Open App B. alt-tab to app A. It moves to workspace 1. You've got to go to workspace to keep the app where it was. Very annoying if you try to organize workspaces by task (as I do with WindowMaker).
Slow performance. Just in general. Switching between workspaces / virtual desktops is painful. Even with a fast CPU and reasonably large RAM allotment (512 MB+).
Lots of other weirdness. Microsoft's GUI just isn't built with the idea of multiple workspaces in mind.
The third-party VDs work a bit better. I used WRQ's (part of Reflection X) for a while. But it still pretty much bites.
Novel disease agent (SARS virus) of unknown origin.
Extremely high mortality rate (as noted by other responses). The ultimate mortality rate appears to be around 9%, though localized rates in excess of 20% exist, possibly due to variance in the infectious agent (more below). Moreover, as I was following stats at the time, the mortality rate was grossly underreported for several weeks as the epidemic unfolded. I wrote several nastygrams myself to The Economist which was quoting a much lower (3-8% IIRC) mortality. Mortality varied greatly with age, from Wikepedia: "below 1% for people aged 24 or younger, 6% for those 25 to 44, 15% in those 45 to 64 and more than 50% for those over 65." The article has a wealth of information.
Extremely high transmission rate. SARS was passed between victims based on very casual contact, including apparently nothing more than sharing a confined room for a brief period of time.
Poor response to therapy. Once ill, a victim's prognosis was largely independent of treatment. Viruses are difficult to treat in any event, and the few nominally useful antiviral treatments which do exist were largely ineffectual.
Rapid mutation and/or wide variance among viral strains. Based on my after-the-fact recollection of SARS mortality rates. China had among the highest mortality, rates were far lower elsewhere. This may have been due to differences in treatment or more strains of the virus present in China (where SARS originated) than elsewhere.
Suppression of initial information. China's government and health authorities initially responded to the SARS outbreak by supressing information. This confounded responses be making unavailable useful information and generating rumors and speculation.
High morbidity and mortality among healthcare workers. Among the hardest hit communities were the doctors, nurses, and researchers initially responding to SARS. Among the victims were several of those who first identified, treated, and isolated the disease. In a broader outbreak, healthcare workers would likely have suffered significantly. A friend's wife, staff at one of the few US hospitals to encounter SARS (Belvue, NYC) was very concerned.
So you've got a new, disease with unknown agent, few treatments, high mortality, and a large impact on healthcare infrastructure. Not a good sign.
The extent to which cases and deaths due to SARS were minimized is not an indication that the disease was overblown, but that the response to it was highly effective. Remember that there was a massive quarantine effort made. Again from Wikipedia:
Attempts were made to control further SARS infection through the use of quarantine. Over 1200 were under quarantine in Hong Kong, while in Singapore and Taiwan, 977 and 1147 were quarantined respectively. Canada also put thousands of people under quarantine. [
12] In Singapore, schools were closed for 10 days and in Hong Kong they are closed until April 21 to contain the spread of SARS.
SARS was a very close call, and a big wakeup alert.
The keyspace is limited, however. Ideally, 1 billion distinct values. In practice, somewhat fewer. Groups 800-999 are not assigned, and Railroad Retirement Act numbers extend the range with "R##" "area" numbers.
Login to the computer using the administrative account when you want to install that stuff. Isn't that obvious?
Sure: sudo aptitude install foo
Oh yeah, can't do that in legacy MS Windows. Don't talk to me about "Run As". Should be called "Run as...maybe, if I feel like it...but it will probably break." A little long for an advertising jingle, but accurate.
Sorry, but the idea of losing 60 windows worth of state, including several editor and mailer sessions, and nine browser windows with on the order of 100 open tabs, just to install/update software, sucks.
My desktop session's been running for over a month. In the meantime I've updated my system almost daily, as well as several others on the local network. Without having to physically access those other boxes (unless using one as a footrest counts).
I've had the following in my signature file rotation for some time. Looks as if it's starting to be fulfilled:
The black hat community is drooling over the possibility of a secure execution environment that would allow applications to run in a secure area which cannot be attached to via debuggers.
- Jason Spence, on Palladium aka NGCSB aka "Trusted Computing"
I've had a CappuccinoPC Mocha P4 for the past couple of years. It's similar in concept to the Mac Mini: small enclosure (mini-ITX), lots of ports (2 NICs, serial, parallel, 4x USB, audio in/out, video in/out, firewire...). But keyboard, monitor, and mouse are sseparate.
That's actually a bonus:
I already had a keyboard, mouse, and monitor. Though not as nice as I'd wanted....
Keyboard ($10) and mouse ($14) are pretty damned cheap.
For $350 I got a really nice 19" CRT monitor.
If any of keyboard, mouse, or monitor go south, you replace them for $10, $14, $150-$350, or out of current inventory.
Meantime, the CPU itself sits safely out of harm's way. Most "accidents" are spills or drops, or just too much handling.
The unit slides into my satchel for ready use at home, work, client site, etc. All I need are a kbd/mouse/monitor to use it. And guess what: most sites already have these.
Modularization is a benefit.
The main grip I've had is that it's not possible to use the unit in transit. CappuccinoPC claimed they'd be coming out with a battery pack, but AFAIK haven't. And there's no seperable LCD display available I've found that's appropriate (I'm thinking $100-$200 pricepoint for a 4x6 640x480 or 800x600 screen -- enough to work on the run).
If Apple could push for that to come out, it would be ideal. Leave the Mac Mini in its bag with a battery pack. Display with a wire stand and/or velcro backing sits on your cafe table or airplane seat back. Keyboard and mouse/trackpad in front of you. Do work.
I'd hope Apple would come out with a security kit other than your standard laptop cable. These generally just fit into a plastic case slot, and the only real security value is that the case is damaged when the unit is stolen.
The damned thing's so small you'd have a significant number of 'em "walking". Not good.
That's one of the advantages of a standard tower design. They're sort of tough to slip into a purse/backpack.
That's something I don't get. Microsoft posts a link not to a download, but to a download launch page. And that doesn't have a download link but a 'Download' button. This something for a utility which updates monthly. Not that I run MSFT's cr*p, but getting paid to clean up after 'em's a sidelight, and being able to wget updates is helpful.
Not sure if Microsoft's planning on moving the link, but the following URLs should work at present:
IBM makes massive committments of marketing, development support, and patent defense to Free Software....because IBM realizes billions of dollars of revenue off of Free Software?
Three words: Bring it on!
IBM's realized that Free Software is Good Business. Amen, brother. That tells me their committment is long term, and so much the better.
One of the interesting things about IBM is that it's among the oldest tech companies in existance -- 116 years old. It's been around enough to learn a few things, and signs are that the institutional knowledge is sticking:
Technology trends come and go.
Leasing wins.
Monopoly positions are "tippy". Great when you've got 'em, but woe (and woah!) when the slide begins.
In IBM's calculus, Free Software (or what they call Open Source) is the equivalent of broadly diversified investment portfolios. You don't get the option for a massive win as you might with a locked-in proprietary solution. But if you've got fundamental tech smarts and execution capability, you can get a long-term bankable performance. And it's murder on the guys playing the monopoly gambit.
Speaking for myself, I'm more than happy to see an argument on the basis of self interest for Free Software participation. It's a Good Thing[tm].
PEBuilder (and 911 Rescue CD) are among the only legacy MS Windows-based rescue bootable CDs I'm aware.
Both of them suffer from a number of disadvantages compared with Linux-based bootable CDs:
Unlicensed. Despite some unconvincing fast footwork by Bart on his website, the fact remains that BartPE is an unlicensed copy of Windows, using files extracted from MS Windows installation media.
Build tools, rather than images. While Knoppix, LNX-BBC, DSL, and other Linux bootable systems are available as complete, self-contained images which can be downloaded and burned to disk, the Windows based PE builders assemble a set of local tools onto the disk. Which means you need copies of the utilities to install. As 911 Rescue points out, that's well over US$700 worth of software.
Severely limited environment. BartPE allows no more than six simultaneous processes, and 24 hours continuous operation, 800x600 max resolution, and you can't legally duplicate and distribute the disks. Linux bootable disks allow unlimited processes, users, maximum supported video resolution, and of course, you can burn as many of 'em as you want to distribute to co-workers, friends, clients, or the public. I've literally left Knoppix systems running for a week or more while using systems for recovery, demo, repair, installation, etc.
Sure, there are Windows-related repair and recovery tasks best accomplished from within a Windows environment. But the tools are far more limited than the equivalent Linux tools.
One thing I gained an appreciation from the Tsunami coverage and videos.
It's only partially about the wave height. I understand now why the term "tidal wave" came into being: the wave is like a fast-moving tide. A wind- or wake-generated wave of 1-3 meters is one thing. A tsunami / tidal surge sustained over several minutes is going to do a world of hurt for low-lying districts, and a lot of coastal areas are only marginally above sea level.
Several videos clearly show a sea that's less crashing into the shore than spilling over its banks, and continuing to do so for several minutes. Even though the water is only a meter or so over mean land elevation, the damage it does is considerable.
Sure, it's not flattened buildings and people sucked out to sea. But it is floaded basements, ground floors, electrical systems, utility conduits, septic systems, and the like. That's still pretty disruptive.
The difference between free software and the proprietary stuff: if you've got no plausible deniability over faults, you tend to own up to them quickly. Not quibble over whether it's a bug or not, or how critical it is. And you fix it.
If you really want to kill a long, rainy afternoon, buy Jeremy Allison some beers and ask him about the undocumented bugs the Samba team knows about in CIFS, but, because they're nice guys, they're not holding MSFT's feet to the fire over.
Sorry to break it to you, but this philosophy died a long time ago. Now we have Emacs, Perl, Python Ruby, FireFox, and so on.
Well, of those, two are balloons (things that go on the end of a pipe that fill up but don't empty -- as opposed to nodes or sponges (think sort)). Pretty much any scripting language (you cite three) can be used in pipelining, and some of the more interesting uses come from same.
The pipeline concept starts running out of steam when you get to complex interactive environments, but that's pretty much the definition of an editor or viewer (eg: Emacs, Firefox). Though it is possible to use scripted editors (hey, isn't that what "sed" stands for?), vim can edit stdin, and text-mode browsers such as lynx and w3m can read and write stdin/stout, and can be quite useful for same. Even pagers such as less -- using lesspipe, it's great for converting MS Word docs to text.
...and it turns out that you can even use pipelines in some tools you'd think otherwise not supporting it, including editors, browsers, and graphics tools, generally in converting or batch-processing data or files, damned useful when you need it.
The upshot: pipelining means a tool's utility is extended greatly beyond what functionality is built into the interactive menus.
Why does every shell need it's own custom language?
First of, false premise. Of the standard shells: sh, bash (and minimized variants ash & dash), csh, tcsh, zsh, and ksh, scripting essentially falls into two classes: Bourne compatible and csh compatible. The two syntaxes are largely similar, and within families, backwards compatible.
Second: Because The Shell Is There. I've seen inits written as bash scripts (LNX-BBC). Damned useful on a minimal system, in this case, bootable mini-CD, but Tom's Root Boot, install disks, or a hell of a lot of embedded systems come to mind. Even in larger systems, shell remains in use, very often in system scripts executed automatically at startup or via schedulers. Just 'coz you can't see 'em doesn't mean they don't exist.
A shell session is (from the kernel's point of view) a very slowly read script. The scripting utility's been built in for over three decades, there's no reason to strip it out. Small shells (ash, dash) provide a powerful scripting environment in minimal space -- an installation of Perl, Python, Ruby, etc., would impose far higher storage requirements.
Being able to rattle off one-liners at shell is also useful, particularly as the syntax is familiar: it's what you're using every day. I know many long-time power hacks who've never gone far into other "real" scripting languages simply because a handfull of shell tools provides sufficient power for their needs.
Sure: If you need a full scripting language and can use it, by all means do. There's room for all (given sufficient storage).
Your statements betray a gross lack of understanding and appreciation of what the shell can and does, not to say a gross immaturity regarding Unix/Linux in general.
Mind, UWIN's/reg virtual filesystem's even cooler. Also note that Microsoft's got a REG.EXE in some subset of platforms that I've been unable to specify exactly.
Which itself is a major hassle of Microsoft systems: finding out just what the command set is, and where it's documented. Rarely anywhere.
anything you can configure with the GUI you can also configure with the command line.
Got a reference for specifics? I've looked for CLI alternatives for a number of tools, and I've pretty much uniformly found:
They're not documented. There's a hell of a lot to be said for man pages. If you're on the right systems (eg: Debian), Policy requires every single system executable be documented.
They're not uniform across MSFT platforms. And most shops I've seen are mixed environments.
I suspect the ultimate decomposition of this statement is that REG.EXE allows modification of any Registry entry. Which on one basis is CLI access. But hardly what a 'Nix admin would be comfortable with, and lacks significant functionality and utility.
I actually noted something similar when I first started migrating toward Linux...from proprietary Unices (Solaris, HPUX, Irix...).
It was that the Linux userland (command line environment and applications) was far richer. This ~1997.
For starters were the shells (bash and zsh over csh and korn/POSIX shell). If you were really lucky, you might find Solaris with tcsh installed.
But it was specific command-line apps that were the real differentiators. Whether retools (gawk vs. nawk), more secure (ssh vs. telnet), or wholy new (Perl, wget, rsync, Python, mutt....). Proprietary Unices of the time were try to tell me that VUE, or OpenLook, or CDE, or $ENTERPRISE_GUI_ENVIRONMENT_DE_JOUR was All I Needed. Bollox.
The point is that it's a combination of factors which makes GNU/Linux what it is. The Unix Philosophy (simple tools, one thing well) is part of it. But the "OS of the users, by the users, for the users" bit is what keeps the actual useful stuff, not high-glitz and sexy interfaces that look good on brochures and in executive presentations, is also essential.
Microsoft has neither. It has no unifying process / file / user / interaction model, as does Unix. And developing "advanced user tools" is seen as a value-add / bonus-pak sort of thing (as was providing solid utilities or dev tools for proprietary 'Nix). And the result is: you can't comprehend the fundamental principles, and you can't count on a base toolkit on being available -- on different platforms, on different sites, even on different boxes within a site.
Sure, MSFT have provided various answers to 'Nix shell and scripting over the years, and I've seen several of them go from hype to dust. Which is another large part of the problem. On my Linux box, the scripts and trix I first picked up 18 years ago at college Still Work. But the environment hasn't remained static, not by a long shot: it's been incrementally improved and augmented over the years. Unmodified scripts, etc., still work, but new ways are available.
Best of both worlds.
So: your point that it's not the shell, but the shell-based programs, that provide functionality? My point exactly: Microsoft have failed to either tend to providing these tools, or provide an environment in which they could flourish. The result is that "third-party" plug-ins such as Cygwin are vastly preferred for automating and managing such tasks. Works. Cross-platform (both among MSFT and 'Nix variants) portable. And long-term uniform and stable. Not an inconsiderable factor.
Feels like there's a lot of room for improvement here.
Of course there is. And Free Software gleefully steals from the best.
For example, how about capturing all of the output per command, then quickly allowing you to scroll through a list of previous commands and jump to its output?
This (and a few other suggestions) suggest you don't subscribe to the Unix tool design philosopy: simple tools that do one thing well. This function is either partially available (command history, reverse search, screen, bang-execution) or would best be supported via a wrapper. As one response noted, Emacs pretty much does this already.
Remember that there are a lot of uses of shell that don't assume interactive use. Hauling around this infrastructure would be bloat and baggage.
Or getting away from overly static command line windows and instead having something like a simple text editor, where you can move around in a "document" and press Enter at any time, with the output always appearing below it (some language interpreters work like this).
This isn't a shell so much as a scripting/programming environment. Python and R come to mind, as well as Emacs (of course).
And shell scripting languages are irrelevant these days,
Slashdot Mirror
Spam received by ASN. Not entirely current ATM, but recent.
For the past year, about 15% of all spam I see comes out of AS4766 - KORnet. The of the top 4-5 rest bounce around Chinese IISPs, Telstra, SBC, Tiscali, AT&T Worldnet, and account for 25% of all spam received. The problem is highly concentrated.
You can also check postings to NANAS (news.admin.net-abuse.sightings). Or just check at Spamhaus for ROKSO spammers and their ISPs.
Unfortunately, for some people (and the ISPs they run), there is no shame.
See Joe St. Sauver's The Impending End of Traditional .forward-style Forwarding. This is a growing problem, and traditional .forward is dead.
Joe runs network ops for University of Oregon, and has a good set of for-the-public articles at his website.
If you're going to emit it (allow .forward), then you're going to have to own it, and if you own it, you're going to have to deal with incoming spam. Unfiltered .forward is a dying breed. Either find an alternate solution, or filter the mail.
Actually, it's slightly more complicated.
Document stylesheet trumps user. Unless the user specifies the "!important" modifier, in which case user trumps document. I find this very useful, and use it to override a lot of b0rkeness on the Web.
Also, in some browsers (Galeon among them) it's possible to create a set of stylesheets which can be applied to any arbitrary page, only when specified. I actually use this to tweak the "light" Slash code to format it more like the default. Fun thing is you can apply it to default websites. Screenshots linked from http://lists.svlug.org/pipermail/svlug/2005-Januar y/048897.html
This and other userContent.css tricks at UserContentCSS TWikIWeThey page.
There's also the greasemonkey Firefox extension, which extends this concept somewhat.
Elsewhere Nielsen advises designers to hide low-level error messages from users. Completely misguided.
One thing I've noticed adminning both GNU/Linux and legacy MS Windows boxes is how much easier it is to research issues in Linux. Plug the command and error output (command output, logs, etc.) into Google, and find the solution. That's GNU/Linux.
Windows. Well.... Is it "The Internet", or "Internet Explorer", or "MSIE", or "IE"? Since you can't copy and paste from an error dialog, what exactly was the error message? (Aside: I hate GNOME, but damned if they didn't get this right: popup error dialogs are copyable as text). Even program names are amazingly un-Googleable. "Um. Let's see if there's anything in Google for 'Word'". Almost as bad as Mission Impossible (the movie) where Cruise searches the Internet for "Job" (from the Bible)...and turns up zero hits. Um. Yeah. Nobody's ever posted a job listing.... Long and short of it: it's bloody difficult to Google for solutions. Also seems to be a cultural difference where people don't post their Windows issues (or at least not meaningfully).
Back to our story: yes, being able to identify the specific program, feature, and location of the error, and if at all possible, the precise error text. Succinctly. But specific.
Changelog.
Though frankly, I think I don't like the new window-circulation-navigation GUI, hope a disable option will go into WPrefs.
Yawn.
The third-party VDs work a bit better. I used WRQ's (part of Reflection X) for a while. But it still pretty much bites.
Why was SARS so significant?
So you've got a new, disease with unknown agent, few treatments, high mortality, and a large impact on healthcare infrastructure. Not a good sign.
The extent to which cases and deaths due to SARS were minimized is not an indication that the disease was overblown, but that the response to it was highly effective. Remember that there was a massive quarantine effort made. Again from Wikipedia:
SARS was a very close call, and a big wakeup alert.
Wrong. Not legally, at any rate.
The keyspace is limited, however. Ideally, 1 billion distinct values. In practice, somewhat fewer. Groups 800-999 are not assigned, and Railroad Retirement Act numbers extend the range with "R##" "area" numbers.
Sure: sudo aptitude install foo
Oh yeah, can't do that in legacy MS Windows. Don't talk to me about "Run As". Should be called "Run as...maybe, if I feel like it...but it will probably break." A little long for an advertising jingle, but accurate.
Sorry, but the idea of losing 60 windows worth of state, including several editor and mailer sessions, and nine browser windows with on the order of 100 open tabs, just to install/update software, sucks.
My desktop session's been running for over a month. In the meantime I've updated my system almost daily, as well as several others on the local network. Without having to physically access those other boxes (unless using one as a footrest counts).
I've had the following in my signature file rotation for some time. Looks as if it's starting to be fulfilled:
Another system had a few hundred copyies of Netsky and MyDoom variants on it.
I've had a CappuccinoPC Mocha P4 for the past couple of years. It's similar in concept to the Mac Mini: small enclosure (mini-ITX), lots of ports (2 NICs, serial, parallel, 4x USB, audio in/out, video in/out, firewire...). But keyboard, monitor, and mouse are sseparate.
That's actually a bonus:
Modularization is a benefit.
The main grip I've had is that it's not possible to use the unit in transit. CappuccinoPC claimed they'd be coming out with a battery pack, but AFAIK haven't. And there's no seperable LCD display available I've found that's appropriate (I'm thinking $100-$200 pricepoint for a 4x6 640x480 or 800x600 screen -- enough to work on the run).
If Apple could push for that to come out, it would be ideal. Leave the Mac Mini in its bag with a battery pack. Display with a wire stand and/or velcro backing sits on your cafe table or airplane seat back. Keyboard and mouse/trackpad in front of you. Do work.
I'd hope Apple would come out with a security kit other than your standard laptop cable. These generally just fit into a plastic case slot, and the only real security value is that the case is damaged when the unit is stolen.
The damned thing's so small you'd have a significant number of 'em "walking". Not good.
That's one of the advantages of a standard tower design. They're sort of tough to slip into a purse/backpack.
That's something I don't get. Microsoft posts a link not to a download, but to a download launch page. And that doesn't have a download link but a 'Download' button. This something for a utility which updates monthly. Not that I run MSFT's cr*p, but getting paid to clean up after 'em's a sidelight, and being able to wget updates is helpful.
Not sure if Microsoft's planning on moving the link, but the following URLs should work at present:
IBM makes massive committments of marketing, development support, and patent defense to Free Software....because IBM realizes billions of dollars of revenue off of Free Software?
Three words: Bring it on!
IBM's realized that Free Software is Good Business. Amen, brother. That tells me their committment is long term, and so much the better.
One of the interesting things about IBM is that it's among the oldest tech companies in existance -- 116 years old. It's been around enough to learn a few things, and signs are that the institutional knowledge is sticking:
In IBM's calculus, Free Software (or what they call Open Source) is the equivalent of broadly diversified investment portfolios. You don't get the option for a massive win as you might with a locked-in proprietary solution. But if you've got fundamental tech smarts and execution capability, you can get a long-term bankable performance. And it's murder on the guys playing the monopoly gambit.
Speaking for myself, I'm more than happy to see an argument on the basis of self interest for Free Software participation. It's a Good Thing[tm].
PEBuilder (and 911 Rescue CD) are among the only legacy MS Windows-based rescue bootable CDs I'm aware.
Both of them suffer from a number of disadvantages compared with Linux-based bootable CDs:
Sure, there are Windows-related repair and recovery tasks best accomplished from within a Windows environment. But the tools are far more limited than the equivalent Linux tools.
More on this at WindowsRescueDisk.
One thing I gained an appreciation from the Tsunami coverage and videos.
It's only partially about the wave height. I understand now why the term "tidal wave" came into being: the wave is like a fast-moving tide. A wind- or wake-generated wave of 1-3 meters is one thing. A tsunami / tidal surge sustained over several minutes is going to do a world of hurt for low-lying districts, and a lot of coastal areas are only marginally above sea level.
Several videos clearly show a sea that's less crashing into the shore than spilling over its banks, and continuing to do so for several minutes. Even though the water is only a meter or so over mean land elevation, the damage it does is considerable.
Sure, it's not flattened buildings and people sucked out to sea. But it is floaded basements, ground floors, electrical systems, utility conduits, septic systems, and the like. That's still pretty disruptive.
...and patched the same day.
The difference between free software and the proprietary stuff: if you've got no plausible deniability over faults, you tend to own up to them quickly. Not quibble over whether it's a bug or not, or how critical it is. And you fix it.
If you really want to kill a long, rainy afternoon, buy Jeremy Allison some beers and ask him about the undocumented bugs the Samba team knows about in CIFS, but, because they're nice guys, they're not holding MSFT's feet to the fire over.
IHBT, IHL, HAND.
...as a free lunch.
...but where's the 'e' come from?
Well, of those, two are balloons (things that go on the end of a pipe that fill up but don't empty -- as opposed to nodes or sponges (think sort)). Pretty much any scripting language (you cite three) can be used in pipelining, and some of the more interesting uses come from same.
The pipeline concept starts running out of steam when you get to complex interactive environments, but that's pretty much the definition of an editor or viewer (eg: Emacs, Firefox). Though it is possible to use scripted editors (hey, isn't that what "sed" stands for?), vim can edit stdin, and text-mode browsers such as lynx and w3m can read and write stdin/stout, and can be quite useful for same. Even pagers such as less -- using lesspipe, it's great for converting MS Word docs to text.
...and it turns out that you can even use pipelines in some tools you'd think otherwise not supporting it, including editors, browsers, and graphics tools, generally in converting or batch-processing data or files, damned useful when you need it.
The upshot: pipelining means a tool's utility is extended greatly beyond what functionality is built into the interactive menus.
First of, false premise. Of the standard shells: sh, bash (and minimized variants ash & dash), csh, tcsh, zsh, and ksh, scripting essentially falls into two classes: Bourne compatible and csh compatible. The two syntaxes are largely similar, and within families, backwards compatible.
Second: Because The Shell Is There. I've seen inits written as bash scripts (LNX-BBC). Damned useful on a minimal system, in this case, bootable mini-CD, but Tom's Root Boot, install disks, or a hell of a lot of embedded systems come to mind. Even in larger systems, shell remains in use, very often in system scripts executed automatically at startup or via schedulers. Just 'coz you can't see 'em doesn't mean they don't exist.
A shell session is (from the kernel's point of view) a very slowly read script. The scripting utility's been built in for over three decades, there's no reason to strip it out. Small shells (ash, dash) provide a powerful scripting environment in minimal space -- an installation of Perl, Python, Ruby, etc., would impose far higher storage requirements.
Being able to rattle off one-liners at shell is also useful, particularly as the syntax is familiar: it's what you're using every day. I know many long-time power hacks who've never gone far into other "real" scripting languages simply because a handfull of shell tools provides sufficient power for their needs.
Sure: If you need a full scripting language and can use it, by all means do. There's room for all (given sufficient storage).
Your statements betray a gross lack of understanding and appreciation of what the shell can and does, not to say a gross immaturity regarding Unix/Linux in general.
Um, userContent.css.
Mind, UWIN's /reg virtual filesystem's even cooler. Also note that Microsoft's got a REG.EXE in some subset of platforms that I've been unable to specify exactly.
Which itself is a major hassle of Microsoft systems: finding out just what the command set is, and where it's documented. Rarely anywhere.
Got a reference for specifics? I've looked for CLI alternatives for a number of tools, and I've pretty much uniformly found:
I suspect the ultimate decomposition of this statement is that REG.EXE allows modification of any Registry entry. Which on one basis is CLI access. But hardly what a 'Nix admin would be comfortable with, and lacks significant functionality and utility.
I actually noted something similar when I first started migrating toward Linux...from proprietary Unices (Solaris, HPUX, Irix...).
It was that the Linux userland (command line environment and applications) was far richer. This ~1997.
For starters were the shells (bash and zsh over csh and korn/POSIX shell). If you were really lucky, you might find Solaris with tcsh installed.
But it was specific command-line apps that were the real differentiators. Whether retools (gawk vs. nawk), more secure (ssh vs. telnet), or wholy new (Perl, wget, rsync, Python, mutt....). Proprietary Unices of the time were try to tell me that VUE, or OpenLook, or CDE, or $ENTERPRISE_GUI_ENVIRONMENT_DE_JOUR was All I Needed. Bollox.
The point is that it's a combination of factors which makes GNU/Linux what it is. The Unix Philosophy (simple tools, one thing well) is part of it. But the "OS of the users, by the users, for the users" bit is what keeps the actual useful stuff, not high-glitz and sexy interfaces that look good on brochures and in executive presentations, is also essential.
Microsoft has neither. It has no unifying process / file / user / interaction model, as does Unix. And developing "advanced user tools" is seen as a value-add / bonus-pak sort of thing (as was providing solid utilities or dev tools for proprietary 'Nix). And the result is: you can't comprehend the fundamental principles, and you can't count on a base toolkit on being available -- on different platforms, on different sites, even on different boxes within a site.
Sure, MSFT have provided various answers to 'Nix shell and scripting over the years, and I've seen several of them go from hype to dust. Which is another large part of the problem. On my Linux box, the scripts and trix I first picked up 18 years ago at college Still Work. But the environment hasn't remained static, not by a long shot: it's been incrementally improved and augmented over the years. Unmodified scripts, etc., still work, but new ways are available.
Best of both worlds.
So: your point that it's not the shell, but the shell-based programs, that provide functionality? My point exactly: Microsoft have failed to either tend to providing these tools, or provide an environment in which they could flourish. The result is that "third-party" plug-ins such as Cygwin are vastly preferred for automating and managing such tasks. Works. Cross-platform (both among MSFT and 'Nix variants) portable. And long-term uniform and stable. Not an inconsiderable factor.
Of course there is. And Free Software gleefully steals from the best.
This (and a few other suggestions) suggest you don't subscribe to the Unix tool design philosopy: simple tools that do one thing well. This function is either partially available (command history, reverse search, screen, bang-execution) or would best be supported via a wrapper. As one response noted, Emacs pretty much does this already.
Remember that there are a lot of uses of shell that don't assume interactive use. Hauling around this infrastructure would be bloat and baggage.
This isn't a shell so much as a scripting/programming environment. Python and R come to mind, as well as Emacs (of course).
ERR_BULLSHIT_FACTOR_OVERLOAD
No response deserved, none given.