In my experience, the amiga filesystem has been very slow and unreliable.
It used linked lists for metadata. Directories and "file inodes" used linked lists when they occupied more than one block. At that time files weren't very big, so the fact that they used linked lists shouldn't have had an important performance hit. In the other hand, it was very slow, specially on floppies. Directories just contained a hash table of pointers to the "inode" of each file or directory. I guess it was so slow because the directory didn't have the names of the files in it. Instead, every name was in its file "inode". The result is that the disk head went mad every time you needed a directory listing. And, in case it wasn't still slow enough, some metadata was stored in ".info" files. This metadata included protections (rwxa), filetype (app, script, datafile), icon image, tool used to open the file (if it was a data file) and an additional list of textual properties for data files. When you opened a directory in the file manager (workbench), the system had to read lots of non contiguous blocks which slowed the system a lot. Also, not related to the filesystem but to the feel of it, the icon layout system wasn't scallable in speed. I guess it was quadratic at least.
In the reliability front my experience has been disastrous. After rebooting during hard disk activity, many times the disk checking tool (diskdoctor) couldn't repair the partition that was being writen at the time of reboot. I guess it was a problem with write ordering.
Journaling your filesystem allows you to maintain integrity through a system crash or power outage.
I'd like to point out that under a system crash you can't guarantee anything, and a journaling filesystem can't help there. The reason is that when the system crashes it may have already corrupted data that has been sent to disk. A journaling filesystem could unroll the changes back to the moment data corruption began, if that moment could be determined and the required data was still in the journal. In most cases it's impossible to determine when data corruption began, and then the journaling can't help there.
Note that journaling your filesystem only keeps the metadata intact, not the file data itself.
It depends on the filesystem. For example, ext3 allows both modes: just metadata or full journaling.
68K architecture may have 16 registers, but they are 16-bit
68K registers have always been 32 bits wide.
On top of that, you can get away with only mapping 7 or 8 (D0, D1, D2, A0, A1, A5, A6, A7), because the rest aren't often used.
If the 68K family has 16 registers is for a reason: speed. Accessing memory is slow. Compilers take full advantadge of the registers to avoid accessing memory, so the argument that only a small set of the registers are often used does not hold. If you need further proof, just search for some m68k assembly generated by a C compiler.
The number of registers is *very* important, because each significantly used register that you can't map is one that will have to be fetched from cache or from main memory very often. That adds up to a very significant performance drop.
Remember that we are talking about the x86 architecture, so you have 8 semi-GPR. From those 8 registers you need two for stack management, so you just have 6 left. You'll need at least another register to use as a base to access to data, for example the status word stored in a struct with other important data. So you might just get 5 registers left to map to emulated registers. The point is that you'll end up effectively mapping 4 from 16 registers, so you'll be basically accessing memory all the time. This is no different from emulating a PPC.
The PPC memory manager may be somewhat trickier to implement than the 68K memory manager but not that much, and in many ways the PPC instruction set should be easier to implement than the 68K one. It has much fewer addressing modes and only one way to load to and store from memory.
In theory a RISC architecture is much more simple to emulate than a CISC architecture, specially memory access, and I fully agree with you in that aspect. In the other hand the PPC is not an extremely RISC architecture as an Alpha could be. Just take a look at the different variants for each basic instruction. There are several opcodes for the move from register to register, each with subtle differences. And this situation repeats for every basic (purely RISC) instructuction. In fact the PPC is not that RISCy (REDUCED Instruction Set Chip).
The old Mac OS for the m68k architecture didn't make use of the MMU. Then, it doesn't make much sense to write suport for it. In the PPC case the situations is very different. Mac OS X uses the MMU. I think that the MMU must be the complex aspect of coding a PPC emulator which might slow down the emulation so much that it can render it useles for any practical purpose.
I originally replied to your post because I found it misleading. Again I'm replying to a post that's not just misleading but has big factual mistakes (e.g. 16 bit registers). I don't belive that that post deserves a +3, I think it deserves a -1 Misleading. Please, moderate posts properly.
PPC has tons more general purpose registers than x86 does. There is a reason why the only Macintosh emulators for x86 only do 68K emulation.
There must be a reason why there are no PPC emulators for x86, but the number or registers is not one. The 68K family has 16 semi-general purpose registers while the x86 has half that, and there have been 68k emulators for x86 for a long time. In fact, the number of registers to be emulated is not that important when you can't map to the registers of the host machine because there are not enougth. But in any case going from 16 to 32 registers doesn't add any complexity. I guess the complexity lies in the instruction set and the MMU.
You can't even rely on that. I have an Epson C70 which is similar to a C80 (for US people) which uses ink cartridges labeled "Intellidge". Those cartridges have an embedded chip that controls the ink level. There's were theory ends, because those chips just have a counter that when reachs zero doesn't let you print anymore with that cartridge. I have opened two of them after they had been "ended", a black one and a yellow one. The amount of ink that remainded was just disapointing, it was around half a cartridge. The real story is that not only they sell cartridges that are not full, they even sell ink that they don't allow you to use!
For Terminal Server, you DO need a specific OS -- Windows. And the "specific OS" you need for X is... Unix, Windows, OS/2, OSX, BeOS,... Hey, there's even an X server written in java. Sorry, still have X beat on that front.
If I recall correctly VMS had an equivalent command that also accepted multi assigns.
Also VMS like the amiga is dead.
It's a shame that they all died.
> Reminds me when IBM's JFS 1.0 kernel patch came out. I spend a day converting my workstation to it, and on the first fsck.jfs that was run, my file system was -nuked-, destroyed, whiped away.. Ever since i'm waiting for the 1.1.0 release:P
I had the same experience. My first fsck on JFS destroyed the root directory. It makes you wonder if IBM is being really serious about Linux. You should take into account that that was version 1.0 and it should have been extra tested.
I've checked reiser too and had minor data corruption from time to time and some crashes which I relate to data corruption.
Then I changed to XFS and I've been using it for 2 months and I haven't had any problem with it. I hope it makes into the standard kernel source soon, as I think it deserves to.
Wouldn't it be better to compile C or whatever language just to the level of the optimized abstract sintax tree/three way instructions and save it as a VM code rather than try to invent another incompatible language?
I think that detecting viruses at the mail server is an interesting idea. But on the other hand it doesn't stop other machines from getting viruses by other ways. You can't control what others execute and that's why you would be better puting an antivirus rigth where the virus can infect. In fact, e-mail clients are the ones that should take care of viruses that are embedded in e-mails, not the mail server. If a virus infects a client it's because the e-mail client is broken, not because e-mail by itself or the server are inherently insecure.
Why do I always hit "Submit" and then try to hit "Preview"?
I think people are putting this out of context. From Ace's Hardware:
"Finally, I also want to make note of
this Register story in which Craig Barrett of Intel responded to the recent licensing deals by reminding us that DRAM makers can produce clean-room versions of SDRAM and DDR SDRAM technologies (much like Compaq with the PC BIOS, and so on)."
I haven't tried doing what you explain, but maybe, if you are using pthreads you could make sure that the read-ahead (p)thread gets mapped directly into a kernel thread. It could happen that you have two user threads but one kernel thread and pthreads doing the switch at user level. Maybe I'm wrong and processes block on I/O but I can't guess why.
From http://www.aceshardware.com on August 07: "AMD will take the basic core processor and tweak the surrounding technology slightly for different markets. Bus speeds, which determine how fast the chip speaks to the main memory, will differ between product segments. . . . Chip packaging, motherboard design and chipsets also will differ." Athlon Ultra will be targeted at server/workstation market and have faster buses, SMP capabilities, larger L2 cache (up to 8 MB) Ahtlon Professional will be targeted at performance/commercial desktops and no SMP. These are the Athlon processors that are coming out next week Athlon Select, the "economical" version, will come in a "different package" than the Athlon Pro and "may not contain as many features."
I guess neither the Athlons that are selling now nor the socketed ones will be SMPable.
Out of topic: In Spain there is a company that produces bleech and related things that, guess that, it's name is "Athlon". My mother has one bottle, so maybe some day you'll see it (when I get a cam).
Have you ever heard of QNX (http://www.qnx.com)?. They make a kernel for real time systems that is so small that it fits in the CPU's first level cache. The idea behind it is that in real time systems you need responses as fast as possible.
I don't like the concept of buying a motherboard which locks you into a specific processor.
Well, then why did you buy a Celeron 433-compatible board if it only works with celerons?
Don't get me wrong. You'll never have a motherboard that works for different Intel processors. Intel also sells chipsets. They just change the CPU's packaging to make you buy a new motherboad and have you pay them one more time for their chipset. It's just a way to exploit their monopoly to grab more money from you.
I don't think this is bad for Apple. If Intel adopted Firewire then PC's could use Cams and other peripherals that only the Mac's use. That would be terrible for Apple because they would loose their market.
JPEG is lossy because it discards high frequencies. Is it right? PNG doen't discard data but it uses a logarithmic scale which could make an effect similar to a quantization. Anyone knows if is this right?
Slashdot Mirror
In my experience, the amiga filesystem has been very slow and unreliable.
It used linked lists for metadata. Directories and "file inodes" used linked lists when they occupied more than one block. At that time files weren't very big, so the fact that they used linked lists shouldn't have had an important performance hit. In the other hand, it was very slow, specially on floppies. Directories just contained a hash table of pointers to the "inode" of each file or directory. I guess it was so slow because the directory didn't have the names of the files in it. Instead, every name was in its file "inode". The result is that the disk head went mad every time you needed a directory listing. And, in case it wasn't still slow enough, some metadata was stored in ".info" files. This metadata included protections (rwxa), filetype (app, script, datafile), icon image, tool used to open the file (if it was a data file) and an additional list of textual properties for data files. When you opened a directory in the file manager (workbench), the system had to read lots of non contiguous blocks which slowed the system a lot. Also, not related to the filesystem but to the feel of it, the icon layout system wasn't scallable in speed. I guess it was quadratic at least.
In the reliability front my experience has been disastrous. After rebooting during hard disk activity, many times the disk checking tool (diskdoctor) couldn't repair the partition that was being writen at the time of reboot. I guess it was a problem with write ordering.
Journaling your filesystem allows you to maintain integrity through a system crash or power outage.
I'd like to point out that under a system crash you can't guarantee anything, and a journaling filesystem can't help there. The reason is that when the system crashes it may have already corrupted data that has been sent to disk. A journaling filesystem could unroll the changes back to the moment data corruption began, if that moment could be determined and the required data was still in the journal. In most cases it's impossible to determine when data corruption began, and then the journaling can't help there.
Note that journaling your filesystem only keeps the metadata intact, not the file data itself.
It depends on the filesystem. For example, ext3 allows both modes: just metadata or full journaling.
68K architecture may have 16 registers, but they are 16-bit
68K registers have always been 32 bits wide.
On top of that, you can get away with only mapping 7 or 8 (D0, D1, D2, A0, A1, A5, A6, A7), because the rest aren't often used.
If the 68K family has 16 registers is for a reason: speed. Accessing memory is slow. Compilers take full advantadge of the registers to avoid accessing memory, so the argument that only a small set of the registers are often used does not hold. If you need further proof, just search for some m68k assembly generated by a C compiler.
The number of registers is *very* important, because each significantly used register that you can't map is one that will have to be fetched from cache or from main memory very often. That adds up to a very significant performance drop.
Remember that we are talking about the x86 architecture, so you have 8 semi-GPR. From those 8 registers you need two for stack management, so you just have 6 left. You'll need at least another register to use as a base to access to data, for example the status word stored in a struct with other important data. So you might just get 5 registers left to map to emulated registers. The point is that you'll end up effectively mapping 4 from 16 registers, so you'll be basically accessing memory all the time. This is no different from emulating a PPC.The PPC memory manager may be somewhat trickier to implement than the 68K memory manager but not that much, and in many ways the PPC instruction set should be easier to implement than the 68K one. It has much fewer addressing modes and only one way to load to and store from memory.
In theory a RISC architecture is much more simple to emulate than a CISC architecture, specially memory access, and I fully agree with you in that aspect. In the other hand the PPC is not an extremely RISC architecture as an Alpha could be. Just take a look at the different variants for each basic instruction. There are several opcodes for the move from register to register, each with subtle differences. And this situation repeats for every basic (purely RISC) instructuction. In fact the PPC is not that RISCy (REDUCED Instruction Set Chip).
The old Mac OS for the m68k architecture didn't make use of the MMU. Then, it doesn't make much sense to write suport for it. In the PPC case the situations is very different. Mac OS X uses the MMU. I think that the MMU must be the complex aspect of coding a PPC emulator which might slow down the emulation so much that it can render it useles for any practical purpose.
I originally replied to your post because I found it misleading. Again I'm replying to a post that's not just misleading but has big factual mistakes (e.g. 16 bit registers). I don't belive that that post deserves a +3, I think it deserves a -1 Misleading. Please, moderate posts properly.
missleadingPPC has tons more general purpose registers than x86 does. There is a reason why the only Macintosh emulators for x86 only do 68K emulation.
There must be a reason why there are no PPC emulators for x86, but the number or registers is not one. The 68K family has 16 semi-general purpose registers while the x86 has half that, and there have been 68k emulators for x86 for a long time. In fact, the number of registers to be emulated is not that important when you can't map to the registers of the host machine because there are not enougth. But in any case going from 16 to 32 registers doesn't add any complexity. I guess the complexity lies in the instruction set and the MMU.
> Look and compare the measure of ml on the box!
You can't even rely on that. I have an Epson C70 which is similar to a C80 (for US people) which uses ink cartridges labeled "Intellidge". Those cartridges have an embedded chip that controls the ink level.
There's were theory ends, because those chips just have a counter that when reachs zero doesn't let you print anymore with that cartridge. I have opened two of them after they had been "ended", a black one and a yellow one. The amount of ink that remainded was just disapointing, it was around half a cartridge.
The real story is that not only they sell cartridges that are not full, they even sell ink that they don't allow you to use!
For Terminal Server, you DO need a specific OS -- Windows. And the "specific OS" you need for X is ... Unix, Windows, OS/2, OSX, BeOS, ... Hey, there's even an X server written in java. Sorry, still have X beat on that front.
If I recall correctly VMS had an equivalent command that also accepted multi assigns.
Also VMS like the amiga is dead.
It's a shame that they all died.
> Reminds me when IBM's JFS 1.0 kernel patch came out. I spend a day converting my workstation to it, and on the first fsck.jfs that was run, my file system was -nuked-, destroyed, whiped away.. Ever since i'm waiting for the 1.1.0 release :P
I had the same experience. My first fsck on JFS destroyed the root directory. It makes you wonder if IBM is being really serious about Linux. You should take into account that that was version 1.0 and it should have been extra tested.
I've checked reiser too and had minor data corruption from time to time and some crashes which I relate to data corruption.
Then I changed to XFS and I've been using it for 2 months and I haven't had any problem with it. I hope it makes into the standard kernel source soon, as I think it deserves to.
You shouldn't run it as root. If it had an exploit someone could do nasty things to your machine.
:)
(Yeah, I go it
Wouldn't it be better to compile C or whatever language just to the level of the optimized abstract sintax tree/three way instructions and save it as a VM code rather than try to invent another incompatible language?
Just my two cent euro.
I just got used to typing "del *.*;*" a lot to erase all the versions.
Then you deleted all the versions! Why didn't you just use "purge"?
Finally I got it. They are collecting e-mail addresses to sell them for spammers. Just a guess, but that's the only idea that makes sense.
I think that detecting viruses at the mail server is an interesting idea. But on the other hand it doesn't stop other machines from getting viruses by other ways. You can't control what others execute and that's why you would be better puting an antivirus rigth where the virus can infect.
In fact, e-mail clients are the ones that should take care of viruses that are embedded in e-mails, not the mail server. If a virus infects a client it's because the e-mail client is broken, not because e-mail by itself or the server are inherently insecure.
Why do I always hit "Submit" and then try to hit "Preview"?
But you wouldn't put a mail server in a workstation that is meant to be used for "Office applications", would you?
Why sould you need an antivirus in Linux?
From Ace's Hardware:
First Troll Tech managed to kill off Project Harmony. Is the Open Group Trying to kill lesstif?
Post the IP's the messages came from in a separate story for everyone to know.
I haven't tried doing what you explain, but maybe, if you are using pthreads you could make sure that the read-ahead (p)thread gets mapped directly into a kernel thread. It could happen that you have two user threads but one kernel thread and pthreads doing the switch at user level.
Maybe I'm wrong and processes block on I/O but I can't guess why.
From http://www.aceshardware.com on August 07:
"AMD will take the basic core processor and tweak the surrounding technology slightly for different markets. Bus speeds, which determine how fast the chip speaks to the main memory, will differ between product segments. . . . Chip packaging, motherboard design and chipsets also will differ."
Athlon Ultra will be targeted at server/workstation market and have faster buses, SMP capabilities, larger L2 cache (up to 8 MB)
Ahtlon Professional will be targeted at performance/commercial desktops and no SMP. These are the Athlon processors that are coming out next week
Athlon Select, the "economical" version, will come in a "different package" than the Athlon Pro and "may not contain as many features."
I guess neither the Athlons that are selling now nor the socketed ones will be SMPable.
Out of topic: In Spain there is a company that produces bleech and related things that, guess that, it's name is "Athlon". My mother has one bottle, so maybe some day you'll see it (when I get a cam).
Have you ever heard of QNX (http://www.qnx.com)?. They make a kernel for real time systems that is so small that it fits in the CPU's first level cache. The idea behind it is that in real time systems you need responses as fast as possible.
I don't like the concept of buying a motherboard which locks you into a specific processor.
Well, then why did you buy a Celeron 433-compatible board if it only works with celerons?
Don't get me wrong. You'll never have a motherboard that works for different Intel processors. Intel also sells chipsets. They just change the CPU's packaging to make you buy a new motherboad and have you pay them one more time for their chipset. It's just a way to exploit their monopoly to grab more money from you.
I don't think this is bad for Apple. If Intel adopted Firewire then PC's could use Cams and other peripherals that only the Mac's use. That would be terrible for Apple because they would loose their market.
Anyone has ever written that famous program that works like this?:
./program < program
./program < something_else
$
Yes.
$
No.
JPEG is lossy because it discards high frequencies. Is it right?
PNG doen't discard data but it uses a logarithmic scale which could make an effect similar to a quantization. Anyone knows if is this right?