The question "which RAID level do I use?" raises other questions: which drive interface technology? what is your budget? how much storage do you need? do you need redundancy for swap? for boot partitions?
But regardless of how you answer those questions and what RAID level you finally go for, I would strongly recommend layering LVM (logical volume management) on top of RAID. Sounds bizarre and cumbersome to have two virtual layers between your filesystem and your physical devices, but in most cases it's worth it.
(Now here I'm assuming you're using Linux, but similar solutions are available for other OSs).
If you're not familiar with LVM, it virtualizes partitions. You group together one or more physical volumes (PVs) that provide a pool of physical extents (PEs). From this pool, you create logical volumes (LVs) filled with logical extents (LEs).
Thus, you could have four partitions on three drives serving as PVs, and from that pool (Volume Group or VG) you could create, say, two partitions. From there you have many options:
- You can resize the partitions. - You can add another drive and add the space on that drive to the VG, then increase the size of the partitions. - You can migrate data off one of the partitions, then remove that partition from the VG. - You can migrate to another drive by adding that drive, migrating data away from the previous PVs, then removing the old PVs from the VG. This can be, by far, the easiest way to
To combine LVM with RAID, just use the md device as a PV.
And here is the top reason to use LVM: - You can create snapshot backups.
A snapshot backup is a virtual partition, read-only, which contains the same data as another partition, frozen at a certain point in time. Something similar to copy-on-write is used so that the snapshot partition takes only the amount of disk space necessary to store the changes between the time the snapshot was frozen and the current state of the 'snapped' filesystem.
If you 'rm -rf *', you can just cp the files from your latest snapshot. (BTW, this can save a ton of work for sysadmins with forgetful users... users can restore the file they just deleted by navigating (graphically even!) to, say,/backup/2004-06-16/home/jason and copying a file to the desired location).
So RAID can protect you from hardware error, and LVM with snapshots can help protect you from user error.
Except for broken applications, there is no conflict between the primary selection and clipboard mechanisms. You can completely ignore middle-click and happily use only the clipboard. Almost all modern apps implement Ctrl-X/C/V; some older ones implement Ctrl-Insert/Delete because that was the standard in earlier versions of Motif (it came from the CUA standard ---> IBM Presentation Manager ---> Motif 1.0).
So you can look at Select+MiddleClick as an optional addition to the user interface. Don't care for it? Just use the clipboard!
But let's not work ourselves into a sweat and start ripping the primary selection code out of the GUI toolkits. Primary selection is a good thing: it works where clipboard selection doesn't (for example, where a selection is permitted but no Copy function is available), it takes advantage of the hardware (let's use those middle buttons!), and it's a legitimate timesaver for many of us.
(But to whoever made the earlier versions of KDE operate on the primary selection when Ctrl-X/C/V was used: we sentence you to read the Inter-Client Communication Convention Manual (ICCCM) from the X Window System from Cover to Cover, three times. In 8-point Courier. On red paper).
The Galeon browser is great with tabs. Set it up so that middle-click opens in a new tab...
- Middle-click the HOME icon to get a new tab. - Middle-click an existing tab to open a duplicate. - To do the "Open the selection in a new tab" thing, middle-click HOME then middle-click somewhere on the new window body.
Galeon also allows re-ordering tabs, closing a tab other than the one you're looking at (useful at work... think about it), and so forth.
You make an interesting point when you ask whether security problems will increase if Open Source 'goes mainstream'.
However, I think we need to keep in mind the fact that Closed Source limits support options. Ultimately, bug fixes must come from the party who has the source. Thus, any support provider who does not have the source is automatically a second-tier provider, at the mercy of the party that controls the source.
IBM is a multibillion dollar, international company that has (at least recently) built a large part of their business around support offerings. But if you buy a large LAN from them, and that LAN runs proprietary, closed source software, then IBM is limited in the support that they can provide when a bug is discovered. They are at the mercy of (for example) Microsoft to fix bugs in their products -- Office, Windows XP, SQL Server, and so forth. If MS doesn't see a bug as critical, then it could be some time before it is fixed -- if ever. You can change support providers, but none of the providers except for MS itself can do any better at fixing your problem. (MS is only an example here -- substitute Oracle, CA, Sibel, SAS, or any other proprietary vendor).
On the other hand, if IBM sells you the same LAN and the same support contract, but that LAN runs Open Source software, then they can fix any bugs that are discovered. They have the capability to provide top-notch support.
Even more useful: IBM has to compete with everyone else who has the source code in order to keep your support contract. If IBM doesn't come through -- if the network is buggy and unstable -- then you can turn to any other support provider and have them work on the problem for you. The little 3-man consulting shop down the street has a crack at providing better support than the multinational, and vice versa. And since (contrary to what some proprietary vendors will tell you) people hate to fork (it's way too much work!), the fixes do get sent back to the maintainers and do get rolled into the core distributions.
For this reason I think that you will find that Open Source's stability will scale as it gains acceptance in the marketplace.
From the Microsoft rebuttal: It is also notable that the specifications Microsoft must now license do not yet exist. Microsoft will have to create them. These specifications, which will comprise thousands of pages of valuable information, will qualify as copyrighted works in their own right and as copyrightable preparatory design material for a computer program under the EC s 1991 Software Copyright Directive.
This just confirms what we've been thinking for a long time -- MS software is not planned. The protocols aren't mapped out or specified. The implementation *is* the specification. Software just happens; there is no such thing as Software Engineering in the Microsoft world. To get a written specification, it has to be reverse-engineered from the product.
But you don't have to be able to pump the full 1000 Mbps to take advantage of gigabit ethernet. As long as you can pump more than 100 Mbps, then gigabit will give you a speed improvement over 100 Mbps ethernet.
(Or, a good location for the ceiling is "anywhere above your head").
My two daughters (now 8 and 10) have also used Linux since they were tiny (3-4 years old).
One change that I made to the normal system install was to modify the display manager (gdm/kdm) to enable multiple X sessions on different virtual terminals. We ran four different X servers -- one each on VT7 through VT10. Each of these VT's was assigned to a member of the family, so that we could each login and use the system even if another family member had not logged out.
Thus, regardless of who was logged in, I could switch to my VT by pressing Ctrl-Alt-F7 and login there. If I got tied up with a phone call, my wife could then press Ctrl-Alt-F8 to switch to her VT and login there, without disturbing any applications which I had running. I could later switch back to my session on VT7 with Ctrl-Alt-F7. Likewise my two girls had VT9 and VT10.
(This is set up with a relatively minor change in the Xservers file (for xdm/kdm) or gdm.conf file (for gdm)).
I would have continued that practice, except that when I recently upgraded my home system, I added two additional keyboard/mouse/monitor setups. Thus we now have a single PC that supports three simultaneous users (using Backstreet Ruby; here is a description of the setup). For our family needs, this is easier to administer and uses less power than a 3-machine LAN while still providing plenty of performance.
I used and loved WP on Unix from 5.1 through 8. I still have WP6 and WP8 on one of my Linux boxes to manage the occassional old document.
WP's user interface had clunky spots, but it was *predictable*. StarOffice drives me crazy in a few places-- Getting rid of extra lines at the top of the page sometimes seems impossible, and Good Luck if you have a table at the top of a page and want to insert lines above it.
But WP's most impressive feat was the file compatability. From 5.2 onward, files were forward- AND backward-compatible. The tagged-block structure file format had been thought out well, and as new features were introduced, they were added to the format in such a way that older versions of the app could open and use as much of the newer files as possible. Compared to Word, it stood out as just plain Good Engineering.
One of the main design goals of the RPM system (the most common package format, used in RedHat/Fedora, SuSE, Mandrake, Conectiva, and others) is that you can reliably rebuild packages in an automated way.
The meta-data provided by a package system is essential when maintaining production servers -- you need the ability to easily figure out which package owns a given file and what will break if you change something. This is not nearly as critical for a home machine, or a system that will not be running for years, gradually upgraded over time.
If the binary package works for you, cool. If you want to rebuild with the latest libraries and better optimizations, or for a newer architechture (amd64 vs. x86 for example), then go for it.
Most.src.rpm files will use the./configure provided with the package, which will generally figure out good defaults for your system, and you can further tweak this with your RPM macros.
If there's no RPM for something you want to install, then create one! It will take you half a day to make a really good RPM the first time, but just an hour the second time, and you'll have it down to 5-10 minutes + the compile time after your first dozen.
And to get out of dependency hell, use yum or apt/synaptic.
The other change that I've seen from AOL (and some other ISPs) recently is that e-mail from dynamic IPs is being rejected. I understand the reason for this, but it seems a poor criterion for mail rejection; an SPF record should be able to override this, yet this does not seem to be the case.
This is going to affect a number of Linux distros, where the Sendmail configuration assumes that e-mail may be sent directly to remote hosts.
I don't see why IBM couldn't be objective -- they sell both Windows and Linux systems, and to be honest, they probably sell more systems with Windows installed. IBM has the technical competence and the experience with both technologies (and more -- AIX, OS/390, OS/400, OS/2,...) to reasonably compare the two.
A reseller that sells two product lines, even if somewhat biased, is going to be a whole lot more objective than the manufacturer of one of those product lines.
'Execution' is a word executives use to divert blame from themselves. If a company or team is unsuccessful, "poor execution" is the reason, even though a bad or unrealistic business plan may have been at fault.
It's odd that you note that executives blame poor execution for a failure... by definition, an 'executive' is someone who is responsible for 'execution' of affairs (see Websters). So if the execution is poor, the executives must be responsible!
I think (gasp) Bell Canada is Getting It... use payphone locations for 802.11b access points. We talked about this a while ago but didn't focus on the payphone-subsidizing aspect...
Beside releasing specs, the other thing that the hardware companies can do is support standards and engineer their products so that there is less variation between product generations.
Rather than invent new protocols, command sequences, and interfaces, they can support a standard interface across their whole product line.
This makes it easier for the open-source developers, but it also makes it easier for the company itself -- hardware designers, in-house developers, and support people. In many cases, an old driver can be used, perhaps slightly updated to manage a few new features. This reduces the amount of redevelopment and therefore reduces the opportunities for bugs to sneak in -- regardless of the platform.
Some good examples come to mind:
- HP scanners. The HP scanner protocol has been pretty much stable for years, and the same command set has been used on the USB scanners as the SCSI scanners. You can take a current SCSI scanner and use it with a driver from 6 years ago. Yes, the protocol is proprietary, but it's well documented and well understood, and it's not changed at whim.
- DPT controllers (old). These used the EATA (extended ATA) interface across the product line. EATA was well-documented, multi-vendor, and stable. It provided basic compatability with ATA (IDE host adapter) specs but could then take off from there. New cards needed tweaking but not wholesale driver rewrites.
- Most SCSI tape drives. These all use the standard SCSI tape command set, even though they have very different capabilities. (Contrast this to OnStream drives, below).
Some bad examples:
- Early OnStream tape drives. Although the newer units understand standard SCSI tape protocols, the early units used an unnecessary proprietary variation. There were reasons for the variation -- but the fact that the newer drives understand the standard command sets indicates that the variation was not necessary.
- Video cards. Why can't successive video cards from the same manufacturer each support a superset of the previous capabilities, so that you could use the previous driver to start, then eventually add the new functionality to the driver to fully support the latest card?
- Many advanced laser printers (this is a cross-manufacturer issue). I have yet to see two different makers that use the same paper-source-select or staple-enable codes. If PCL and PostScript and PJL are all standardized for other functions, why not source-select and finisher options? It wouldn't require an ANSI subcommittee, just one or two face-to-face meetings or a couple of days of faxes and e-mails.
In most cases, these are engineering problems. The first-generation products need to be designed with some foresight -- version numbers, capability registers, extensible command sets, protocols that can be implemented over different interfaces -- so that later product generations can interoperate, even when they support features which we can't even dream about now.
To get insanely long battery life you'd need a very low-drain laptop coupled with something like an Electrofuel 120 or 160 (a think that looks like a mousepad that fits under your laptop, but which is actually a 12+ or 16+ hour battery).
Disclaimer: I haven't used 'em, but I saw them at Comdex and they looked cool enough to put on my Christmas wish list.
That's not necessarily true -- certificates have an expiry date. After the expiry date, the entry in the CRL can be deleted, because the certificate will be rejected anyways.
It's interesting to me that the building of power plants is opposed by some environmentalists in California. It would seem that you could more readily control the polution produced by a properly built, maintained, and regulated power plant than the thousands of diesel generators that get powered up when rolling blackouts are applied...
Yes, the University of Calgary housed two Multics systems in the 80's: a 6-CPU system and a 1-CPU test system. The company that supported Multics after Honeywell (ACTC) was a spin-off from U of C.
Multics (at UofC) was the first large system I used, and I have many fond memories of it. I attended the Shad Valley (technology + entrepreneurship) summer program in 1984 and spent hours absorbing 'everything Multics'. On-line manuals, pathnames, processes, e-mail, chatting, windowing systems (character-based)... all very fascinating to a tech-hungry teenager.
It's interesting to note that Multics underwent a development surge in the early 80's and despite the aging hardware design still had a number of sites at that point (Ford, Canadian defense, US DOD).
I'm sad to see it go, though its time has come (without portability, it was doomed to die with the hardware). I remember touring the U of C computer room when a tech was on site, reportedly doubling the cache *width* while the system remained on-line (I presume he was taking one CPU offline at a time). The LED bargraph pads showing CPU utilization for each processor that were scattered around the room were quite impressive too:-)
C'mon, do the math... 8 drives * 36 GB/drive = 288 GB in 1U. That's the add-on box, the main box has half that. Where did the 640 GB figure come from?! The vendor's web site only claims 432 GB in 2U.
(Still, it's impressive to have multi-TB storage along with a beowulf cluster in one rack:-)
As long as our favourite non-free x86-only OS rules the planet, we'll have x86.
There's more to it than that. If we're all running free OSs, but need some proprietary binary-only drivers or applications on top of that OS, we're still locked into one CPU architechture.
I am not a give-me-Free-Software-or-Death kind of guy, and regularly run proprietary software on top of a free OS, but I think we have to be aware that this continues to lock us into one architechture. Attempts to viably market proprietary software on multiple machine architechtures (e.g., apps for NT on Intel+Alpha+MIPS, or WordPerfect on various RISC Unices) have generally failed due to support costs and market size.
Symlinks with copy-on-write could be very useful. But the article doesn't mention anything about copy-on-write, and automatic symlinking without COW could be very dangerous.
Has anyone seen any pointers to additional info on this 'feature'?
Record a disk full of true random numbers on a "3-minute" version of this disk and you've got a multi-GB one-time-pad for cryptography. (A one-time-pad is a list of random numbers against which you XOR your data. The only way to decrypt (as long as the numbers are truly random and you can't guess 'em) it is to have a copy of the OTP number list. If the DVD self-destructs in a few minutes that won't be possible-- if they come and confiscate your system after you encrypt and send the data, no go, and if they sneak into your spy headquarters to copy the disk before you encrypt the data, the disk is voided. Of course, the receiving end also needs a copy of the OTP data:-).
One of the things that Caldera sought was access to MS APIs for a period of 10 years. If the $0.03 per share / $150M figure seems too low, perhaps it's because there were non-monetary components in the settlement, e.g., API disclosure, software or patent licensing, non-compete agreements, etc. Who knows, maybe Lineo picked up the rights to CE or something (ouch!).
It would be interesting if Caldera got the 10-year API disclosure originally sought; that could lead to some significant improvements in Willows Twin, WINE, and/or some proprietary equivalent (WABI revival?).
You raise a good point (which keyboard would be better *specifically for programming*). Dvorak keyboards were designed with the most common letters on the home row, and the common vowels on one hand and common consonants on the other (to encourage alternation). But a number of the common Unix commands were shortened (to reduce typing and teletype ribbon consumption:-) by removing the vowels. On the Dvorak keyboard, this would eliminating the use of one hand's home row altogether.
Therefore I would suspect that using a Dvorak keyboard to type at a shell prompt might not buy you much... (think cd, cp, ls, bc, mv, rm, gcc, gdb, ftp, etc).
(This isn't to say that I don't believe in the Dvorak keyboard... I only tried it once, when I knew the Qwerty layout and was moderately fast but not a speed daemon-- by remapping my Commodore 64 keyboard of all things!-- and within a few few hours I had my Dvorak speed up to my Qwerty speed or better. But at the present time I switch between systems too often to want to try Dvorak again).
Slashdot Mirror
The question "which RAID level do I use?" raises other questions: which drive interface technology? what is your budget? how much storage do you need? do you need redundancy for swap? for boot partitions?
... users can restore the file they just deleted by navigating (graphically even!) to, say, /backup/2004-06-16/home/jason and copying a file to the desired location).
But regardless of how you answer those questions and what RAID level you finally go for, I would strongly recommend layering LVM (logical volume management) on top of RAID. Sounds bizarre and cumbersome to have two virtual layers between your filesystem and your physical devices, but in most cases it's worth it.
(Now here I'm assuming you're using Linux, but similar solutions are available for other OSs).
If you're not familiar with LVM, it virtualizes partitions. You group together one or more physical volumes (PVs) that provide a pool of physical extents (PEs). From this pool, you create logical volumes (LVs) filled with logical extents (LEs).
Thus, you could have four partitions on three drives serving as PVs, and from that pool (Volume Group or VG) you could create, say, two partitions. From there you have many options:
- You can resize the partitions.
- You can add another drive and add the space on that drive to the VG, then increase the size of the partitions.
- You can migrate data off one of the partitions, then remove that partition from the VG.
- You can migrate to another drive by adding that drive, migrating data away from the previous PVs, then removing the old PVs from the VG. This can be, by far, the easiest way to
To combine LVM with RAID, just use the md device as a PV.
And here is the top reason to use LVM:
- You can create snapshot backups.
A snapshot backup is a virtual partition, read-only, which contains the same data as another partition, frozen at a certain point in time. Something similar to copy-on-write is used so that the snapshot partition takes only the amount of disk space necessary to store the changes between the time the snapshot was frozen and the current state of the 'snapped' filesystem.
If you 'rm -rf *', you can just cp the files from your latest snapshot. (BTW, this can save a ton of work for sysadmins with forgetful users
So RAID can protect you from hardware error, and LVM with snapshots can help protect you from user error.
So why doesn't your purchase order software put your text in caps for you?
I'm finding this discussion almost unbelievable!
Except for broken applications, there is no conflict between the primary selection and clipboard mechanisms. You can completely ignore middle-click and happily use only the clipboard. Almost all modern apps implement Ctrl-X/C/V; some older ones implement Ctrl-Insert/Delete because that was the standard in earlier versions of Motif (it came from the CUA standard ---> IBM Presentation Manager ---> Motif 1.0).
So you can look at Select+MiddleClick as an optional addition to the user interface. Don't care for it? Just use the clipboard!
But let's not work ourselves into a sweat and start ripping the primary selection code out of the GUI toolkits. Primary selection is a good thing: it works where clipboard selection doesn't (for example, where a selection is permitted but no Copy function is available), it takes advantage of the hardware (let's use those middle buttons!), and it's a legitimate timesaver for many of us.
(But to whoever made the earlier versions of KDE operate on the primary selection when Ctrl-X/C/V was used: we sentence you to read the Inter-Client Communication Convention Manual (ICCCM) from the X Window System from Cover to Cover, three times. In 8-point Courier. On red paper).
The Galeon browser is great with tabs. Set it up so that middle-click opens in a new tab...
- Middle-click the HOME icon to get a new tab.
- Middle-click an existing tab to open a duplicate.
- To do the "Open the selection in a new tab" thing, middle-click HOME then middle-click somewhere on the new window body.
Galeon also allows re-ordering tabs, closing a tab other than the one you're looking at (useful at work... think about it), and so forth.
You make an interesting point when you ask whether security problems will increase if Open Source 'goes mainstream'.
However, I think we need to keep in mind the fact that Closed Source limits support options. Ultimately, bug fixes must come from the party who has the source. Thus, any support provider who does not have the source is automatically a second-tier provider, at the mercy of the party that controls the source.
IBM is a multibillion dollar, international company that has (at least recently) built a large part of their business around support offerings. But if you buy a large LAN from them, and that LAN runs proprietary, closed source software, then IBM is limited in the support that they can provide when a bug is discovered. They are at the mercy of (for example) Microsoft to fix bugs in their products -- Office, Windows XP, SQL Server, and so forth. If MS doesn't see a bug as critical, then it could be some time before it is fixed -- if ever. You can change support providers, but none of the providers except for MS itself can do any better at fixing your problem. (MS is only an example here -- substitute Oracle, CA, Sibel, SAS, or any other proprietary vendor).
On the other hand, if IBM sells you the same LAN and the same support contract, but that LAN runs Open Source software, then they can fix any bugs that are discovered. They have the capability to provide top-notch support.
Even more useful: IBM has to compete with everyone else who has the source code in order to keep your support contract. If IBM doesn't come through -- if the network is buggy and unstable -- then you can turn to any other support provider and have them work on the problem for you. The little 3-man consulting shop down the street has a crack at providing better support than the multinational, and vice versa. And since (contrary to what some proprietary vendors will tell you) people hate to fork (it's way too much work!), the fixes do get sent back to the maintainers and do get rolled into the core distributions.
For this reason I think that you will find that Open Source's stability will scale as it gains acceptance in the marketplace.
From the Microsoft rebuttal: It is also notable that the specifications Microsoft must now license do not yet exist. Microsoft will have to create them. These specifications, which will comprise thousands of pages of valuable information, will qualify as copyrighted works in their own right and as copyrightable preparatory design material for a computer program under the EC s 1991 Software Copyright Directive.
This just confirms what we've been thinking for a long time -- MS software is not planned. The protocols aren't mapped out or specified. The implementation *is* the specification. Software just happens; there is no such thing as Software Engineering in the Microsoft world. To get a written specification, it has to be reverse-engineered from the product.
Ouch.
But you don't have to be able to pump the full 1000 Mbps to take advantage of gigabit ethernet. As long as you can pump more than 100 Mbps, then gigabit will give you a speed improvement over 100 Mbps ethernet.
(Or, a good location for the ceiling is "anywhere above your head").
From a note I sent to the author of the article:
My two daughters (now 8 and 10) have also used Linux since they were tiny (3-4 years old).
One change that I made to the normal system install was to modify the display manager (gdm/kdm) to enable multiple X sessions on different virtual terminals. We ran four different X servers -- one each on VT7 through VT10. Each of these VT's was assigned to a member of the family, so that we could each login and use the system even if another family member had not logged out.
Thus, regardless of who was logged in, I could switch to my VT by pressing Ctrl-Alt-F7 and login there. If I got tied up with a phone call, my wife could then press Ctrl-Alt-F8 to switch to her VT and login there, without disturbing any applications which I had running. I could later switch back to my session on VT7 with Ctrl-Alt-F7. Likewise my two girls had VT9 and VT10.
(This is set up with a relatively minor change in the Xservers file (for xdm/kdm) or gdm.conf file (for gdm)).
I would have continued that practice, except that when I recently upgraded my home system, I added two additional keyboard/mouse/monitor setups. Thus we now have a single PC that supports three simultaneous users (using Backstreet Ruby; here is a description of the setup). For our family needs, this is easier to administer and uses less power than a 3-machine LAN while still providing plenty of performance.
I used and loved WP on Unix from 5.1 through 8. I still have WP6 and WP8 on one of my Linux boxes to manage the occassional old document.
WP's user interface had clunky spots, but it was *predictable*. StarOffice drives me crazy in a few places-- Getting rid of extra lines at the top of the page sometimes seems impossible, and Good Luck if you have a table at the top of a page and want to insert lines above it.
But WP's most impressive feat was the file compatability. From 5.2 onward, files were forward- AND backward-compatible. The tagged-block structure file format had been thought out well, and as new features were introduced, they were added to the format in such a way that older versions of the app could open and use as much of the newer files as possible. Compared to Word, it stood out as just plain Good Engineering.
This isn't an either-or situation.
.src.rpm files will use the ./configure provided with the package, which will generally figure out good defaults for your system, and you can further tweak this with your RPM macros.
One of the main design goals of the RPM system (the most common package format, used in RedHat/Fedora, SuSE, Mandrake, Conectiva, and others) is that you can reliably rebuild packages in an automated way.
The meta-data provided by a package system is essential when maintaining production servers -- you need the ability to easily figure out which package owns a given file and what will break if you change something. This is not nearly as critical for a home machine, or a system that will not be running for years, gradually upgraded over time.
If the binary package works for you, cool. If you want to rebuild with the latest libraries and better optimizations, or for a newer architechture (amd64 vs. x86 for example), then go for it.
Most
If there's no RPM for something you want to install, then create one! It will take you half a day to make a really good RPM the first time, but just an hour the second time, and you'll have it down to 5-10 minutes + the compile time after your first dozen.
And to get out of dependency hell, use yum or apt/synaptic.
The other change that I've seen from AOL (and some other ISPs) recently is that e-mail from dynamic IPs is being rejected. I understand the reason for this, but it seems a poor criterion for mail rejection; an SPF record should be able to override this, yet this does not seem to be the case.
This is going to affect a number of Linux distros, where the Sendmail configuration assumes that e-mail may be sent directly to remote hosts.
I don't see why IBM couldn't be objective -- they sell both Windows and Linux systems, and to be honest, they probably sell more systems with Windows installed. IBM has the technical competence and the experience with both technologies (and more -- AIX, OS/390, OS/400, OS/2, ...) to reasonably compare the two.
A reseller that sells two product lines, even if somewhat biased, is going to be a whole lot more objective than the manufacturer of one of those product lines.
'Execution' is a word executives use to divert blame from themselves. If a company or team is unsuccessful, "poor execution" is the reason, even though a bad or unrealistic business plan may have been at fault.
It's odd that you note that executives blame poor execution for a failure... by definition, an 'executive' is someone who is responsible for 'execution' of affairs (see Websters). So if the execution is poor, the executives must be responsible!
I think (gasp) Bell Canada is Getting It... use payphone locations for 802.11b access points. We talked about this a while ago but didn't focus on the payphone-subsidizing aspect...
http://www.bell.ca/accesszone
Beside releasing specs, the other thing that the hardware companies can do is support standards and engineer their products so that there is less variation between product generations.
Rather than invent new protocols, command sequences, and interfaces, they can support a standard interface across their whole product line.
This makes it easier for the open-source developers, but it also makes it easier for the company itself -- hardware designers, in-house developers, and support people. In many cases, an old driver can be used, perhaps slightly updated to manage a few new features. This reduces the amount of redevelopment and therefore reduces the opportunities for bugs to sneak in -- regardless of the platform.
Some good examples come to mind:
- HP scanners. The HP scanner protocol has been pretty much stable for years, and the same command set has been used on the USB scanners as the SCSI scanners. You can take a current SCSI scanner and use it with a driver from 6 years ago. Yes, the protocol is proprietary, but it's well documented and well understood, and it's not changed at whim.
- DPT controllers (old). These used the EATA (extended ATA) interface across the product line. EATA was well-documented, multi-vendor, and stable. It provided basic compatability with ATA (IDE host adapter) specs but could then take off from there. New cards needed tweaking but not wholesale driver rewrites.
- Most SCSI tape drives. These all use the standard SCSI tape command set, even though they have very different capabilities. (Contrast this to OnStream drives, below).
Some bad examples:
- Early OnStream tape drives. Although the newer units understand standard SCSI tape protocols, the early units used an unnecessary proprietary variation. There were reasons for the variation -- but the fact that the newer drives understand the standard command sets indicates that the variation was not necessary.
- Video cards. Why can't successive video cards from the same manufacturer each support a superset of the previous capabilities, so that you could use the previous driver to start, then eventually add the new functionality to the driver to fully support the latest card?
- Many advanced laser printers (this is a cross-manufacturer issue). I have yet to see two different makers that use the same paper-source-select or staple-enable codes. If PCL and PostScript and PJL are all standardized for other functions, why not source-select and finisher options? It wouldn't require an ANSI subcommittee, just one or two face-to-face meetings or a couple of days of faxes and e-mails.
In most cases, these are engineering problems. The first-generation products need to be designed with some foresight -- version numbers, capability registers, extensible command sets, protocols that can be implemented over different interfaces -- so that later product generations can interoperate, even when they support features which we can't even dream about now.
-Chris Tyler
To get insanely long battery life you'd need a very low-drain laptop coupled with something like an Electrofuel 120 or 160 (a think that looks like a mousepad that fits under your laptop, but which is actually a 12+ or 16+ hour battery).
Disclaimer: I haven't used 'em, but I saw them at Comdex and they looked cool enough to put on my Christmas wish list.
That's not necessarily true -- certificates have an expiry date. After the expiry date, the entry in the CRL can be deleted, because the certificate will be rejected anyways.
It's interesting to me that the building of power plants is opposed by some environmentalists in California. It would seem that you could more readily control the polution produced by a properly built, maintained, and regulated power plant than the thousands of diesel generators that get powered up when rolling blackouts are applied...
Yes, the University of Calgary housed two Multics systems in the 80's: a 6-CPU system and a 1-CPU test system. The company that supported Multics after Honeywell (ACTC) was a spin-off from U of C.
... all very fascinating to a tech-hungry teenager.
:-)
Multics (at UofC) was the first large system I used, and I have many fond memories of it. I attended the Shad Valley (technology + entrepreneurship) summer program in 1984 and spent hours absorbing 'everything Multics'. On-line manuals, pathnames, processes, e-mail, chatting, windowing systems (character-based)
It's interesting to note that Multics underwent a development surge in the early 80's and despite the aging hardware design still had a number of sites at that point (Ford, Canadian defense, US DOD).
I'm sad to see it go, though its time has come (without portability, it was doomed to die with the hardware). I remember touring the U of C computer room when a tech was on site, reportedly doubling the cache *width* while the system remained on-line (I presume he was taking one CPU offline at a time). The LED bargraph pads showing CPU utilization for each processor that were scattered around the room were quite impressive too
C'mon, do the math... 8 drives * 36 GB/drive = 288 GB in 1U. That's the add-on box, the main box has half that. Where did the 640 GB figure come from?! The vendor's web site only claims 432 GB in 2U.
:-)
(Still, it's impressive to have multi-TB storage along with a beowulf cluster in one rack
There's more to it than that. If we're all running free OSs, but need some proprietary binary-only drivers or applications on top of that OS, we're still locked into one CPU architechture.
I am not a give-me-Free-Software-or-Death kind of guy, and regularly run proprietary software on top of a free OS, but I think we have to be aware that this continues to lock us into one architechture. Attempts to viably market proprietary software on multiple machine architechtures (e.g., apps for NT on Intel+Alpha+MIPS, or WordPerfect on various RISC Unices) have generally failed due to support costs and market size.
Symlinks with copy-on-write could be very useful. But the article doesn't mention anything about copy-on-write, and automatic symlinking without COW could be very dangerous.
Has anyone seen any pointers to additional info on this 'feature'?
Record a disk full of true random numbers on a "3-minute" version of this disk and you've got a multi-GB one-time-pad for cryptography. (A one-time-pad is a list of random numbers against which you XOR your data. The only way to decrypt (as long as the numbers are truly random and you can't guess 'em) it is to have a copy of the OTP number list. If the DVD self-destructs in a few minutes that won't be possible-- if they come and confiscate your system after you encrypt and send the data, no go, and if they sneak into your spy headquarters to copy the disk before you encrypt the data, the disk is voided. Of course, the receiving end also needs a copy of the OTP data :-).
One of the things that Caldera sought was access to MS APIs for a period of 10 years. If the $0.03 per share / $150M figure seems too low, perhaps it's because there were non-monetary components in the settlement, e.g., API disclosure, software or patent licensing, non-compete agreements, etc. Who knows, maybe Lineo picked up the rights to CE or something (ouch!).
It would be interesting if Caldera got the 10-year API disclosure originally sought; that could lead to some significant improvements in Willows Twin, WINE, and/or some proprietary equivalent (WABI revival?).
You raise a good point (which keyboard would be better *specifically for programming*). Dvorak keyboards were designed with the most common letters on the home row, and the common vowels on one hand and common consonants on the other (to encourage alternation). But a number of the common Unix commands were shortened (to reduce typing and teletype ribbon consumption :-) by removing the vowels. On the Dvorak keyboard, this would eliminating the use of one hand's home row altogether.
... (think cd, cp, ls, bc, mv, rm, gcc, gdb, ftp, etc).
Therefore I would suspect that using a Dvorak keyboard to type at a shell prompt might not buy you much
(This isn't to say that I don't believe in the Dvorak keyboard... I only tried it once, when I knew the Qwerty layout and was moderately fast but not a speed daemon-- by remapping my Commodore 64 keyboard of all things!-- and within a few few hours I had my Dvorak speed up to my Qwerty speed or better. But at the present time I switch between systems too often to want to try Dvorak again).