Most modems have alot of extra processing to handle error correction, compression, and other things. I can imagine that a "Gamer's Modem" would cut out the non-essential steps such as V.42bis compression. It might also bypass some of the other bandwidth-enhancing tricks they do, trading bandwidth for latency.
Also, depending on how fancy they are, they might be doing some IP-level tricks, although I'd hope they're not. (This is reminiscent of the XModem-accelerating modems of several years ago that would fake an XModem ACK to speed up downloads, since XModem didn't stream.)
One possible reason for such a competition is to actively seek out poor performing systems and use them to try to understand how best to fix the operating system. For example, in the Linux world, people now complain about long fsck times on huge filesystems, so the Linux community responds by developing journalled filesystems. (Note that in the early days, filesystems weren't huge enough to make fsck times an issue for most users. Nowadays, even typical home-user filesystems are large enough to cause a minor headache. This sort of model -- fix what the users say is broken now, even if it wasn't broken before -- is a reasonably good model.)
I'm not saying that Microsoft is behind this contest, but it would be an interesting (and good) if they were. This is an effective way to find out where a product is not doing as well as it should and can be improved, and it's something I think every software vendor should do.
Other industries do this. My dad used to work at the GM plant where they build the 3800 Series II V6 Engine. (This is the power plant that comes in the 3.8L Grand Prix, Bonneville, and some other cars. I personally own a supercharged Grand Prix GTP.) The 3800 apparently has a legendary track record as one of the most stable engines GM has produced in recent memory. Nonetheless, they purchased a used 3800 engine from a cab company that had somewhere around 300K miles on it, to do failure analysis on it so that they could make their engines even better. The disassembled engine is now on proud display at the plant as a testament to how good of an engine it was.
What would be interesting is if Microsoft did the same: "Show us your worst performing servers, and as a prize, we'll exchange your servers for new ones and use your old ones to do performance analysis so this problem doesn't happen again."
These are very good tips. (In particular, I had missed the "1 inode per 4K bytes" bit in my brief encounter with the mke2fs manpage, but indeed that's the default.)
BTW, for the curious, the magic incantation that produces the above set of parameters is like so: mke2fs -b 4096 -i 131072/dev/whatever
I have a 17Gb hard-drive that I use for CD-ROM images for when I build music-compilation CDRs. These tips would work great on this HD, particularly for the odd case when I have to fsck. Note that a 4Kb cluster size should also speed up most other operations on large files, particularly those which require synchronous metadata updates, such as rm's.
(Note: I've only had one Linux kernel crash that I can remember since getting this drive, due to some strange interaction between burning a CD, playing a WAV file and insmod'ing the floppy driver from kerneld on a kernel that would have preferred kmod. The rest have been stupids like bumping the power switch, having a UPS go bad, etc.)
Intel is pushing your third bullet into new territory by claiming that Pentium III has special features for "enhancing your Internet experience" (whatever that means*).
The average AOL-esqe consumer will fall for it, certainly. Yay marketing.
--Joe
(* Note: I know it refers to using SSE-enabled plugins to view content on special websites. Plugins are just another opportunity for my browser to crash -- they do not 'enhance my Internet experience'. If a site requires them, I just visit a different site.)
AMD puts out n+1 x86, where n is the current intel generation, but intel comes back a few months later with somthing better, the k5 was far better then a 486, but pales to a pentium. a k6 is better then a pentium, but dosn't really hold up to a pII/PIII. the Athlon beats the pants off a p6, but...
You forget... K5 came out after Pentium, and K6 came out after the P6 family parts. K7/Athlon is the first time AMD has actually beaten Intel to the punch.
Well, no. Certainly you could use mmap() to get a memory mapped file, but there are a couple of deficiencies associated with that approach. [...] Second, EROS has checkpointing to ensure that saved state of many different objects are all saved at an identical time and are consistent with each other. That consistency is very hard to guarantee except at the operating system level.
EROS does provide checkpointing, but at too coarse a granularity to be useful for a transaction database. (That is, unless I missed something.) You still need to implement a two-phase commit that you know has committed to some non-volatile storage.
Consider an EROS-based transaction database that's sitting between two other entities in a transaction. (For example, suppose it's running bank software at your bank and you're doing an Electronic Funds Transfer.) Just as you initiate the EFT, the EROS box "sends" the money to the remote bank and updates the ledger, and tells everyone that all updates are successful. Now suppose the power goes out at your bank. The remote bank has updated its ledger, you've updated your ledger, but has the EROS box flushed the changes to disk yet?
This problem exists whether or not you've abstracted away RAM vs. disk as EROS does. For certain classes of application, you must know that a given object is committed to non-volatile storage as part of the transaction protocol. (In fact, that's the reason many high-end transaction systems use solid-state "disks" to store transaction journals.) Does EROS provide for this need?
Imagine if you will, how much smaller a database engine could be, if it could simply keep everything it wants to remember in virtual memory.
Smaller and simpler, sure. But, then, you can do that today just by calling mmap() on the database under most Unix systems. What you lose in this design is control. The database software probably has a better picture of what it's going to access, and in what order than does the OS's generic VM/buffer cache. Because it knows this, it can schedule reads and writes much more efficiently (at least in theory) than the OS could. (That's why a number of database engines support a "raw device" mode which bypasses the OS and filesystem altogether.)
This brings up an interesting, related point: Real-time programming has got to be more difficult in such a machine, unless there's a set of APIs (and associated capabilities) for ensuring a set of objects is in memory at a particular time. Otherwise, you have little control over when you fetch data from disk, because as an object, you don't see the disk -- it's abstracted away.
One interesting aspect of EROS' model is that the line between the filesystem and memory seems nonexistant. RAM is merely a cache for objects, and the "state of the universe" is held on the HD. Everything's an object, and the system embodies the continual evolution of those objects. (If I misunderstood, someone please correct me.)
What's interesting about this model is that there is no clear beginning, end, or reboot, just as there isn't any clear concept of a "user" or anything else. The whole system is a collection of objects that are interacting with each other in various ways.
Unless I've missed something, this could lead to an interesting problem wherein the existing pool of objects lacks sufficient capabilities to continue to function. Since the whole system is persistent, how do you recover?
If there is a means to "restart" the system (and bring the system back to a reasonable continuum of objects), how is access to this mechanism controlled? Can you accidentally drop the capability to invoke the "restart"? I don't count the Big Red Button as a reasonable answer for restarting the system...
--Joe --
You need to have the correct "capability".
on
Which BSD?
·
· Score: 1
First, it's still useful against the "broken program" attack, where the attacker guides a broken privileged program to change a file. The broken program is unlikely blindly clearing immutable flags.
Second, the process doing the chattr needs the correct capability to actually do the chattr call. To get a similar effect to securelevel, you can revoke this capability at bootup from all running processes.
--Joe --
Immutable + Linux ==> chattr
on
Which BSD?
·
· Score: 2
The chattr command allows changing file attributes on an ext2 partition. Here's an excerpt from the man-page:
CHATTR(1) CHATTR(1)
NAME chattr -changefileattributeson aLinuxsecondextended file system
The lsattr command allows showing these attributes.
--Joe --
FreeBSD is probably a good starting point
on
Which BSD?
·
· Score: 5
Although I haven't tried it personally*, everything I've seen and heard points to FreeBSD being the smallest leap from Linux. Once you get past the shallow stability/scalability/performance claims, the two aren't appreciably different.
As for the "emulation", I understand it is pretty good. A coworker of mine used to request Linux builds of a particular piece of software I maintained at work, because he was using it on a FreeBSD box, and I had a Linux box. It all worked without a hitch.
As for claims that some software runs faster, I'm sure it does. In general, software will run slightly differently, which includes some operations running faster and others running slower. FreeBSD and Linux are optimized differently -- this is an artifact of the fact that they're completely different implementations of the same basic POSIX and Unix APIs. I'm sure there's a class of problems that each is better at. Making a broad statement that X is faster than Y is pretty much pointless. (Even if Y is a Microsoft product. ;-) )
In the end, you really need to try out different flavors and find the one you're happiest with. If it seems like too much of a hassle, then perhaps that's a hint that the change won't do you much good.
--Joe
(* Note: I did try to install FreeBSD once, but a bug in the Adaptec 7800 driver caused it to trash memory and crash before it even mounted the/ partition. (This was a long time ago and I'm sure it's fixed by now. Linux and FreeBSD have been sharing their AIC7xxx code for awhile now.) Since I needed the machine for some hardcore simulation work, and since I already had a working Linux install, I didn't take the time to debug it then, and haven't gotten back around to it since. This isn't a black-mark against FreeBSD in my mind at all relative to Linux: Not only were the FreeBSD developers willing to help, but also my first Linux installs required similar sorts of hand-holding. The two worlds aren't that different. I've just been too lazy to try another Unix when I have something that works well enough for me.)
Please don't moderate total falsehoods like this up - this is flamebait. Alan Cox, the actual primary code architect of the Linux Kernel, is a Red Hat employee. While RH does often ship a 'tweener' kernel, or one that is in some state of AC's patches, there is nothing at all non-standard about it.
I sense you've missed the point. The Linux 2.2.5-15 kernel that came with RedHat 6.0 is not identical to the stock Linux 2.2.5 kernel. Configuration issues aside, the 2.2.5-15 that shipped with RedHat 6.0 included a handful of other patches as well. This is what makes it a nonstandard kernel. Sure, the patches may be publically available, and sure, they're probably included in an "-ac#" patch, but that doesn't make them part of the mainstream kernel series.
If Pacific Hi-Tech places their clustering patches online for all to download and use, what's the difference? Since it sounds like they're going to try to get Linus to accept them, they've got to be made public anyway. What's the difference if distribution vendor X ships a kernel with H.J. Liu's latest knfsd patches or Pacific Hi Tech's latest clustering patches? Both result in kernels that differ in more than configuration selection from the mainstream kernel.
Just because Alan Cox works for RedHat doesn't mean that RedHat's patches are part of the mainstream kernel. (Same would be true if Transmeta got into the Linux Distrib business and shipped their own tweaked kernel -- despite the fact that Linus works there.) Alan knows and acknowledges that the "-ac" kernels are a sort of feature enhancement mini-fork. (His diary entry for October 21 refers to 2.2.13-ac1 as a feature enhancement addon kit.) To give another concrete example: While the "large FDs" patch was not part of the mainstream kernel, Alan offered it as a separate patch and stated publicly that it's one that many vendors may apply to the kernels they ship, even though it wasn't part of the mainstream kernel. Those patched vendor kernels are non-standard kernels once patched.
There's nothing wrong with shipping a modified kernel, particularly if the modifications are public and can be applied to any kernel. But, such a kernel can hardly be considered standard.
Patenting DNA structures could lead to a whole new form of lawsuit. Since certain aspects of DNA structures are randomly determined (both through mutation and combination during sexual reproduction), it could be possible for anyone to infringe just by living.
I think that's pretty absurd.
"Oh, I'm sorry, we just got the patent on the gene which gives you blue eyes. We felt it was novel because of how it changes the pigment which colors the eye. License the patent or die."
Granted, I doubt that's their intentions. I can see patenting certain processes for building DNA strands, and perhaps even processes for integrating modified DNA within existing tissue. But patenting the DNA patterns themselves is like trying to patent any of nature's creations.
Or perhaps I can put it in slightly less inflammatory words: so long as Linux projects the ability to re-compile the kernel as one of the key features of the OS, Linux will only succeed to the point of being the most popular version of Unix. [...] Key point: Linux, like Unix, appeals to the computerphile--people who are intrinsically interested in how computers work.
I see nothing wrong with this. Linux is a kernel, and most Linux distrobutions do not hide this kernel or the Unix utilities from the user too much. I love it. So do alot of other Linux users.
This model probably doesn't make sense for many typical desktop users, but I don't care. Linux works for me and that's what I do care about. I only care about Linux being more successful to the point that it brings applications that I'm interested in to my platform.
Now, nothing is stopping a motivated vendor from taking the Linux kernel and overlaying a completely non-Unix working environment over it -- eg. one which replaces all of the Unix tools with a comprehensive GUI environment that replaces/sbin/init. Then you can have your GUI only easy to use OS. It wouldn't be Linux in the traditional sense -- it'd be something different. "Lindows" perhaps? Whatever you call it, I won't use it. I won't come near it. It's not for me. It does not cater to my needs. But that's ok, it works for another group of people entirely.
The point? To each his own. Linux does not have to be all things to all people, just like Ferrari's shouldn't come with tow packages, and heavy-duty pickup trucks shouldn't come with lowering springs and spoilers. But, there's nothing stopping you from dropping a nice V12 engine in both.
About a year before I installed Linux on my machine for the first time, I was just starting to learn Unix. During that larval stage, I heard about something unique, something my commercial-software-bred mind never dreamed would exist: A free Unix for 386's.
(And I mean free in the free-beer sense. I wasn't aware of the fact that it came with source code and all the "free-speech" aspect.)
I said to myself "Wow, how can that be?" and started looking into it. What was I looking into? No, not Linux. 388BSD! (eventually FreeBSD.) That's right -- BSD got a head start. I didn't download or install it at the time, since I only had a 386sx25 w/ 4MB RAM and a 120MB HD, and it was getting used for course-work in DOS, GeoWorks, and Win 3.1. I also had a measly 9600 baud serial link to the 'net, so downloading would've been a royal pain.
During that year, hardware got upgraded, I got an ethernet link, my Unix skills matured somewhat, and coursework moved from DOS/Win 3.1 to Unix-centric work. I went back to look for that free Unix I'd heard about, at which time Linux was evangelized to me. Had there been no Linux, I'd be a BSD user today. Instead, I installed SLS 1.03 (and later, Slackware 1.1.1) and never looked back.
That's about the long and the short of it: If there were no Linux, I suspect FreeBSD would've filled its role in my life and in many other hacker's lives. It might not have filled it as nicely, since it's more fun to conduct an OS revolution with an OS which is ostensibly a fresh rewrite, but oh well. Besides, I think Chuck (BSD's cute daemon) is a darn cool mascot for an OS, and could've made up for it.
I suspect if Linux weren't open-source, it would never have reached the critical mass that brought it to so many peoples' attentions back in 1994 and 1995. BSD or Hurd or something may have taken peoples' attention instead. Who knows?
How is it that some older people can't comprehend an ATM, while others can easily use a computer? I don't think it is related to how smart you are, but maybe it is a function of how many brain cells are being created or how their bodies manage to incorporate them into their existing brain.
I remember reading a study awhile back which showed that people who are in occupations where they exercise their mind heavily tend not to lose brain mass. In contrast, people who have relatively mindless jobs (such as bus drivers) tend to actually lose brain mass.
I think this phenomenon is related your question about learning: If you rarely exercise your ability to learn, then your body doesn't bother to maintain that part of the brain, and it literally atrophies. It doesn't matter how much you already know -- if you're not equipped to learn, you can't learn (at least, not easily).
Neurogenesis implies that you might be able to restore some lost functions, depending on where those new neurons are placed. I wouldn't bank alot of money on it.
A different issue that affects people's ability to learn certain topics is fear and/or strong misconceptions: some people are just too afraid (either consciously or subconsciously) of a particular topic to learn anything on it, or too certain that a topic is too difficult to be learned. Basically, both states lock out the person's ability to accept that they can and should learn about the topic at hand. I see both happen computer newbies all the time.
A number of people have posted the same misinformation, namely "Yeah, you can tell it to act like it has a different MAC address, but it'll put you into PROMISC mode and slow your machine down, etc. etc."
Most of these people are probably not actively trying to spread "fear, uncertainty, and doubt" about Linux. However, some people may use that information as FUD. The difference is intention. I guess it's that fine line between "stupidity" and "malice."*
--Joe
* For those who didn't catch it, I'm referring to Hanlon's Razor: "Never attribute to malice what can be adequately explained by stupidity."
DEADBEEF/ded-beef//n./ The hexadecimal word-fill pattern for freshly allocated memory (decimal -21524111) under a number of IBM environments, including the RS/6000. Some modern debugging tools deliberately fill freed memory with this value as a way of converting heisenbugs into Bohr bugs. As in "Your program is DEADBEEF" (meaning gone, aborted, flushed from memory); if you start from an odd half-word boundary, of course, you have BEEFDEAD. See also the anecdote under fool.
I'd have to agree that some sort of explict-parallelism approach such as VLIW is the way to go. Compatibility with future parts at the object code level is difficult, but the gains at a particular process node are worth it. I'd rather spend my transistors on functional units than on hardware scheduling engines, since those are expensive. In contrast, I don't have to ship the compiler with every chip. And even if I did, it's software, which is much, much easier to manipulate.
I say this as someone who codes for a VLIW during my day job.:-)
I think most people have realized that RISC CPUs (in the sense of the early MIPS and SPARC designs) have not been made for a long time. Nowadays, the only real remaining differentiator between a "RISC" machine and a "CISC" machine is whether the instruction set is LOAD/STORE based or has memory operands on various instructions. There are several reasons for this:
Perhaps the largest reason: Backwards compatibility. If you look at the MIPS and SPARC architectures, they both brought to the table the concept of "delay slots". For instance, a LOAD instruction on MIPS won't write its result until after the second cycle, since the LOAD is pipelined over multiple cycles. (SPARC's delayed branches are similar.) Change the pipeline depth, and you sign yourself up for alot of hocus-pocus to continue playing this charade.
The relative cost of operations changes pretty radically over time. For example, when RISC debuted, ideas such as including a multiplier on-chip were out of the question, since they cost too many transistors. So instead, programs implemented multiplies with shifts and adds, or in some cases, with lookup-tables. Nowadays, multipliers are relatively cheap when you consider how much the transistor budget has grown.
Memory latency has gotten really bad relative to CPU performance. This is one of the largest drivers of out-of-order issue, actually. IBM invented this way-back-when before caches were feasible. (It escapes me on which machine they did this, but it was one of the old mainframes.) The idea is that you can cope with latency by allowing instructions to run when their data arrived -- whether it's from a slow memory or slow floating point unit. (Those of you with Hennesey & Patterson on your shelf: Go look up the Tomasulo scheduling algorithm.)
The cost of communication and control has gone way up as pipelines have gotten deeper and transistors have gotten faster than the wires that connect them. "Complex" instructions which reduce communication, and sophisticated branch-prediction schemes which try to flatten control are attempts to address these issues.
The point is that these are difficult problems, no matter what type of architecture you have. Even Alpha spends alot of transistors allowing such things as "hit under miss" in the cache (allowing one stream of instructions to proceed while another is stalled waiting for a cache service).
Every so often, when the gap between the original "programmer's model of the architecture" and "what we can do easily in silicon" gets too wide, it becomes necessary to move to a new paradigm. With this shift comes a new programmer's model. Moving from "CISC" to "RISC" was one such paradigm shift. One could argue that we're due for another one, and that VLIW/EPIC-like schemes are the new contenders.
Some approaches, such as traditional VLIW, say "We're not going to worry so much about bout presenting a traditional scalar model to the programmer. We're going to expose our complexity to the compiler and let it do its best, rather than play tricks behind its back." These work by exposing the functional units of the machine, removing alot of the control complexity. These are today's "direct execution" architectures. (See TI's C6000 DSP family for a live example of VLIW in the field.)
Intel's EPIC takes VLIW a step further. It adopts alot of the explicitness of VLIW, but it retains alot of the chip complexity that's required to retain compatibility across widely varying family members. It's too early to know how this will turn out, but I'm somewhat concerned that it does not reduce complexity.
All-in-all, it'll be interesting to see how this turns out. Who knows what type of architectures we'll be programming in 20 years...
The keyword list is about the right length that you could use it as a sort of base-64 encoding for encrypted mail. (There are more than 64 key words, but several of them group in phrases. You could define a set of 64 symbols pretty easily from this list.) Instead of using PGP-style "ASCII armor", you could use "Echelon armor" on your encrypted emails.
Now how's that for fun? Anyone care to write a quick-and-dirty perl filter to convert base-64 into echelon-64 and back?:-)
Slashdot Mirror
I can't say I like Impalas. Until the recent redesign, they just looked like Caprice's w/ wide tires. Big, slow, ugly.
Now the Grand Prix.... :-) Or if you want something a bit bigger, the new Bonneville....
--Joe--
Most modems have alot of extra processing to handle error correction, compression, and other things. I can imagine that a "Gamer's Modem" would cut out the non-essential steps such as V.42bis compression. It might also bypass some of the other bandwidth-enhancing tricks they do, trading bandwidth for latency.
Also, depending on how fancy they are, they might be doing some IP-level tricks, although I'd hope they're not. (This is reminiscent of the XModem-accelerating modems of several years ago that would fake an XModem ACK to speed up downloads, since XModem didn't stream.)
--Joe--
One possible reason for such a competition is to actively seek out poor performing systems and use them to try to understand how best to fix the operating system. For example, in the Linux world, people now complain about long fsck times on huge filesystems, so the Linux community responds by developing journalled filesystems. (Note that in the early days, filesystems weren't huge enough to make fsck times an issue for most users. Nowadays, even typical home-user filesystems are large enough to cause a minor headache. This sort of model -- fix what the users say is broken now, even if it wasn't broken before -- is a reasonably good model.)
I'm not saying that Microsoft is behind this contest, but it would be an interesting (and good) if they were. This is an effective way to find out where a product is not doing as well as it should and can be improved, and it's something I think every software vendor should do.
Other industries do this. My dad used to work at the GM plant where they build the 3800 Series II V6 Engine. (This is the power plant that comes in the 3.8L Grand Prix, Bonneville, and some other cars. I personally own a supercharged Grand Prix GTP.) The 3800 apparently has a legendary track record as one of the most stable engines GM has produced in recent memory. Nonetheless, they purchased a used 3800 engine from a cab company that had somewhere around 300K miles on it, to do failure analysis on it so that they could make their engines even better. The disassembled engine is now on proud display at the plant as a testament to how good of an engine it was.
What would be interesting is if Microsoft did the same: "Show us your worst performing servers, and as a prize, we'll exchange your servers for new ones and use your old ones to do performance analysis so this problem doesn't happen again."
--Joe--
These are very good tips. (In particular, I had missed the "1 inode per 4K bytes" bit in my brief encounter with the mke2fs manpage, but indeed that's the default.)
BTW, for the curious, the magic incantation that produces the above set of parameters is like so: mke2fs -b 4096 -i 131072 /dev/ whatever
I have a 17Gb hard-drive that I use for CD-ROM images for when I build music-compilation CDRs. These tips would work great on this HD, particularly for the odd case when I have to fsck. Note that a 4Kb cluster size should also speed up most other operations on large files, particularly those which require synchronous metadata updates, such as rm's.
(Note: I've only had one Linux kernel crash that I can remember since getting this drive, due to some strange interaction between burning a CD, playing a WAV file and insmod'ing the floppy driver from kerneld on a kernel that would have preferred kmod. The rest have been stupids like bumping the power switch, having a UPS go bad, etc.)
--Joe--
Intel is pushing your third bullet into new territory by claiming that Pentium III has special features for "enhancing your Internet experience" (whatever that means*).
The average AOL-esqe consumer will fall for it, certainly. Yay marketing.
--Joe(* Note: I know it refers to using SSE-enabled plugins to view content on special websites. Plugins are just another opportunity for my browser to crash -- they do not 'enhance my Internet experience'. If a site requires them, I just visit a different site.)
--
You forget... K5 came out after Pentium, and K6 came out after the P6 family parts. K7/Athlon is the first time AMD has actually beaten Intel to the punch.
--Joe--
EROS does provide checkpointing, but at too coarse a granularity to be useful for a transaction database. (That is, unless I missed something.) You still need to implement a two-phase commit that you know has committed to some non-volatile storage.
Consider an EROS-based transaction database that's sitting between two other entities in a transaction. (For example, suppose it's running bank software at your bank and you're doing an Electronic Funds Transfer.) Just as you initiate the EFT, the EROS box "sends" the money to the remote bank and updates the ledger, and tells everyone that all updates are successful. Now suppose the power goes out at your bank. The remote bank has updated its ledger, you've updated your ledger, but has the EROS box flushed the changes to disk yet?
This problem exists whether or not you've abstracted away RAM vs. disk as EROS does. For certain classes of application, you must know that a given object is committed to non-volatile storage as part of the transaction protocol. (In fact, that's the reason many high-end transaction systems use solid-state "disks" to store transaction journals.) Does EROS provide for this need?
--Joe--
Smaller and simpler, sure. But, then, you can do that today just by calling mmap() on the database under most Unix systems. What you lose in this design is control. The database software probably has a better picture of what it's going to access, and in what order than does the OS's generic VM/buffer cache. Because it knows this, it can schedule reads and writes much more efficiently (at least in theory) than the OS could. (That's why a number of database engines support a "raw device" mode which bypasses the OS and filesystem altogether.)
This brings up an interesting, related point: Real-time programming has got to be more difficult in such a machine, unless there's a set of APIs (and associated capabilities) for ensuring a set of objects is in memory at a particular time. Otherwise, you have little control over when you fetch data from disk, because as an object, you don't see the disk -- it's abstracted away.
--Joe--
One interesting aspect of EROS' model is that the line between the filesystem and memory seems nonexistant. RAM is merely a cache for objects, and the "state of the universe" is held on the HD. Everything's an object, and the system embodies the continual evolution of those objects. (If I misunderstood, someone please correct me.)
What's interesting about this model is that there is no clear beginning, end, or reboot, just as there isn't any clear concept of a "user" or anything else. The whole system is a collection of objects that are interacting with each other in various ways.
Unless I've missed something, this could lead to an interesting problem wherein the existing pool of objects lacks sufficient capabilities to continue to function. Since the whole system is persistent, how do you recover?
If there is a means to "restart" the system (and bring the system back to a reasonable continuum of objects), how is access to this mechanism controlled? Can you accidentally drop the capability to invoke the "restart"? I don't count the Big Red Button as a reasonable answer for restarting the system...
--Joe--
First, it's still useful against the "broken program" attack, where the attacker guides a broken privileged program to change a file. The broken program is unlikely blindly clearing immutable flags.
Second, the process doing the chattr needs the correct capability to actually do the chattr call. To get a similar effect to securelevel, you can revoke this capability at bootup from all running processes.
--Joe--
The chattr command allows changing file attributes on an ext2 partition. Here's an excerpt from the man-page:
CHATTR(1) CHATTR(1)
NAME
chattr -changefileattributeson aLinuxsecondextended
file system
SYNOPSIS
chattr [-RV] [-vversion ][mode]files...
DESCRIPTION
chattr changesthefile attributesona Linuxsecond
extendedfilesystem.
The lsattr command allows showing these attributes.
--Joe--
Although I haven't tried it personally*, everything I've seen and heard points to FreeBSD being the smallest leap from Linux. Once you get past the shallow stability/scalability/performance claims, the two aren't appreciably different.
As for the "emulation", I understand it is pretty good. A coworker of mine used to request Linux builds of a particular piece of software I maintained at work, because he was using it on a FreeBSD box, and I had a Linux box. It all worked without a hitch.
As for claims that some software runs faster, I'm sure it does. In general, software will run slightly differently, which includes some operations running faster and others running slower. FreeBSD and Linux are optimized differently -- this is an artifact of the fact that they're completely different implementations of the same basic POSIX and Unix APIs. I'm sure there's a class of problems that each is better at. Making a broad statement that X is faster than Y is pretty much pointless. (Even if Y is a Microsoft product. ;-) )
In the end, you really need to try out different flavors and find the one you're happiest with. If it seems like too much of a hassle, then perhaps that's a hint that the change won't do you much good.
--Joe(* Note: I did try to install FreeBSD once, but a bug in the Adaptec 7800 driver caused it to trash memory and crash before it even mounted the / partition. (This was a long time ago and I'm sure it's fixed by now. Linux and FreeBSD have been sharing their AIC7xxx code for awhile now.) Since I needed the machine for some hardcore simulation work, and since I already had a working Linux install, I didn't take the time to debug it then, and haven't gotten back around to it since. This isn't a black-mark against FreeBSD in my mind at all relative to Linux: Not only were the FreeBSD developers willing to help, but also my first Linux installs required similar sorts of hand-holding. The two worlds aren't that different. I've just been too lazy to try another Unix when I have something that works well enough for me.)
--
I sense you've missed the point. The Linux 2.2.5-15 kernel that came with RedHat 6.0 is not identical to the stock Linux 2.2.5 kernel. Configuration issues aside, the 2.2.5-15 that shipped with RedHat 6.0 included a handful of other patches as well. This is what makes it a nonstandard kernel. Sure, the patches may be publically available, and sure, they're probably included in an "-ac#" patch, but that doesn't make them part of the mainstream kernel series.
If Pacific Hi-Tech places their clustering patches online for all to download and use, what's the difference? Since it sounds like they're going to try to get Linus to accept them, they've got to be made public anyway. What's the difference if distribution vendor X ships a kernel with H.J. Liu's latest knfsd patches or Pacific Hi Tech's latest clustering patches? Both result in kernels that differ in more than configuration selection from the mainstream kernel.
Just because Alan Cox works for RedHat doesn't mean that RedHat's patches are part of the mainstream kernel. (Same would be true if Transmeta got into the Linux Distrib business and shipped their own tweaked kernel -- despite the fact that Linus works there.) Alan knows and acknowledges that the "-ac" kernels are a sort of feature enhancement mini-fork. (His diary entry for October 21 refers to 2.2.13-ac1 as a feature enhancement addon kit.) To give another concrete example: While the "large FDs" patch was not part of the mainstream kernel, Alan offered it as a separate patch and stated publicly that it's one that many vendors may apply to the kernels they ship, even though it wasn't part of the mainstream kernel. Those patched vendor kernels are non-standard kernels once patched.
There's nothing wrong with shipping a modified kernel, particularly if the modifications are public and can be applied to any kernel. But, such a kernel can hardly be considered standard.
--Joe--
...there is no spoon.
--Joe--
Patenting DNA structures could lead to a whole new form of lawsuit. Since certain aspects of DNA structures are randomly determined (both through mutation and combination during sexual reproduction), it could be possible for anyone to infringe just by living.
I think that's pretty absurd.
"Oh, I'm sorry, we just got the patent on the gene which gives you blue eyes. We felt it was novel because of how it changes the pigment which colors the eye. License the patent or die."
Granted, I doubt that's their intentions. I can see patenting certain processes for building DNA strands, and perhaps even processes for integrating modified DNA within existing tissue. But patenting the DNA patterns themselves is like trying to patent any of nature's creations.
--Joe--
I see nothing wrong with this. Linux is a kernel, and most Linux distrobutions do not hide this kernel or the Unix utilities from the user too much. I love it. So do alot of other Linux users.
This model probably doesn't make sense for many typical desktop users, but I don't care. Linux works for me and that's what I do care about. I only care about Linux being more successful to the point that it brings applications that I'm interested in to my platform.
Now, nothing is stopping a motivated vendor from taking the Linux kernel and overlaying a completely non-Unix working environment over it -- eg. one which replaces all of the Unix tools with a comprehensive GUI environment that replaces /sbin/init. Then you can have your GUI only easy to use OS. It wouldn't be Linux in the traditional sense -- it'd be something different. "Lindows" perhaps? Whatever you call it, I won't use it. I won't come near it. It's not for me. It does not cater to my needs. But that's ok, it works for another group of people entirely.
The point? To each his own. Linux does not have to be all things to all people, just like Ferrari's shouldn't come with tow packages, and heavy-duty pickup trucks shouldn't come with lowering springs and spoilers. But, there's nothing stopping you from dropping a nice V12 engine in both.
--Joe--
About a year before I installed Linux on my machine for the first time, I was just starting to learn Unix. During that larval stage, I heard about something unique, something my commercial-software-bred mind never dreamed would exist: A free Unix for 386's.
(And I mean free in the free-beer sense. I wasn't aware of the fact that it came with source code and all the "free-speech" aspect.)
I said to myself "Wow, how can that be?" and started looking into it. What was I looking into? No, not Linux. 388BSD! (eventually FreeBSD.) That's right -- BSD got a head start. I didn't download or install it at the time, since I only had a 386sx25 w/ 4MB RAM and a 120MB HD, and it was getting used for course-work in DOS, GeoWorks, and Win 3.1. I also had a measly 9600 baud serial link to the 'net, so downloading would've been a royal pain.
During that year, hardware got upgraded, I got an ethernet link, my Unix skills matured somewhat, and coursework moved from DOS/Win 3.1 to Unix-centric work. I went back to look for that free Unix I'd heard about, at which time Linux was evangelized to me. Had there been no Linux, I'd be a BSD user today. Instead, I installed SLS 1.03 (and later, Slackware 1.1.1) and never looked back.
That's about the long and the short of it: If there were no Linux, I suspect FreeBSD would've filled its role in my life and in many other hacker's lives. It might not have filled it as nicely, since it's more fun to conduct an OS revolution with an OS which is ostensibly a fresh rewrite, but oh well. Besides, I think Chuck (BSD's cute daemon) is a darn cool mascot for an OS, and could've made up for it.
I suspect if Linux weren't open-source, it would never have reached the critical mass that brought it to so many peoples' attentions back in 1994 and 1995. BSD or Hurd or something may have taken peoples' attention instead. Who knows?
--Joe--
Have you seen Alan Cox's Portaloo yet? It provides a reasonably spartan display, and seems to focus on providing information only, rather than glitz.
What's even nicer is that it's open source, and so you can modify it to provide whatever you like. :-)
--Joe--
"Your Mama" was the Slashdot nick of the person who submitted the article. (See the Slashdot article text at the top. "Your Mama writes...")
--Joe--
I remember reading a study awhile back which showed that people who are in occupations where they exercise their mind heavily tend not to lose brain mass. In contrast, people who have relatively mindless jobs (such as bus drivers) tend to actually lose brain mass.
I think this phenomenon is related your question about learning: If you rarely exercise your ability to learn, then your body doesn't bother to maintain that part of the brain, and it literally atrophies. It doesn't matter how much you already know -- if you're not equipped to learn, you can't learn (at least, not easily).
Neurogenesis implies that you might be able to restore some lost functions, depending on where those new neurons are placed. I wouldn't bank alot of money on it.
A different issue that affects people's ability to learn certain topics is fear and/or strong misconceptions: some people are just too afraid (either consciously or subconsciously) of a particular topic to learn anything on it, or too certain that a topic is too difficult to be learned. Basically, both states lock out the person's ability to accept that they can and should learn about the topic at hand. I see both happen computer newbies all the time.
--Joe--
A number of people have posted the same misinformation, namely "Yeah, you can tell it to act like it has a different MAC address, but it'll put you into PROMISC mode and slow your machine down, etc. etc."
Most of these people are probably not actively trying to spread "fear, uncertainty, and doubt" about Linux. However, some people may use that information as FUD. The difference is intention. I guess it's that fine line between "stupidity" and "malice."*
--Joe* For those who didn't catch it, I'm referring to Hanlon's Razor: "Never attribute to malice what can be adequately explained by stupidity."
--
Old IBM Mainframes did it. See the jargon file:
--Joe--
I'd have to agree that some sort of explict-parallelism approach such as VLIW is the way to go. Compatibility with future parts at the object code level is difficult, but the gains at a particular process node are worth it. I'd rather spend my transistors on functional units than on hardware scheduling engines, since those are expensive. In contrast, I don't have to ship the compiler with every chip. And even if I did, it's software, which is much, much easier to manipulate.
I say this as someone who codes for a VLIW during my day job. :-)
--Joe--
I think most people have realized that RISC CPUs (in the sense of the early MIPS and SPARC designs) have not been made for a long time. Nowadays, the only real remaining differentiator between a "RISC" machine and a "CISC" machine is whether the instruction set is LOAD/STORE based or has memory operands on various instructions. There are several reasons for this:
Perhaps the largest reason: Backwards compatibility. If you look at the MIPS and SPARC architectures, they both brought to the table the concept of "delay slots". For instance, a LOAD instruction on MIPS won't write its result until after the second cycle, since the LOAD is pipelined over multiple cycles. (SPARC's delayed branches are similar.) Change the pipeline depth, and you sign yourself up for alot of hocus-pocus to continue playing this charade.
The relative cost of operations changes pretty radically over time. For example, when RISC debuted, ideas such as including a multiplier on-chip were out of the question, since they cost too many transistors. So instead, programs implemented multiplies with shifts and adds, or in some cases, with lookup-tables. Nowadays, multipliers are relatively cheap when you consider how much the transistor budget has grown.
Memory latency has gotten really bad relative to CPU performance. This is one of the largest drivers of out-of-order issue, actually. IBM invented this way-back-when before caches were feasible. (It escapes me on which machine they did this, but it was one of the old mainframes.) The idea is that you can cope with latency by allowing instructions to run when their data arrived -- whether it's from a slow memory or slow floating point unit. (Those of you with Hennesey & Patterson on your shelf: Go look up the Tomasulo scheduling algorithm.)
The cost of communication and control has gone way up as pipelines have gotten deeper and transistors have gotten faster than the wires that connect them. "Complex" instructions which reduce communication, and sophisticated branch-prediction schemes which try to flatten control are attempts to address these issues.
The point is that these are difficult problems, no matter what type of architecture you have. Even Alpha spends alot of transistors allowing such things as "hit under miss" in the cache (allowing one stream of instructions to proceed while another is stalled waiting for a cache service).
Every so often, when the gap between the original "programmer's model of the architecture" and "what we can do easily in silicon" gets too wide, it becomes necessary to move to a new paradigm. With this shift comes a new programmer's model. Moving from "CISC" to "RISC" was one such paradigm shift. One could argue that we're due for another one, and that VLIW/EPIC-like schemes are the new contenders.
Some approaches, such as traditional VLIW, say "We're not going to worry so much about bout presenting a traditional scalar model to the programmer. We're going to expose our complexity to the compiler and let it do its best, rather than play tricks behind its back." These work by exposing the functional units of the machine, removing alot of the control complexity. These are today's "direct execution" architectures. (See TI's C6000 DSP family for a live example of VLIW in the field.)
Intel's EPIC takes VLIW a step further. It adopts alot of the explicitness of VLIW, but it retains alot of the chip complexity that's required to retain compatibility across widely varying family members. It's too early to know how this will turn out, but I'm somewhat concerned that it does not reduce complexity.
All-in-all, it'll be interesting to see how this turns out. Who knows what type of architectures we'll be programming in 20 years...
--Joe--
The keyword list is about the right length that you could use it as a sort of base-64 encoding for encrypted mail. (There are more than 64 key words, but several of them group in phrases. You could define a set of 64 symbols pretty easily from this list.) Instead of using PGP-style "ASCII armor", you could use "Echelon armor" on your encrypted emails.
Now how's that for fun? Anyone care to write a quick-and-dirty perl filter to convert base-64 into echelon-64 and back? :-)
--Joe--