I've got a local virtual XP instance (mostly for dealing with Exchange brokenness, which I haven't had to do for weeks, so I haven't even fired it up).
My experience is that rdesktop to a remote host (usually a terminal server) gives better performance, and is useful for poorly-written, nonstandard enterprise/corporate applications (fortunately there are fewer of these with time in my experience). A server pool would allow for occasional access as needed, and Google could presumably work out licensing for CALs. Better than pigging out RAM and disk with a virtual instance.
x86/AMD64 based virtual computing still hasn't hit the efficiencies the IBM 360 series boxes had, and GUI shells impose slightly more demanding resource/feedback requirements than something as elegant (coff) as TSO/ISPF.
What's kinda amusing is that WindowMaker (itself a NextStep clone, which is where Aqua has its roots, that being what word+dog is imitating now) has minimize all the way to the left, and close all the way to the right. You gets your two buttons and you likes it.
I've configured my workplace KDE3 desktop (WindowMaker dock bug if anyone has a clue) to be similarly decorated.
The GNOME / Ubuntu silliness is amusing in a sad sort of a way.
Fortunately, this is GNU/Linux. We've other options.
I tested that capability of my car during the test drive. Since most cars now offer at least ABS (and some will give traction control), understanding what happens is very helpful.
Level, straight, deserted stretch of road. Sped up to ~60 MPH. Stood on the brakes. Did that in several different vehicles I tried.
More recently I had the opportunity to drive from San Francisco to Chicago for Christmas. Again, a deserted, level stretch of road, this time: how does the car handle braking at low speeds (10-20 MPH) in a panic stop on snow and ice?
Familiarize yourself with such behavior, in a safe setting.
Understand how your car handles differently on different surfaces: dry asphalt, wet roads, sand/gravel, snow/ice. For my own perspective, sand/gravel are the worst -- they appear without warning, vary greatly in quality, and have a bad habit of jumping up and leaving an impression on your windscreen. Oh well.
In practice, the main problem with panic stops is the idiot following too closely behind you. I defend that space vigorously.
NB: most insurance companies will pay completely fix the windshield if damaged as it's a safety hazard.
While it's true that a full GUI boot of Knoppix won't happen in < 96 MB, and isn't particularly happy in less than ~128 MB, your comment promulgates several fallacies:
You need that much memory to run a bootable distro. False. There are floppy and CD bootable distros which will run in 16-32 MB.
The distro loads to RAM. False Most bootable CDs actually use the "cloop" driver. This is a compressed loopback device, which reads data directly off the CD, decompressing it on access. The CD itself is NOT loaded into RAM, by default, although it can be. Rather the overhead of, say, Knoppix, is that of the applications and X session.
Knoppix and kin offer the analytics necessary to profile a system, what they lack are the heuristics to make a sane statement of what improvements would be useful for a system. The idea of a bootable distro which simply runs an analyzer and produces a report (to be saved to file, printed, etc.) is reasonably straightforward.
Yes, you can run Knoppix entirely in RAM (800+ MB are recommended), and yes, performance of a bootable CD isn't what you'd see from a HD install (in part because of the overhead of reading from CD and performing the on-the-fly decompression). But tests of system speed (memory, CPU, hdparm) should give a pretty good sense of performance characteristics.
There are also floppy-based distros which run entirely in RAM (eg: Tom's Root Boot, Trinux), but they have pretty minimal system requirements.
PowerPoint, Impress, or otherwise, most slide generators will export to HTML as well, either with graphics or just plain text. Would be preferable to PDF IMO.
As for PPT, among my favorite viewers is (I'm serious) strings. Usually strips off all the nonprintable crud, you get just the raw text. Has a remarkably high success rate.
As several people have indicated, Debian's dpkg --get-selections provides you with this. But it gets better.
Application configuration data is pretty much definitionally/etc, which is why you want that backed up.
In the "it gets better" department: Debian, being a policy-based distro, requires that all packages create a directory under/usr/share/doc. Turns out you can use this to recover the data effectively held in your packages database, in the event you wipe out/var. In fact, I've scripted the recovery, after the idea was suggested by Nicholas Petreley, available here (among other places -- Osamu Aoki also includes it in his Debian Reference).
Debian also stores a backup of your packages database (and other important data) in/var/backups.
So, yes, you're covered a couple of different ways, particularly if you maintain backups.
While you can see who's requested your credit report (and I'd recommend you check it at least annually), this has limited utility.
While most financial institutions will prefer to obtain this data directly from the major vendors (Experian / Trans Union, Equifax), the problem is that data are transitive, but data tracing is not. You have no idea who among the entities who've requested your data have passed it on, or let it slip, to others.
You may see the secondary queries and activity resulting from such leakage, however.
What's happening right now is that the basis for assuming identity based on data characteristics is being called into serious question. The leakage must be assumed, and the genie can't be re-corked. Not that I'm happy about this either. But figuring out how to operate in this world, as individuals, as financial institutions, and as merchants, is going to be an interesting problem over the next few years.
It's not that it takes 12 minutes to break into a 'Doze box. If you're targeting a given system, you're talking seconds (if you have to assess its vulnerabilities), fractions of a second if you know its weaknesses -- say, for an out-of-the-box, unsafe-at-any-bandwidth, factory-defective "product".
It's that such a box is cracked, within 12 minutes on average, of going online.
It's as if your car was burgled five times an hour, every hour, every day, 365 days a year. 366 on leap years.
The grandparent may not have an entirely appropriate analogy, but I think the gist is correct: sheeple are being sold something which is unfit for use in standard configurations and environments. This is not a user problem, it is a design defect.
(A) The central repository approach will never provide 100%
coverage. I'm sure you've read the complaints about Debian release
process, but I just point out that even they have 3rd Party "backports".
Also, I read that Fedora 4 conflicts with the Sun Java RPM, apparently
for ideological rather than customer-driven reasons.
Sure, there's a need for third-party repos. If you want an inventory
of my own system, in addition to the standard Debian, non-US, and
security sources, I have marillat (for video codecs) added. For reasons
similar to those I gave above, I try to keep my sources lists from
proliferating beyond what's necessary. The neat thing is that if you
want to go outside the canonical sources, there are several ancillary
sources which can be selected easily.
Beyond this, the unpackaged software on my system is: Realplayer,
Flash, XPDE, and BrowseX. None of which I use significantly. Two are proprietary, and unsurprisingly, concern AV / multimedia formats. The other two are unpackaged free software projects I keep tabs on. Additionally I've got some
locally written tools, which I do use heavily.
In the case of Debian, packaging offers significant advantages to
software developers as well, including a distribution channel,
support, bugtracking, and a significant userbase. For these reasons, if
it's free software, there's good odds it's going to be packaged.
For proprietary software, you've got the options of packaging for
Debian explicitly, or providing a typical Unix installer routine, which
frankly isn't much different from, say, Install Shield or similar in
legacy MS Windows. Realize that packaging systems for GNU/Linux are
worlds beyond what the proprietary Unix world had to offer a few years
ago, or even now.
As for ideology: don't discount it. There's reasons why RMS and the
FSF focus on software freedom, and they're not trivial or incidental.
Sun has long-standing problems with its attempts to control Java, and
they're affecting more than just GNU/Linux distro adoption and
distribution of same.
(B) Most malware doesn't require elevated privileges to perform it's
evil deeds anyway. Administrator is protection on Windows largely
because the malware is written/packaged by the same bunch of dunderheads
that require Admin for other user-level software.
Sure, there's lots of harm you can do in user space, particularly by
way of generating network traffic (spam, DDoS, etc.). But malware has
to get on to your system in the first place. My essay covers this in
more detail but it largely boils down to:
Systems software with security exploits. Most legacy MS Windows
malware is currently delivered through email or Web vectors. While some
relies on social engineering, much still relies on the ability to
execute arbitrary code. Software with such exploits on GNU/Linux is
marked as buggy. In Debian, these would be release-critical bugs, and
would remove the package from consideration for stable release.
A culture in which users are expected to run arbitrary binaries.
"Self extracting archives", self running installers, and the like. In
GNU/Linux, there's much more a policy of having programs which work on
data (so you run tar over an archive, dpkg or rpm on a package file).
And extensive auditing to ensure that these utilities aren't susceptible
to malicious data. This is changing somewhat, but old farts such as
myself tend to complain loudly. The balance between developers,
packagers, and users means that these issues tend to get a much better
hearing on GNU/Linux than they did in the legacy MS Windows world (and
lord knows people warned about unsafe practices for well over a decade).
I've never liked the concept of "opening" a file, nor of "active"
readers. Marketing drives these concepts in the legacy MS Windows
world. Social engineering is more difficult where users are conditioned to not run arbitrary executables. Moreso if s
This is only because GNU/Linux incompatibilities have forced their users
into a single source for nearly all their software.
There's a nugget of truth to that comment, but it misses both more
significant points and differences between the GNU/Linux way and the
Microsoft way.
It also misses the point that you can, largely, install binary
software on different GNU/Linux systems, so long as core dependencies
(usually your glibc version) are satisfied. E.g.: Macromedia Flash,
Opera, Oracle, Realplayer, and the like, generally under/usr/local/ or/opt/. Though honestly I have very little proprietary software on my
system.
The real reason to go within your distro's package management system
for software installation is that it's easier, faster, works better, and
minimizes future administration needs -- rather than managing a slew of
software packages independently, you do a systemwide update. You've
also got a tremendous selection of software -- 15k+ packages in the most
recent Debian stable. There's rarely a compelling reason to go outside
the archive, though you can and are assured the packaging system won't
interfere with your locally installed selections.
The reasons this is possible are largely: sources are available for
the software you're installing (most GNU/Linux software is FSF Free
Software / OSI Open Source), the distro itself doesn't have a horse in
the race (it's not competing with the software developers, unlike the
relationship between Microsoft and its ISVs), and systemwide policies
can be implemented and enforced with a very high degree of uniformity
(particularly in the case of Debian-based distros). There's also three
clearly independent parties involved, each with a major voice in the
process: the software developer, the distro / software packager, and
the users. You get the benefit of review of the application by a users
(independent of both the developer and the distro/packager).
Microsoft simply doesn't have this degree of remove from the system as a
whole -- it's competing with both software developers and its
users over features and control.
The result isn't so much that users are forced to go within
their distro's package management system for software, but that they
choose to do so, and that a healthy distro culture (e.g.:
Debian) provides very strong incentives and feedback loops for both
developers and users to gain by this.
I've explored this at somewhat greater length in an article
discussing malware on Microsoft and GNU/Linux systems respectively, Spyware,
Adware, Windows, GNU/Linux, and Software Culture. Manoj Srivastava
has a very good Why
Linux, Why Debian talk covering the issue from a few other angles
(and better technical understanding of the guts of Debian).
Signals may have been detected from the Cosmos 1 solar sail spacecraft that lost communication during launch on a converted missile fired from a Russian submarine under the Barrents Sea, mission officials said late Tuesday night.
The news came after an all-day search for Cosmos 1, which is intended to demonstrate that a spacecraft can be propelled by the pressure of light from the sun. If it is confirmed that the signals detected by three ground stations did come from Cosmos 1, it means that the craft did achieve orbit, said mission official Jim Cantrell.
Update for June 22 @ 1 a.m. EDT: Mission controllers revealed a short time ago that weak blips of data believed transmitted from the Cosmos 1 spacecraft have been found in recordings at tracking station passes immediately after launch. The Planetary Society originally said that no signals were heard. If the new revelation is true, it suggests that the solar sail did reach some sort of orbit around Earth despite what Russian media reports indicate was a rocket engine problem during ascent. However, the U.S. military's space tracking network has not found the craft and its current orbit is unknown. "So now we search. It could take days to find," the Society said in a statement.
Doesn't happen. You can remember the setting for a given site. Usually this means your first few days of surfing involve a fair bit of swotting cookies, but after that, it's pretty smooth sailing.
...for those who haven't experience FFX cookie-munching goodness yet:
You can specify (default choice) "remember this choice for all cookies from this site", so you only have to ack/deny cookies for a site once. The first few days with FFX you'll bee hitting the 'esc' key frequently, but if your browsing patterns are typical, you'll cover most frequently visited sites quickly.
Options are "allow", "deny", or "session only". Session cookies are allowed for the duration of a browsing session, but are not saved permanently. This means that sites which require cookies for navigation will work, but cross-session user tracking largely won't. The longbeards will worry about possible workarounds, but this seems to be a pretty good fix.
Third plus (programmers can't count...): you can manage cookies and sites through a cookie manager interface, so that if you happen to deny a site's cookies and later need to allow them, you can, easily.
And there's a password manager for handling authentication to sites (such as Slashdot) for which you don't chose to retain a permanent cookie.
Nothing off the top of my head, though several recent solar storm writeups have mentioned disturbances to the Canadian electrical grid, some years back. Google says Quebec, 1989.
I've been attending the USENIX NT and LISA NT (Large Installation Systems Administration for NT) conference in downtown Seattle this week.
One of those magical Microsoft moments(tm) happened yesterday and I thought that I'd share. Non-geeks may not find this funny at all, but those in geekdom (particularly UNIX geekdom) will appreciate it.
Greg Sullivan, a Microsoft product manager (henceforth MPM), was holding forth on a forthcoming product that will provide Unix style scripting and shell services on NT for compatibility and to leverage UNIX expertise that moves to the NT platform. The product suite includes the MKS (Mortise Kern Systems) windowing Korn shell, a windowing PERL, and lots of goodies like awk, sed and grep. It actually fills a nice niche for which other products (like the MKS suite) have either been too highly priced or not well enough integrated.
An older man, probably mid-50s, stands up in the back of the room and asserts that Microsoft could have done better with their choice of Korn shell. He asks if they had considered others that are more compatible with existing UNIX versions of KSH.
The MPM said that the MKS shell was pretty compatible and should be able to run all UNIX scripts.
The questioner again asserted that the MKS shell was not very compatible and didn't do a lot of things right that are defined in the KSH language spec.
The MPM asserted again that the shell was pretty compatible and should work quite well.
This assertion and counter assertion went back and forth for a bit, when another fellow member of the audience announced to the MPM that the questioner was, in fact David Korn of AT&T (now Lucent) Bell Labs. (David Korn is the author of the Korn shell)
Uproarious laughter burst forth from the audience, and it was one of the only times that I have seen a (by then pink cheeked) MPM lost for words or momentarily lacking the usual unflappable confidence. So, what's a body to do when Microsoft reality collides with everyone elses?
Shell programs should support the mouse, should respect theme color preferences and should use the X clipboard for copy and paste. There are many other ways in which the CLI could benefit from a closer integration with the GUI.
Written by someone who clearly fails to understand scoping.
The shell was written when the primary human-computer interface was the teletype. It's transitioned exceptionally well from hardcopy to bitmapped (GUI) display modes. Expecting the shell to be knowledgable about its graphical context is a really bad study in domain scoping. Look for example, at the limitations of the MS Windows "DOS Box", with a small set of fixed font sizes, explicit window sizing, and lack of free-form window resizing. If you've seen Cygwin's rxvt you've got a slight idea of what a decent text terminal window can do.
Coding GUI functionality directly into the shell loses on several counts:
It's code bloat not necessary for 99.99% of shell invocations (scripts).
It's functionality largely available elsewhere.
It's functionality which hard-codes assumptions about windowing environments which are reasonable now but which are likely to be horribly broken in 2035 (Bourne shell's been around for 30+ years, think about it).
The usual way to support a function in the Unix philosophy is to write a tool to handle it. Several of these include GNU screen, gpm (a mouse management interface for console), and/or mouse-aware terminals (GNOME terminal and Konsole are both mouse-aware, though I personally prefer rxvt). There's even an X Windows scripting environment (whose name I forget) and tools for accessing the X clipboard directly. Though frankly, highlight & paste are pretty damned easy for me.
There are "CLI" (more accurately, ncurses) applications which support mouse interactions. w3m, mc (midnight commander), links, and emacs all come to mind. There's a slight win to this, but not massive. I recall HPUX's 'elm' implementation was also mouse-aware, I think....
Support your GUI operations through your GUI, window manager, and/or terminal application. Don't overload the shell. If you've got a specific app which may benefit directly, great.
Better: Write a spec of the operations which you'd like to be able to do. Odds are it's not worth the hassle.
The other issue not addressed is that the Earth's magnetosphere is neither uniform nor static.
It is significantly compressed on the Sunward side, and elongated on the opposite side, through which any geostationary satellite (and hence space tether) would cross on a 24 hour basis.
Additionally, there is significant displacement as a result of variable solar activity (aside: WindowMaker's 'wmspaceweather' dock app is oddly addictive). I believe other events can create flux as well, both external and internal to the Earth.
Given the length of the tether, even minor effects will be significantly magnified.
Nothing remotely of this scale has been attempted. Structures vastly smaller than this scale have had pronounced effects. This includes both tethered satellites, and earth-based power grids, and both have experience unexpected catastrophic failures due to widespread magnetic events, natural (again: solar events, magnetosphere flux) and man-made (nuclear blasts).
One: IIS is bundled with stock legacy MS Windows desktops. Amateur installs probably blow away Apache numbers.
Two: If they're still published, take a look at Alexa's stats. When I took a look at their top sites November 2003, representation of IIS in Fortune 100 sites was high. But representation of Apache in actual top-ranked websites was far higher. Moral: it's easier to sell to those vulnerable to manipulation than to those who live and die by their website's performance.
From the top 20 (again: Nov 2003):
Apache: 7
MS IIS: 7
Netscape-Enterprise: 2
GWS: 1
Stronghold: 1
Unknown: 2
If memory serves, GWS is Apache-influenced, and I suspect the "unknowns" are also Apache.
Hosts are: 6 Linux, 6 FreeBSD, 5 Windows 2000,, 1 Solaris 8, 1 NT4/Windows 98, 1 unknown. By which I'll presume that Apache and other 'Nix-based webservers outnumber Windows 3:1, among top-20 websites.
www.yahoo.com is running unknown on FreeBSD.
www.msn.com is running Microsoft-IIS/5.0 on Windows 2000.
www.daum.net is running Apache on Linux.
www.google.com is running GWS/2.1 on Linux.
www.naver.com is running Apache/1.3.26 (Unix) on Linux.
www.yahoo.co.jp is running unknown on FreeBSD.
www.microsoft.com is running Microsoft-IIS/6.0 on Linux.
www.passport.net is running Microsoft-IIS/5.0 on Windows 2000.
www.ebay.com is running Microsoft-IIS/4.0 on NT4/Windows 98.
www.sina.com.cn is running Apache/2.0.45 (Unix) behind a computer running FreeBSD.
www.sayclub.com is running Apache/1.3.28 (Unix) mod_ssl/2.8.15 OpenSSL/0.9.6a on FreeBSD.
www.bugs.co.kr is running Microsoft-IIS/5.0 on Windows 2000.
www.amazon.com is running Stronghold/2.4.2 Apache/1.3.6 C2NetEU/2412 (Unix) mod_fastcgi/2.2.12 on Linux.
www.163.com is running Apache/1.3.26 (Unix) behind a computer running FreeBSD.
www.netmarble.net is running Microsoft-IIS/5.0 on Windows 2000.
www.sohu.com is running Apache/1.3.27 (Unix) mod_gzip/1.3.19.1a behind a computer running unknown.
www.go.com is running Microsoft-IIS/5.0 on Windows 2000.
www.3721.com is running Apache/1.3.26 (Unix) PHP/4.2.2 on FreeBSD.
www.nate.com is running Netscape-Enterprise/6.0 on Solaris 8.
www.cnn.com is running Netscape-Enterprise/6.1 AOL on Linux.
Campaign effectiveness, monitoring & evaluation requires before-and-after measurement, and preferably a control group (or period).
What we've got is s single-point reference which suggests that the majority of SMBs are considering GNU/Linux. Which is pretty damned substantial. Oh, and it's recycled from a release a month or so back... which similarly did some really impressive spinning of stats to make strong Linux support sound weak.
Clearly the work of those not expecting critical readers.
Slashdot Mirror
I've got a local virtual XP instance (mostly for dealing with Exchange brokenness, which I haven't had to do for weeks, so I haven't even fired it up). My experience is that rdesktop to a remote host (usually a terminal server) gives better performance, and is useful for poorly-written, nonstandard enterprise/corporate applications (fortunately there are fewer of these with time in my experience). A server pool would allow for occasional access as needed, and Google could presumably work out licensing for CALs. Better than pigging out RAM and disk with a virtual instance. x86/AMD64 based virtual computing still hasn't hit the efficiencies the IBM 360 series boxes had, and GUI shells impose slightly more demanding resource/feedback requirements than something as elegant (coff) as TSO/ISPF.
$ grep -C4 font-family userContent.css
/* FONT {
/* OK, undo the damage for <pre>. */
BODY {
padding: 8px 8px;
font-family: serif !important;
}
--
* {
font-size: 100% !important;
line-height: normal !important;
font-family: serif !important;
}
--
* color: inherit !important;
* background: inherit !important;
* font-family: inherit !important;
* font-size: inherit !important;
* }
*/
--
PRE, TT, CODE {
font-family: monospace !important;
}
--
H1, H2, H3, H4, H5, H6 {
font-weight: bold !important;
font-family: sans-serif !important;
font-weight: bold !important;
padding-bottom: 0.25em;
}
--
textarea, directory {
font-family: "Courier New", monospace !important;
font-size: 90% !important;
}
What's kinda amusing is that WindowMaker (itself a NextStep clone, which is where Aqua has its roots, that being what word+dog is imitating now) has minimize all the way to the left, and close all the way to the right. You gets your two buttons and you likes it. I've configured my workplace KDE3 desktop (WindowMaker dock bug if anyone has a clue) to be similarly decorated. The GNOME / Ubuntu silliness is amusing in a sad sort of a way. Fortunately, this is GNU/Linux. We've other options.
I tested that capability of my car during the test drive. Since most cars now offer at least ABS (and some will give traction control), understanding what happens is very helpful. Level, straight, deserted stretch of road. Sped up to ~60 MPH. Stood on the brakes. Did that in several different vehicles I tried. More recently I had the opportunity to drive from San Francisco to Chicago for Christmas. Again, a deserted, level stretch of road, this time: how does the car handle braking at low speeds (10-20 MPH) in a panic stop on snow and ice? Familiarize yourself with such behavior, in a safe setting. Understand how your car handles differently on different surfaces: dry asphalt, wet roads, sand/gravel, snow/ice. For my own perspective, sand/gravel are the worst -- they appear without warning, vary greatly in quality, and have a bad habit of jumping up and leaving an impression on your windscreen. Oh well. In practice, the main problem with panic stops is the idiot following too closely behind you. I defend that space vigorously. NB: most insurance companies will pay completely fix the windshield if damaged as it's a safety hazard.
While it's true that a full GUI boot of Knoppix won't happen in < 96 MB, and isn't particularly happy in less than ~128 MB, your comment promulgates several fallacies:
Knoppix and kin offer the analytics necessary to profile a system, what they lack are the heuristics to make a sane statement of what improvements would be useful for a system. The idea of a bootable distro which simply runs an analyzer and produces a report (to be saved to file, printed, etc.) is reasonably straightforward.
Yes, you can run Knoppix entirely in RAM (800+ MB are recommended), and yes, performance of a bootable CD isn't what you'd see from a HD install (in part because of the overhead of reading from CD and performing the on-the-fly decompression). But tests of system speed (memory, CPU, hdparm) should give a pretty good sense of performance characteristics.
There are also floppy-based distros which run entirely in RAM (eg: Tom's Root Boot, Trinux), but they have pretty minimal system requirements.
PowerPoint, Impress, or otherwise, most slide generators will export to HTML as well, either with graphics or just plain text. Would be preferable to PDF IMO.
As for PPT, among my favorite viewers is (I'm serious) strings. Usually strips off all the nonprintable crud, you get just the raw text. Has a remarkably high success rate.
Cool. I'll add them here.
As several people have indicated, Debian's dpkg --get-selections provides you with this. But it gets better.
Application configuration data is pretty much definitionally /etc, which is why you want that backed up.
In the "it gets better" department: Debian, being a policy-based distro, requires that all packages create a directory under /usr/share/doc. Turns out you can use this to recover the data effectively held in your packages database, in the event you wipe out /var. In fact, I've scripted the recovery, after the idea was suggested by Nicholas Petreley, available here (among other places -- Osamu Aoki also includes it in his Debian Reference).
Debian also stores a backup of your packages database (and other important data) in /var/backups.
So, yes, you're covered a couple of different ways, particularly if you maintain backups.
While you can see who's requested your credit report (and I'd recommend you check it at least annually), this has limited utility.
While most financial institutions will prefer to obtain this data directly from the major vendors (Experian / Trans Union, Equifax), the problem is that data are transitive, but data tracing is not. You have no idea who among the entities who've requested your data have passed it on, or let it slip, to others.
You may see the secondary queries and activity resulting from such leakage, however.
What's happening right now is that the basis for assuming identity based on data characteristics is being called into serious question. The leakage must be assumed, and the genie can't be re-corked. Not that I'm happy about this either. But figuring out how to operate in this world, as individuals, as financial institutions, and as merchants, is going to be an interesting problem over the next few years.
It's not that it takes 12 minutes to break into a 'Doze box. If you're targeting a given system, you're talking seconds (if you have to assess its vulnerabilities), fractions of a second if you know its weaknesses -- say, for an out-of-the-box, unsafe-at-any-bandwidth, factory-defective "product".
It's that such a box is cracked, within 12 minutes on average, of going online.
It's as if your car was burgled five times an hour, every hour, every day, 365 days a year. 366 on leap years.
The grandparent may not have an entirely appropriate analogy, but I think the gist is correct: sheeple are being sold something which is unfit for use in standard configurations and environments. This is not a user problem, it is a design defect.
No..
They're in boats.
Sure, there's a need for third-party repos. If you want an inventory of my own system, in addition to the standard Debian, non-US, and security sources, I have marillat (for video codecs) added. For reasons similar to those I gave above, I try to keep my sources lists from proliferating beyond what's necessary. The neat thing is that if you want to go outside the canonical sources, there are several ancillary sources which can be selected easily.
Beyond this, the unpackaged software on my system is: Realplayer, Flash, XPDE, and BrowseX. None of which I use significantly. Two are proprietary, and unsurprisingly, concern AV / multimedia formats. The other two are unpackaged free software projects I keep tabs on. Additionally I've got some locally written tools, which I do use heavily.
In the case of Debian, packaging offers significant advantages to software developers as well, including a distribution channel, support, bugtracking, and a significant userbase. For these reasons, if it's free software, there's good odds it's going to be packaged.
For proprietary software, you've got the options of packaging for Debian explicitly, or providing a typical Unix installer routine, which frankly isn't much different from, say, Install Shield or similar in legacy MS Windows. Realize that packaging systems for GNU/Linux are worlds beyond what the proprietary Unix world had to offer a few years ago, or even now.
As for ideology: don't discount it. There's reasons why RMS and the FSF focus on software freedom, and they're not trivial or incidental. Sun has long-standing problems with its attempts to control Java, and they're affecting more than just GNU/Linux distro adoption and distribution of same.
Sure, there's lots of harm you can do in user space, particularly by way of generating network traffic (spam, DDoS, etc.). But malware has to get on to your system in the first place. My essay covers this in more detail but it largely boils down to:
There's a nugget of truth to that comment, but it misses both more significant points and differences between the GNU/Linux way and the Microsoft way.
It also misses the point that you can, largely, install binary software on different GNU/Linux systems, so long as core dependencies (usually your glibc version) are satisfied. E.g.: Macromedia Flash, Opera, Oracle, Realplayer, and the like, generally under /usr/local/ or /opt/. Though honestly I have very little proprietary software on my
system.
The real reason to go within your distro's package management system for software installation is that it's easier, faster, works better, and minimizes future administration needs -- rather than managing a slew of software packages independently, you do a systemwide update. You've also got a tremendous selection of software -- 15k+ packages in the most recent Debian stable. There's rarely a compelling reason to go outside the archive, though you can and are assured the packaging system won't interfere with your locally installed selections.
The reasons this is possible are largely: sources are available for the software you're installing (most GNU/Linux software is FSF Free Software / OSI Open Source), the distro itself doesn't have a horse in the race (it's not competing with the software developers, unlike the relationship between Microsoft and its ISVs), and systemwide policies can be implemented and enforced with a very high degree of uniformity (particularly in the case of Debian-based distros). There's also three clearly independent parties involved, each with a major voice in the process: the software developer, the distro / software packager, and the users. You get the benefit of review of the application by a users (independent of both the developer and the distro/packager). Microsoft simply doesn't have this degree of remove from the system as a whole -- it's competing with both software developers and its users over features and control.
The result isn't so much that users are forced to go within their distro's package management system for software, but that they choose to do so, and that a healthy distro culture (e.g.: Debian) provides very strong incentives and feedback loops for both developers and users to gain by this.
I've explored this at somewhat greater length in an article discussing malware on Microsoft and GNU/Linux systems respectively, Spyware, Adware, Windows, GNU/Linux, and Software Culture. Manoj Srivastava has a very good Why Linux, Why Debian talk covering the issue from a few other angles (and better technical understanding of the guts of Debian).
Spaceflight.com adds:
Doesn't happen. You can remember the setting for a given site. Usually this means your first few days of surfing involve a fair bit of swotting cookies, but after that, it's pretty smooth sailing.
...for those who haven't experience FFX cookie-munching goodness yet:
And there's a password manager for handling authentication to sites (such as Slashdot) for which you don't chose to retain a permanent cookie.
Nothing off the top of my head, though several recent solar storm writeups have mentioned disturbances to the Canadian electrical grid, some years back. Google says Quebec, 1989.
Glen McCready's got a good item on it, when Microsoft reality conllides with everyone elses(Fri, 28 Aug 1998 09:26:58 -0400):
Written by someone who clearly fails to understand scoping.
The shell was written when the primary human-computer interface was the teletype. It's transitioned exceptionally well from hardcopy to bitmapped (GUI) display modes. Expecting the shell to be knowledgable about its graphical context is a really bad study in domain scoping. Look for example, at the limitations of the MS Windows "DOS Box", with a small set of fixed font sizes, explicit window sizing, and lack of free-form window resizing. If you've seen Cygwin's rxvt you've got a slight idea of what a decent text terminal window can do.
Coding GUI functionality directly into the shell loses on several counts:
The usual way to support a function in the Unix philosophy is to write a tool to handle it. Several of these include GNU screen, gpm (a mouse management interface for console), and/or mouse-aware terminals (GNOME terminal and Konsole are both mouse-aware, though I personally prefer rxvt). There's even an X Windows scripting environment (whose name I forget) and tools for accessing the X clipboard directly. Though frankly, highlight & paste are pretty damned easy for me.
There are "CLI" (more accurately, ncurses) applications which support mouse interactions. w3m, mc (midnight commander), links, and emacs all come to mind. There's a slight win to this, but not massive. I recall HPUX's 'elm' implementation was also mouse-aware, I think....
Support your GUI operations through your GUI, window manager, and/or terminal application. Don't overload the shell. If you've got a specific app which may benefit directly, great.
Better: Write a spec of the operations which you'd like to be able to do. Odds are it's not worth the hassle.
lsh.
The other issue not addressed is that the Earth's magnetosphere is neither uniform nor static.
It is significantly compressed on the Sunward side, and elongated on the opposite side, through which any geostationary satellite (and hence space tether) would cross on a 24 hour basis.
Additionally, there is significant displacement as a result of variable solar activity (aside: WindowMaker's 'wmspaceweather' dock app is oddly addictive). I believe other events can create flux as well, both external and internal to the Earth.
Given the length of the tether, even minor effects will be significantly magnified.
Nothing remotely of this scale has been attempted. Structures vastly smaller than this scale have had pronounced effects. This includes both tethered satellites, and earth-based power grids, and both have experience unexpected catastrophic failures due to widespread magnetic events, natural (again: solar events, magnetosphere flux) and man-made (nuclear blasts).
Two points:
One: IIS is bundled with stock legacy MS Windows desktops. Amateur installs probably blow away Apache numbers.
Two: If they're still published, take a look at Alexa's stats. When I took a look at their top sites November 2003, representation of IIS in Fortune 100 sites was high. But representation of Apache in actual top-ranked websites was far higher. Moral: it's easier to sell to those vulnerable to manipulation than to those who live and die by their website's performance.
From the top 20 (again: Nov 2003):
If memory serves, GWS is Apache-influenced, and I suspect the "unknowns" are also Apache.
Hosts are: 6 Linux, 6 FreeBSD, 5 Windows 2000,, 1 Solaris 8, 1 NT4/Windows 98, 1 unknown. By which I'll presume that Apache and other 'Nix-based webservers outnumber Windows 3:1, among top-20 websites.
ObIRepliedToAnAC: IHBT, IHL, HAND.
Yessir ladies and gentlefolk, we has a Winnah!
Campaign effectiveness, monitoring & evaluation requires before-and-after measurement, and preferably a control group (or period).
What we've got is s single-point reference which suggests that the majority of SMBs are considering GNU/Linux. Which is pretty damned substantial. Oh, and it's recycled from a release a month or so back ... which similarly did some really impressive spinning of stats to make strong Linux support sound weak.
Clearly the work of those not expecting critical readers.
Had a few errors indicating not enough child prcesses available. If your systems aren't pegged elsewhere, might try upping those limits.
Greets to PJ.