Right, but the experience is not the same. In IE it brings up the files and folder structure in an explorer like shell. In FF it lists them all as a web directory.
The point being, you don't need to have Internet Explorer in Windows to get the behaviour of trying to use your Web browser as your system's file manager.
Processing \\servername\sharename paths is a native Windows I/O function, and prettying them up as file://servername/sharename or smb://servername/sharename doesn't change that much.
If you want to use your native file manager, use the native file manager. In this case, the embedding is going the other way--IE has the file tree control embedded, so it can give you an Explorer (as opposed to Internet Explorer) view of the filesystem.
Try this: Start -> Run -> \\servername\sharename
Or to get there by browsing, use Network Neighborhood.
Or in an Explorer (not Internet...) window, type \\servername\sharename in the Address bar.
On Mac OS X, Apple has a neat (and somewhat disturbing) trick. Any protocol that can be treated as disk storage can be mounted as a filing device (so all programs can use it). So you can "Connect to server" with "ftp://someserver/" and the FTP site shows up on your desktop. Or "http://davserver/" for WebDAV (Microsoft calls 'em Web Folders I believe).
From that point, the Finder or any file manager you like, to browse.
I think the reason why people are reading this as IPv6 work is that they are still talking about class-based addressing:
Structurally, the IP address is broken into a network identifying portion (also known as an IP network prefix), a host identifying portion, and some bits used to identify one of three different formats of the IP address.
Apparently, they missed the entire industry switching to classless inter-domain routing over 10 years ago. (Which is what freed up enough address space to let IPv4 survive as long as it has; the old class-based allocation was amazingly wasteful. Which 126 organizations really needed 16,777,214 hosts on the globally-routable network? More to the point, how many organizations needed 65,534 hosts globally-routable? Turned out, very few.)
And, the punch cards are in a "known" format. With a suitable backing (black sheet of cardboard), you could scan the punched cards, and have an image processing program turn it into bytes.
A good-size flatbend scanner could probably take 3-4 cards at a time.
Similarly, an old PDP has enough circuitry made from discrete components that you can repair it, even if the vendor won't. Failing that, repairing the disk assembly and interfacing to a modern machine is possible; the wire protocols are well-documented and the disk layout is known.
Old disk packs (and tapes) had a low bits-per-inch rate; you could actually spray them with a coating that would reveal the magnetic patterns visually, then decode by hand.
How about when the control board fries on a 3-year-old IDE disk? If you can get the same controller, you could try and swap it. Now how about the spindle motor failing? Or the voice-coil actuator for the head assembly?
Just because it isn't old doesn't mean you'll be able to get your data off of failed hardware.
But, when the PDP is still in service, you can transfer everything on its drives to other machines. Serial links, networking, all sorts of chances to transfer data.
All of which only works if the files aren't tied to a particular host by some DRM scheme. I've still got files that started on an Amiga, went through a Mac, and are now on Linux.
I would be extremely wary of anyone who claims that their UNIX class operating system is immune to resource exhaustion from a local user.
There are some things that Linux responds to in a much worse way than some of the older UNIXes.
I wrote a fork() bomb at work to demonstrate what a buggy program had just done to one of our Big Sun Machines. It was out of process slots (entirely--because the per-user limit was something like 30,000, and with the number of users on the system with hundreds of unreaped child processes it overloaded the kernel process table).
while(-1!=fork());
I've done things like that on AIX machines I was testing in the past, and sure, they get pretty unresponsive and it's hell to kill off; you basically have to switch to that user and carefully kill -9 -1. (Careful to make sure you don't do it as root....) But if you don't try to hide the bomb, CTRL-C eventually goes through.
It wedged my Linux machine so hard that caps lock stopped responding. (My test for "is it X11 that's dead or the whole kernel".) CTRL-C or CTRL-\ just weren't going to happen... I tried for 15 minutes before hitting the power button.
And I've got a 4095 per-user process limit. But as fork() starts failing in some processes, other processes get scheduled to try fork() themselves. So you get over 4000 processes all trying to fork() at once, and nothing else gets time on the CPU.
A different scheduling algorithm could mitigate some of the impact of a forkbomb on Linux. Similar to the way Linux will dump all its VM pages in favor of allocating them to disk buffers; Linux's approach to some things may be great for performance, but can make things worse when things go wrong.
filling it with low quality cracker-box houses built on small lots.
But the construction isn't much better on those "monster home" subdivisions you see in places like western New Jersey. $700,000 houses, cheap frame construction, no corners left un-cut. Decent-sized lots, though--but there won't be any shade trees for a couple of decades at least.
The ones with brick veneer only have it on the front, the rest of the house is plastic siding. That would never sell here in Canada; you brick the front of the house, you'd better brick the other 3 sides. (Not that our new home builders are much better, but at least you get a crappy house an hour and a half from the big city for under $200,000. Heck, that far from the city it'd probably be under $100,000. But who wants to be that far away?)
He may have been silly, or funny, but it's no joke. Search Google for "search engine" (with or without the quotes). They're now down to 6th place without quotes, 8th with.
I never understand people who favor Apple over Microsoft.
To a large extent, Apple learned from their "wholly proprietary" past. They no longer have their own disk format (remember the multi-speed 800K floppies, SCSI drives formatted to something other than 512 bytes/sector), they generally use standard parts.
Granted, in some cases they were a bit ahead of the game, and chose a standard that wound up failing to become commoditized--though I think they switched from mainly-SCSI to mainly-IDE at about the right time. IDE drives were reaching a good maturity level, and SCSI just wasn't coming down in price.
Similarly, they've chosen RAM standards that failed, or were quickly eclipsed by a newer one. Trying to find RAM for some older machines makes it feel like you're trying to get proprietary parts... but trying to find working combinations of 60ns EDO SIMMS for an old PC isn't much better.
As others have pointed out, USB was Intel's baby, and Apple made it popular. There's a whole mess of USB gear that doesn't say word 1 about working on a Mac that plugs in and works fine. Similarly, FireWire is Apple's version of serial SCSI, that they fed back into the SCSI-III standard. (Along with IBM SSA and FC-AL for other serial SCSI transports.)
I don't really have a problem with Apple trying to find out who's violating their confidentiality contracts. These aren't people who are reporting about security problems, or other issues where Apple might be trying to hide fault or liability. They're new product directions.
The only thing I really don't like about their current operations is how they don't seem to be willing to let other companies generate protected AAC files for the iPod. But, we only have Real's word on the other side of that coin--how many other companies have gone to Apple and asked to license the tech?
But, it also important to keep an eye on Apple. Like you said, they've been there in the past, and they might try to go back there. I liked my Amigas, but I don't think wholly-proprietary hardware is good for the consumer. Similarly, I don't think proprietary software is good for the consumer, either. But I'm keeping my Macs because they Just Work; something I've yet to get Linux to do with the collection of junk I want to use with it.
(Though, in the case of software, a proprietary program with an open data format isn't a big deal--anyone can build a proprietary web server or browser that works well with the rest of the Internet. Look at Opera.)
Asking photo ID when a credit card is presented protects against identity theft.
Really? You've now given someone your full address, a photo of yourself, a valid credit card WITH the "security code" and your signature on both documents. Keep in mind, when forging signatures, it is important to not make every one identical, so two from you is a big help. And they've now got two numbers they can use to search for further information.
Checking ID may protect you from credit card theft, but it HELPS identity theft.
Calling in a lost or stolen credit card promptly is much more useful. But make sure you always keep credit cards where you'll notice their loss.
I think all credit card companies require phone-in "activiation" before you can use the card, so lifting a brand-new card out of a mailbox should be a thing of the past. (And the ones I deal with no longer use Caller ID to quickly activate your card if you call from home--someone can easily pop the cover off the phone junction box and use my phone line with just a pair of test clips on a regular desk phone.)
Lead-Acid is older but I don't remember them in sizes smaller than motorcycle batteries.
They're around. Sealed lead-acid gel cells can be had as small as about 0.5" x 1.5" x 2", and about 0.2 lb. (That one is two cells, 4V total,.5 Ah.)
If you've got a UPS, you'll probably have one or two SLA batteries in it, they're usually about half the size of a motorcycle battery. And, more importantly, won't dribble sulphuric acid all over the place if you tip the UPS over. And you won't kill it by forgetting to check the water level that ONE time....
The same sorts of batteries are used in emergency lighting, burglar alarms, and things like that. Fairly easy to get at electronic components stores. Generally you want to use a 20h charge (current 1/20th the Ah capacity), unlike the 10h charge typical for flooded lead-acid. But most of the times you see an SLA, it will be connected to a brain-dead trickle charger; the sort of thing that would destroy a NiCD or NiMH (both respond poorly to overcharging).
Reminds me, it's time to replace the battery on one of my UPSes.
My PowerBook has an estimated battery life of 3 hours but never gets more than 1.5.
Of course, all that depends on the age of the battery and the use profile. Like, is Engergy Saver set to slow down the CPU? Are you running big number crunching AltiVec code?
My iBook is also rated for about 3 hours, and it's now two years old. To actually get through a 2.5-3 hour movie, I have to turn off Airport. And DVD playback ain't cheap on the power budget.
I did forget to bring a paper notebook to a tradeshow once, and so I used the iBook and xemacs to take notes in the seminars and BOFs. I got 8 hours of run-time out of the machine--by turing the display backlight off and touch-typing blind.
Mine's now to the point where I'm going to seriously consider thinking about maybe getting a new battery for it.
Not that Apple's never had misleading claims in the past. But, unlike other makers, then tend to get hit with a class action suit and have to compensate their customers. (Like the iMac DV settlement, which didn't apply to non-Americans. Fortunately I didn't buy it for the 'DV' part.)
So you needed a "declaration ROM" on a NuBus card. The same sort of thing is present in PCI as well; same with MCA and Zorro. In fact, non-PnP ISA is the only bus I can think of that DOESN'T have an on-card identity ROM of some sort. You didn't have to have drivers on the card; if you didn't, it couldn't be used until the system came up.
But how hard was it to find out what goes in that ROM?
A little Googling turns up NuBus is a Texas Instruments trademark of something based on an MIT design. NuBus is IEEE standard 1196; so getting data on it isn't going to be tough. (Though it probably won't be free.) A few hardware notes from Apple say, emphatically, that you had better follow the IEEE specs or you'll be in trouble on some models of Macintosh.
Macintosh Toolbox ROM did not use a whitelist for NuBus cards based on their declaration ROM. Compliant cards were required to have that ROM so the bus could configure itself, and then the system could load suitable drivers. Again, to this day, PCI does the same thing--only it is integrated into the PCI bus controller on the card. Back in NuBus's day, integration wasn't as complete, so the NuBus controller on the card was in several chips; one of them a ROM.
Most faults that take a long time to appear are thermal faults; as a component heats and cools, a circuit trace cracks. When it cools off the circuit re-forms, and as it warms up, it breaks again.
Sometimes you get the opposite behaviour, and the thermal expansion keeps the circuit closed, and it fails when it cools off. This is the one that takes out servers that "ran for months until that power failure".
The iBook logic problem (I'm on my 3rd logic board now) is a fairly classic thermal fault; when it first starts, shutting it off and waiting a while will give you a bit of run-time; eventually, it just gets so bad that you can't even do that.
I used that bit of run-time to deauthorize my iBook from the iTMS, as the computer's ID is associated with the Ethernet MAC.
One nice thing; you can still get to Target Disk Mode when the logic board problem takes out your iBook, so you can back up the very last changes you had made. Or erase the system completely if you have... interesting files on it that you don't want the repair depot guys playing with.
Of course, the repair centre should know about thermals and any LBRP candidate should be run for several hours with the display active.
Another thing about the logic board problem: You can't start up when there is no video. So if you had turned it off to try and get past the problem, it won't stay on unless you go to Target Disk Mode. (Hold down T at the chime; your iBook is now a really expensive self-powered FireWire disk.)
One last thing on the logic boards: My first replacement board lasted only 3 months. When I was merging the machine specific preferences files, I noticed that the first replacement had a lower Ethernet MAC than the original board. But the second replacement had a much higher MAC than the original; in fact, it had a whole new manufacturer ID (still one assigned to Apple).
So I suspect that some old stock was being flushed out through the repair program. Or, worse, they were putting logic boards refurbed from some other fault into the replacement stream. (Hmmm, what's the "selling used equipment as new" and "failing to honour service and warranty" contracts bit about? The Forbes article only talked about retailers forced out of business.)
A number of packaging utilities (mainly those not used on consumer-targetted OSes like Mac OS X and Windows) track checksums, sizes and permissions of installed files. At least, those that the packager indicates are expected to be non-mutable after install--so, typically, the contents of/usr, but not/etc or/var.
The downside is, the repository of known sizes and checksums are stored on local disk. The upside is they are also recorded, in a fairly easy to retrieve form, on the original install media and are the updates are recorded with each patch file also.
So a good sysadmin doesn't have to track all that, because a good system already did it for him. A good sysadmin would want to make sure there's a way to get into the system from known-good media and access the checksum database from alternate media. Instead of trying to rebuild the DB from install media, it could be just as good to back up the DB when the system is in a known good state. (Just after clean install; before each update, verify the system from clean boot and an offline copy of the checksum db, and so on.)
On AIX, use "lppchk", Solaris has "pkgchk", and RPM-based Linuxes have "rpm --verify".
OK, I lied about Mac OS X, though I don't know of any way to verify the information. 'lsbom' will list the information from a bill of materials file, and these are kept in/Library/Recipts/$PackageName. Disk Utility's "Repair Permissions" uses at least part of the information; maybe I'll intentionally screw up a system file and see if it reports a size verification or checksum failure on it.
Now, of course, anything you put on a system which doesn't use the system package manager won't be recorded in the system package database. So you can't find out it is there, or validate it, or anything.
From my recollections of working with InstallShield a few years ago, it does not track this kind of information at all. I could be wrong about this, it's been quite a while--NT 4.0 was still new!
i'm pretty sure there's a clause in the EULA that prohibits you from running Office on anything other than Windows or "supported" emulators, like Virtual PC
Virtual PC isn't the same sort of beast at all; Virtual PC emulates the hardware, you still need a copy of Windows. (It may have accelerators for some of the API entry points written in native code, but that is done on top of the installed Windows.)
WINE is a new and original implementation of the Win32 API from first principles (the documentation, such as it is), combined with a whole lot of experimental work to figure out just how Microsoft's various implementations of Win32 (Win32s, Win95 series, WinNT series) differ from the docs.
So, Microsoft can't claim you aren't running it on Windows with Virtual PC (or VMWare or other hardware emulators or virtualizers), because you do have Windows. You don't, necessarily, have an Intel CPU, but that's Intel's and AMD's problem.
With Mac OS, keep in mind, there's no such thing as a "Full Retail" copy of Mac OS X--in fact, of any Mac OS except the version that was licensed for clones. All Macs come with Mac OS, so all copies of Mac OS are actually upgrades, not full versions for an OS-less machine.
While a number of posters have been pointing out the differences between patching the Windows OS vs. patching the 1000s of optional packages available with most Linux distributions, I have a different question.
How many bugs are fixed by a typical Windows security patch? On the W2K machines where I work, the Software Update thing will quite often show up with 5-7 patches, all of which contain something like the following description:
A flaw in Windows may allow an attacker to take full control of your system.
There could be dozens of bugs fixed in one of those patches. Or there could be just one--you have no way of knowing. I don't even know which files were changed.
Whereas, at least the Red Hat errata I've dealt with, Red Hat lists the all the bugs resolved in a single update (relative the the prior update for that package).
So counting patches is just useless, for many reasons. You need to count the number of open exploits--and how can you count the unknown ones?
However on the subject of typing: the real problem is that typing foreign characters is insanely hard in every OS out there.
This is strongly dependent on both the language and OS in question. For example, Japanese input methods work very well on US keyboards; you key in romaji, and the input method converts it to hirigana or katakana on the fly. When you hit space, a menu of kanji with the given reading is presented. Space again picks the first one, or cursor up/down before hitting space to pick another.
This is apparently a quite common input method, as a Japanese friend who had never used a Mac told me how to use OS X's input method.
The dead keys on Mac OS for Western European languages are also quite easy to get used to. (The AltGr thing on X11 I'm not so fond of.)
But, of course, most Scandinavian users (referring to the grandparent post) will have Scandinavian keyboards, and they aren't entering foreign language sites, they're going to sites in their native languages.
Anyway, you start with the assumption that a domain name is going to contain only characters from one of those groups, and you report if it's otherwise.
You'll probably have to restrict that check to only a single element of the hostname, as the "www." and TLD codes will continue to be in ISO 646 (ASCII).
Slashdot Mirror
What on Earth does an outdent of 9000 pixels, and setting the overflow to "hidden" mean, EXCEPT that they are trying to hide it?
After all, very few of us browse the Web by reading the raw HTML and JavaScript. I find all the bad HTML code is really bad for my brain.
Of course I'm at work, why else would I be reading slashdot?
The point being, you don't need to have Internet Explorer in Windows to get the behaviour of trying to use your Web browser as your system's file manager.
Processing \\servername\sharename paths is a native Windows I/O function, and prettying them up as file://servername/sharename or smb://servername/sharename doesn't change that much.
If you want to use your native file manager, use the native file manager. In this case, the embedding is going the other way--IE has the file tree control embedded, so it can give you an Explorer (as opposed to Internet Explorer) view of the filesystem.
Try this: Start -> Run -> \\servername\sharename
Or to get there by browsing, use Network Neighborhood.
Or in an Explorer (not Internet...) window, type \\servername\sharename in the Address bar.
On Mac OS X, Apple has a neat (and somewhat disturbing) trick. Any protocol that can be treated as disk storage can be mounted as a filing device (so all programs can use it). So you can "Connect to server" with "ftp://someserver/" and the FTP site shows up on your desktop. Or "http://davserver/" for WebDAV (Microsoft calls 'em Web Folders I believe).
From that point, the Finder or any file manager you like, to browse.
Apparently, they missed the entire industry switching to classless inter-domain routing over 10 years ago. (Which is what freed up enough address space to let IPv4 survive as long as it has; the old class-based allocation was amazingly wasteful. Which 126 organizations really needed 16,777,214 hosts on the globally-routable network? More to the point, how many organizations needed 65,534 hosts globally-routable? Turned out, very few.)
A good-size flatbend scanner could probably take 3-4 cards at a time.
Similarly, an old PDP has enough circuitry made from discrete components that you can repair it, even if the vendor won't. Failing that, repairing the disk assembly and interfacing to a modern machine is possible; the wire protocols are well-documented and the disk layout is known.
Old disk packs (and tapes) had a low bits-per-inch rate; you could actually spray them with a coating that would reveal the magnetic patterns visually, then decode by hand.
How about when the control board fries on a 3-year-old IDE disk? If you can get the same controller, you could try and swap it. Now how about the spindle motor failing? Or the voice-coil actuator for the head assembly?
Just because it isn't old doesn't mean you'll be able to get your data off of failed hardware.
But, when the PDP is still in service, you can transfer everything on its drives to other machines. Serial links, networking, all sorts of chances to transfer data.
All of which only works if the files aren't tied to a particular host by some DRM scheme. I've still got files that started on an Amiga, went through a Mac, and are now on Linux.
And here I thought asking for ID was an American thing that people just had to live with.
In that case, I'd like to report every merchant I dealt with in the Philadelphia area. All 5 of them.
But, as others pointed out, there's nothing beautiful about a traditional hack. Think programming with an axe, if you like.
Mind you, to do that, you often need to know a lot about how all the pieces you're hitting with that axe all fit together.
Something elegant is called a 'product'.
There are some things that Linux responds to in a much worse way than some of the older UNIXes.
I wrote a fork() bomb at work to demonstrate what a buggy program had just done to one of our Big Sun Machines. It was out of process slots (entirely--because the per-user limit was something like 30,000, and with the number of users on the system with hundreds of unreaped child processes it overloaded the kernel process table).
I've done things like that on AIX machines I was testing in the past, and sure, they get pretty unresponsive and it's hell to kill off; you basically have to switch to that user and carefully kill -9 -1. (Careful to make sure you don't do it as root....) But if you don't try to hide the bomb, CTRL-C eventually goes through.
It wedged my Linux machine so hard that caps lock stopped responding. (My test for "is it X11 that's dead or the whole kernel".) CTRL-C or CTRL-\ just weren't going to happen... I tried for 15 minutes before hitting the power button.
And I've got a 4095 per-user process limit. But as fork() starts failing in some processes, other processes get scheduled to try fork() themselves. So you get over 4000 processes all trying to fork() at once, and nothing else gets time on the CPU.
A different scheduling algorithm could mitigate some of the impact of a forkbomb on Linux. Similar to the way Linux will dump all its VM pages in favor of allocating them to disk buffers; Linux's approach to some things may be great for performance, but can make things worse when things go wrong.
Not to mention there are things which really, really, really don't need to be in full 5.1 Surround.
But the construction isn't much better on those "monster home" subdivisions you see in places like western New Jersey. $700,000 houses, cheap frame construction, no corners left un-cut. Decent-sized lots, though--but there won't be any shade trees for a couple of decades at least.
The ones with brick veneer only have it on the front, the rest of the house is plastic siding. That would never sell here in Canada; you brick the front of the house, you'd better brick the other 3 sides. (Not that our new home builders are much better, but at least you get a crappy house an hour and a half from the big city for under $200,000. Heck, that far from the city it'd probably be under $100,000. But who wants to be that far away?)
He may have been silly, or funny, but it's no joke. Search Google for "search engine" (with or without the quotes). They're now down to 6th place without quotes, 8th with.
To a large extent, Apple learned from their "wholly proprietary" past. They no longer have their own disk format (remember the multi-speed 800K floppies, SCSI drives formatted to something other than 512 bytes/sector), they generally use standard parts.
Granted, in some cases they were a bit ahead of the game, and chose a standard that wound up failing to become commoditized--though I think they switched from mainly-SCSI to mainly-IDE at about the right time. IDE drives were reaching a good maturity level, and SCSI just wasn't coming down in price.
Similarly, they've chosen RAM standards that failed, or were quickly eclipsed by a newer one. Trying to find RAM for some older machines makes it feel like you're trying to get proprietary parts... but trying to find working combinations of 60ns EDO SIMMS for an old PC isn't much better.
As others have pointed out, USB was Intel's baby, and Apple made it popular. There's a whole mess of USB gear that doesn't say word 1 about working on a Mac that plugs in and works fine. Similarly, FireWire is Apple's version of serial SCSI, that they fed back into the SCSI-III standard. (Along with IBM SSA and FC-AL for other serial SCSI transports.)
I don't really have a problem with Apple trying to find out who's violating their confidentiality contracts. These aren't people who are reporting about security problems, or other issues where Apple might be trying to hide fault or liability. They're new product directions.
The only thing I really don't like about their current operations is how they don't seem to be willing to let other companies generate protected AAC files for the iPod. But, we only have Real's word on the other side of that coin--how many other companies have gone to Apple and asked to license the tech?
But, it also important to keep an eye on Apple. Like you said, they've been there in the past, and they might try to go back there. I liked my Amigas, but I don't think wholly-proprietary hardware is good for the consumer. Similarly, I don't think proprietary software is good for the consumer, either. But I'm keeping my Macs because they Just Work; something I've yet to get Linux to do with the collection of junk I want to use with it.
(Though, in the case of software, a proprietary program with an open data format isn't a big deal--anyone can build a proprietary web server or browser that works well with the rest of the Internet. Look at Opera.)
Really? You've now given someone your full address, a photo of yourself, a valid credit card WITH the "security code" and your signature on both documents. Keep in mind, when forging signatures, it is important to not make every one identical, so two from you is a big help. And they've now got two numbers they can use to search for further information.
Checking ID may protect you from credit card theft, but it HELPS identity theft.
Calling in a lost or stolen credit card promptly is much more useful. But make sure you always keep credit cards where you'll notice their loss.
I think all credit card companies require phone-in "activiation" before you can use the card, so lifting a brand-new card out of a mailbox should be a thing of the past. (And the ones I deal with no longer use Caller ID to quickly activate your card if you call from home--someone can easily pop the cover off the phone junction box and use my phone line with just a pair of test clips on a regular desk phone.)
They're around. Sealed lead-acid gel cells can be had as small as about 0.5" x 1.5" x 2", and about 0.2 lb. (That one is two cells, 4V total, .5 Ah.)
If you've got a UPS, you'll probably have one or two SLA batteries in it, they're usually about half the size of a motorcycle battery. And, more importantly, won't dribble sulphuric acid all over the place if you tip the UPS over. And you won't kill it by forgetting to check the water level that ONE time....
The same sorts of batteries are used in emergency lighting, burglar alarms, and things like that. Fairly easy to get at electronic components stores. Generally you want to use a 20h charge (current 1/20th the Ah capacity), unlike the 10h charge typical for flooded lead-acid. But most of the times you see an SLA, it will be connected to a brain-dead trickle charger; the sort of thing that would destroy a NiCD or NiMH (both respond poorly to overcharging).
Reminds me, it's time to replace the battery on one of my UPSes.
Of course, all that depends on the age of the battery and the use profile. Like, is Engergy Saver set to slow down the CPU? Are you running big number crunching AltiVec code?
My iBook is also rated for about 3 hours, and it's now two years old. To actually get through a 2.5-3 hour movie, I have to turn off Airport. And DVD playback ain't cheap on the power budget.
I did forget to bring a paper notebook to a tradeshow once, and so I used the iBook and xemacs to take notes in the seminars and BOFs. I got 8 hours of run-time out of the machine--by turing the display backlight off and touch-typing blind.
Mine's now to the point where I'm going to seriously consider thinking about maybe getting a new battery for it.
Not that Apple's never had misleading claims in the past. But, unlike other makers, then tend to get hit with a class action suit and have to compensate their customers. (Like the iMac DV settlement, which didn't apply to non-Americans. Fortunately I didn't buy it for the 'DV' part.)
But how hard was it to find out what goes in that ROM?
A little Googling turns up NuBus is a Texas Instruments trademark of something based on an MIT design. NuBus is IEEE standard 1196; so getting data on it isn't going to be tough. (Though it probably won't be free.) A few hardware notes from Apple say, emphatically, that you had better follow the IEEE specs or you'll be in trouble on some models of Macintosh.
Macintosh Toolbox ROM did not use a whitelist for NuBus cards based on their declaration ROM. Compliant cards were required to have that ROM so the bus could configure itself, and then the system could load suitable drivers. Again, to this day, PCI does the same thing--only it is integrated into the PCI bus controller on the card. Back in NuBus's day, integration wasn't as complete, so the NuBus controller on the card was in several chips; one of them a ROM.
Sometimes you get the opposite behaviour, and the thermal expansion keeps the circuit closed, and it fails when it cools off. This is the one that takes out servers that "ran for months until that power failure".
The iBook logic problem (I'm on my 3rd logic board now) is a fairly classic thermal fault; when it first starts, shutting it off and waiting a while will give you a bit of run-time; eventually, it just gets so bad that you can't even do that.
I used that bit of run-time to deauthorize my iBook from the iTMS, as the computer's ID is associated with the Ethernet MAC.
One nice thing; you can still get to Target Disk Mode when the logic board problem takes out your iBook, so you can back up the very last changes you had made. Or erase the system completely if you have... interesting files on it that you don't want the repair depot guys playing with.
Of course, the repair centre should know about thermals and any LBRP candidate should be run for several hours with the display active.
Another thing about the logic board problem: You can't start up when there is no video. So if you had turned it off to try and get past the problem, it won't stay on unless you go to Target Disk Mode. (Hold down T at the chime; your iBook is now a really expensive self-powered FireWire disk.)
One last thing on the logic boards: My first replacement board lasted only 3 months. When I was merging the machine specific preferences files, I noticed that the first replacement had a lower Ethernet MAC than the original board. But the second replacement had a much higher MAC than the original; in fact, it had a whole new manufacturer ID (still one assigned to Apple).
So I suspect that some old stock was being flushed out through the repair program. Or, worse, they were putting logic boards refurbed from some other fault into the replacement stream. (Hmmm, what's the "selling used equipment as new" and "failing to honour service and warranty" contracts bit about? The Forbes article only talked about retailers forced out of business.)
The downside is, the repository of known sizes and checksums are stored on local disk. The upside is they are also recorded, in a fairly easy to retrieve form, on the original install media and are the updates are recorded with each patch file also.
So a good sysadmin doesn't have to track all that, because a good system already did it for him. A good sysadmin would want to make sure there's a way to get into the system from known-good media and access the checksum database from alternate media. Instead of trying to rebuild the DB from install media, it could be just as good to back up the DB when the system is in a known good state. (Just after clean install; before each update, verify the system from clean boot and an offline copy of the checksum db, and so on.)
On AIX, use "lppchk", Solaris has "pkgchk", and RPM-based Linuxes have "rpm --verify".
OK, I lied about Mac OS X, though I don't know of any way to verify the information. 'lsbom' will list the information from a bill of materials file, and these are kept in /Library/Recipts/$PackageName. Disk Utility's "Repair Permissions" uses at least part of the information; maybe I'll intentionally screw up a system file and see if it reports a size verification or checksum failure on it.
Now, of course, anything you put on a system which doesn't use the system package manager won't be recorded in the system package database. So you can't find out it is there, or validate it, or anything.
From my recollections of working with InstallShield a few years ago, it does not track this kind of information at all. I could be wrong about this, it's been quite a while--NT 4.0 was still new!
Virtual PC isn't the same sort of beast at all; Virtual PC emulates the hardware, you still need a copy of Windows. (It may have accelerators for some of the API entry points written in native code, but that is done on top of the installed Windows.)
WINE is a new and original implementation of the Win32 API from first principles (the documentation, such as it is), combined with a whole lot of experimental work to figure out just how Microsoft's various implementations of Win32 (Win32s, Win95 series, WinNT series) differ from the docs.
So, Microsoft can't claim you aren't running it on Windows with Virtual PC (or VMWare or other hardware emulators or virtualizers), because you do have Windows. You don't, necessarily, have an Intel CPU, but that's Intel's and AMD's problem.
With Mac OS, keep in mind, there's no such thing as a "Full Retail" copy of Mac OS X--in fact, of any Mac OS except the version that was licensed for clones. All Macs come with Mac OS, so all copies of Mac OS are actually upgrades, not full versions for an OS-less machine.
How many bugs are fixed by a typical Windows security patch? On the W2K machines where I work, the Software Update thing will quite often show up with 5-7 patches, all of which contain something like the following description:
There could be dozens of bugs fixed in one of those patches. Or there could be just one--you have no way of knowing. I don't even know which files were changed.
Whereas, at least the Red Hat errata I've dealt with, Red Hat lists the all the bugs resolved in a single update (relative the the prior update for that package).
So counting patches is just useless, for many reasons. You need to count the number of open exploits--and how can you count the unknown ones?
This is strongly dependent on both the language and OS in question. For example, Japanese input methods work very well on US keyboards; you key in romaji, and the input method converts it to hirigana or katakana on the fly. When you hit space, a menu of kanji with the given reading is presented. Space again picks the first one, or cursor up/down before hitting space to pick another.
This is apparently a quite common input method, as a Japanese friend who had never used a Mac told me how to use OS X's input method.
The dead keys on Mac OS for Western European languages are also quite easy to get used to. (The AltGr thing on X11 I'm not so fond of.)
But, of course, most Scandinavian users (referring to the grandparent post) will have Scandinavian keyboards, and they aren't entering foreign language sites, they're going to sites in their native languages.
You'll probably have to restrict that check to only a single element of the hostname, as the "www." and TLD codes will continue to be in ISO 646 (ASCII).
That's a daemon, damnit!
That'd be dihydrogen monoxide (also found in most industrial waste) and color?