The first entering probes were the Soviet probes around 1967 IIRC. I don't know what they detected WRT atmosphere composition, but they were primative by today's standards
I don't know exactly which probes were doing what. The article said they used data from both the Russian and US probes. Even if the data didn't come from the original probes ~30 years is still quite a short amount of time to be making significant changes to the atmosphere of a planet.
Possiblely, but unlikely to be the source of the hydrogen sulphide or carbonyl sulphide that this article is talking about. I say that because the information about the chemical composition of the atmosphere was gathered by the very probes which might have infected it. Hence its unlikely that the probes infected the atmosphere and the infection changed the whole composition instantly. I think it more likely that contamination on the sensors screwed with the results.
If they need the software why can't they fucking well pay for it?;)....Anyone who "needs" hardcore circuit design software should pay for it
I agree, the problem is that as a student, or anyone else trying to learn, or play with some of these pieces of software, it is prohibitivly expensive. As a student I couldn't afford the $20k+ cost for a decent VHDL and synthesis package. As a professional now, I still cannot afford it. The lack of reasonably priced tools is one reason why I develop software rather than hardware.
What a joke. Please show me some decent circuit simulation tools that are free, how about a VHLD compiler, GIS toolset, corporate bookeeping program, CAD/CAM software, a modern decent game selection, or any other piece of 'real' software. Just because you can surf the web, type a paper, read your email, or one of a few other common tasks does not mean that there is always free software that provides the functionality a lot of people need or want.
I did something like this with starcraft. I bought a single copy and two expansion packs. Then made up a new serial number for the second starcraft install and ran both at the same time. I haven't bought warcraft III because i'm afraid of wasting a huge amount of time (I was a warcraft II minor demigod, yes on the ladder, not just against friends) and they didn't include a spawn with it. I don't think its fair I have to buy two copies just to play on my network against a friend. Especially because they have in the past allowed this with the spawn mode.
I was talking strictly about Openfirmware machines. PC's are a diffrent animal. Often times a card will "work" in diffrent platforms if the OS has drivers for it and the BIOS/OF doesn't choke on invalid card firmware (if there even is any card firmware). This is another discussion.
It sounds like you want or expect to find a GUI or some configuration tool for these devices. My point is still that, in most cases, this should be completely unnecessary at the BIOS level. The installed device should just be recognized and allotted the necessary resources to operate if drivers are present in the OS, period. What you describe, in the case of a video card, does happen in the case of Windows, where it defaults to its built-in basic drivers when it cannot locate the card's true drivers. Same should happen in most operating systems (and is so for some).
Ok, then without a configuration tool, GUI or text, how do I select which device I boot from, in a list of CDROM, HD1, HD2, RAID, network, etc? How does my machine know how to access the device to load the OS and its drivers? This is one of the many strong points of OF over the PC BIOS. It works on a PC by having the user run though the adapter configuration screens (firmware physically stored on the PCI card) and turn on the ability to boot from the adapter (its called something like "install bios extensions" with adaptec). Newer PC BIOS's are somewhat aware of 3rd party boot devices and often have a SCSI/Other option which just leaves the int 19h (I think thats the correct interrupt) handler active instead of reaquiring the handler after the PCI firmware probe stage. In OF, the user is simply presented with a list of choices that are bootable. The PC bios 'hack' works because nearly all PC users never boot from a device that isn't on the motherboard and directly supported by the BIOS the machine shipped with. I should point out though that sometimes even motherboard devices arn't supported by the BIOS proper. I have seen dell's and other manufactures fire up what looks like PCI configuration firmware to configure onboard adaptec's, IDE raid controllers etc. This is because they don't want to waste the engineering effort to integrate an off the shelf device, with the off the shelf BIOS they bought.
As far as video controllers, well these often tend to work (especially on the PC) because again nearly all of them provide hardware compatibility to basic VGA text and raster modes. This is why those default "I can't find the driver" modes tend to look like crap, because they are 640x480x16. Sometimes on a PC your lucky enough that the video card has a VESA layer in its firmware in which case you can get 800x600x256 and some slightly better resolutions in windows. In this respect the PC's VESA BIOS extensions are similar to OF, which also provides basic screen drawing and manipulation routines for cards that the OS doesn't have drivers for. But, as I pointed out erlier this doesn't mean that your mac video card is going to work in a sun box. Unless something has changed on the mac, you still have to buy the 'mac' version of the video card. Often the only diffrence between the mac version and the PC version is the firmware on the card. If you have multiple heads, I wouldn't be supprised that a number of video cards are completly cross platform. You just can't use them as the boot display. Once the OS comes up and loads its versions of the drivers it could care less what is in the card ROM's.
Still all this crap wasn't my original point, which is that OF doesn't really provide the cross platform abilities it originally claimed it was going to provide. The firmware drivers simply don't work well enough to stick a mac SCSI card in a sun or aix box (all OF machines) and expect to be able to boot from an attached hard drive much less a tape drive. OS support for a particular adapter is another issue, execpt for my other point which is that it doesn't appear OF compliant OS's are good enough to even use the drivers provided by OF if they are present and the OS doesn't have a native driver. Sticking a PC card in a mac is the same problem except its not suppost to work. You might be able to load a OS native driver after the OS comes up but using the adapter to bootstrap the machine is just about impossible.
Sure, not everything works. Video cards are a good example since they usually require complex drivers. But interface cards such as SCSI work quite well, and there are numerous PCI cards that work in both platforms. I have a Fibre Channel card that is certified to work in both Mac as well as other systems. It's not that PCI devices can't be cross-platform--but most vendors don't write the drivers.
I'm not even talking about OS level drivers for the video cards. What I'm talking about is that they won't function enough to even display the OF splash screens or provide a text terminal. Besides, OS's that boot from OF and understand OF device trees should be able to function on the bare bones services provided by OF in a particular adapter class. In the case of a video card, if the OS cannot find a native driver it should drop back to the OF services to display its GUI. I don't know of a single OS that can accually do this, even though it is part of the OF spec. I question your statement that SCSI cards work well. I suspect that you have only been using mac SCSI cards in mac's. Try booting from some of those cards in a AIX box or a Solaris box. On the other hand I don't doubt that you have a FC card that claims its cross platform. There are cards that do work on more than one platform, they are extreemly rare though. Usually in these cases the code has a lot of checks to work around platform inconsistancies. BTW: I have done OF development work and I know people who make their money by porting OF drivers from one platform to another.
OF has its own set of problems. Most of which are much harder to overcome then the little anoyance the PC BIOS's provides. For example OF is written in an old Forth dialect and doesn't support interrupts. This means that all your nifty new high speed adapters need to run in polled mode. Quite a problem if the adapter hasn't been designed with polled mode in mind (most of them nowdays).
How about the fact that OF is really just a fancy PCI configuration and driver enviroment. This means that half of the work done by a modern bios/firmware (processor config/selftest, ram config/selftest, initial PCI bridge detection/selftest, etc) accually has to be done before the OF enviroment can even be started.
Anyway, OF was a great idea that never really had the kinks worked out of it. Like java, its cross platform promises never took off except in a few cases because the manufactures (Sun, IBM, Apple, others) couldn't get the basic services to behave similarly enough to the spec that OF pci cards just worked between vendors. Try it, buy some sweet fiber channel cards from Sun and try plugging them into your mac. I will bet money they won't all work. Try plugging a mac video card into your AIX box, I'm sure you can't find a single video card that works in both the mac and the aix box.
This is not unusual. The problem is particularly noticable with the upgrade from 100base to 1000base. A little time tuning the network infrastructure (using non standard MTU, etc) can see huge gains in performace.
Most modern PC's won't have any problem handling the bandwith of 1000base. There is plenty of PCI bandwith and memory bandwith for DMA. A tuned IP stack on a reasonable CPU won't have a problem either. Finding an application that can handle it is going to be a little harder.
Cogent. 100Mbits for $1000. Much better deal. Now your 20 users will be _VERY_ happy. Only problem is that you will feel silly with 802.11 tied to a 100mbit line.
Write back caching on the IDE drive solves this problem for writes. Of course with a tranactional system writeback needs to be properly synced. Since IDE doesn't support a fence operation you basically have to turn WB off to guarantee consistancy. For your average workstation or small server user (who doesn't understand all this anyway) its not likely they need that kind of data guarantee, a dropped email isn't the end of the world.
For reads, the outstanding reads don't help much and its more efficient to have the OS do the read ordering because of priority issues. For example a page fault gets moved to the head of the read queue and statified immediatly rather than waiting of existing reads to complete. With the large read caches on the disks grabbing a whole track its not a performace loss to move the head grab a couple sectors and then move the head back to its previous location and read the remaining sectors. The return move will simply be statisfied from the cache.
Actually, the repeal was incomplete. You still cannot do many thing that were once legal. For example distilling your own alcohol is a federal offense. Until recently brewing your own beer was illegal as well. Many of the 'dry counties' around the US were made that way during prohibition and they never repealed the local legislation.
"The real problem is that CISC doesn't really lend its self to low power consumtion - too many transistors."
This is utter BS, go look up how many transitors the original 8086 had, then compare it with the smallest ARM you can find. The problem with low power x86 has to do with trying to achieve both low power and high performace.
Nice how this sparked a discussion about everything but what the article is accually about. So... in usual/. fasion I will post good techical info, lets see if it gets ignored.
CAN (controller area network) bus, seems to be mostly what he was taking about, and the hint that the information is public? Try this site about CAN. It is an ISO standard and is used for everything from automobile's to factory automation. The author of the above site doesn't have the ISO docs but he does have some good pdf's. If your interrested in tools or more info there is of course google google.
That means that they sent a kernel or library developer out to look at the problem. Accually that is the whole point of the 'debug box' the box gets installed and the developer can just debug it from their office over phone or internet. It basically just provides a control point when the machine is stopped at a breakpoint in kernel space. Linux has much the same functionality, only instead of shipping with every install like the kernel debugger in Nt/W2k/Xp does, it must be compiled in. If any of you accually did kernel developement you would know that _Linus_ is wrong, real developers use debuggers instead of just trying to guess what the problem is, fixing something and rebooting to try it out. Linus has even admitted once or twice to using a debugger.
As far as being closed source, sure thats a big problem when it comes to fixing kernel bugs. On the other hand, I have had to had fix a large number of linux kernel bugs. I don't think i've ever found a real kernel bug in NT. Even so, if I had, then I could probably have fixed it given enough time wandering around in the NT kernel debugger with the symbol set shipped in the DDK's. I am perfectly capable of reading and understanding assembly, especially the way the NT kernel is written. Compare a stack dump in linux with one that comes out of NT. The linux one is littered with unreadable symbols, while Nt has these wordy verbose descriptions, IoRegisterDriverReinitialization(), RtlQueryRegistryValues(), IoSetCompletionRoutine(), IoCallDriver() and KeWaitForSingleObject() kind of stuff.
Same here. I work with linux, but my desktop machine at work is a W2k box. I run two heads and a copy of exceed. All my surfing, code editing etc happens on the windows box. The linux boxes just sit there like dumb headless machines. Its just a matter of having my video cards just work. Quicly too since the drivers are all optimized by the vendors. My web surfing looks nice, and doesn't crash, with IE. I don't have to fight with the mouse when I kick the X resolution up to 2kx1600 on two heads (dumb X problem is still around with the accelleration vs speed issues). All the fancy crap KDE/Gnome/etc do doesn't make up for the absolute smooth user interaction I get from windows. I'm not really supprised at the numbers. I only know a couple of people who accually use linux as a desktop machine and they are running proxies which identify their machines as mac's or windows boxes.
That assumes a certain amount of diligence on the part of the programmers.
Your right! Handing return codes from every function can make a big mess, this is why it rarely happens in user space. This also why you should use C++, Java, or any other language with structured exception handling. That way the programmer can be 'sloppy' and still handle error conditions. User space programs that are considered 'critical' do a lot better job. This is a easy attitude. If your application can crash then be sloppy. If your writing a database then you had better handle failures in a graceful way. On the other hand you will discover that kernel programmers (Linux is becoming an exception, the Linux kernel code is getting a lot sloppier) are a _LOT_ better since unhanded failures cause the machine to crash. The kernel code can be cleaner too since a lot of functions are written to guarantee they will succeed. If they cannot then the function will automatically retry or deschedule till it can.
Well, obviously you kill the system maintainer for compiling a kernel that won't fit in memory.:-P
This is amusing:> but fails to note that the running size of the kernel is different from the compiled 'text' size. One of the problems is the required data the kernel has to allocate to manage the running processes. The more processes that are running, the more IO that requires kernel buffering, and the more memory being backed on disk increases the number of kernel pages that are locked down. One of the solutions to this problem is paging the kernel data structures. This brings up a different set of problems which are reasonably difficult to solve. These kind of problems require a unified view of kernel behavior in order to fully understand and design around. Slapping this kind of thing onto an existing code base that wasn't designed to support if from day one bring about a huge validation nightmare. All kinds of strange bugs start to crop up because critical code doesn't get properly locked down. Depending on the kernel it can actually be harder than say.. making a UP kernel run on an SMP.
Linux has the ability to dynamically increase the swap memory using regular files if you install swapd.
This is also great but doesn't help when its not running or the disk gets full. In these cases the kernel better be able to deal with it. Depending on something like that to never fail is a good recipie for an OS that crashes when the page file gets full.
This is absolute BS. Most OS's don't allow overcommit. Linux is one of the few that does. Basically what this means is that Linux allows an application (or the total system workingset) to exceed the amount of ram+pagefile available. This is completely unacceptable. When an application comes up and asks for memory that is being consumed it should have its memory allocation fail. That is why malloc has the option to return NULL. If it returns NULL then the current application has to deal with it. If it cannot continue then it needs to write to a log and exit. Otherwise the kernel is forced to choose (very ungracefully) what process gets killed when it is unable to find space to swap a page out to get the required page into memory. This is VERY BAD!!!. Sometimes the only pages in RAM are critical to the operating system. Say for instance only kernel pages and pages for init are in memory. Now which do you kill? Hmmm pretty bad hu? Its not a solvable problem. This is why it should be avoided. This discussion has come up in the past but the base kernel developers always say something like "well at that point your system is pretty much screwed up already". Duh! but its not a fatal system reboot. The system that isn't overcommited can unwedge itself with proper scheduling and memory management given enough time, Linux has to reboot. Ever see W2k pop up a dialog that says "Running low on memory increasing page file size"? Thats not because the machine is 'low' on memory. In fact the whole working set may still fit in memory. What that means is that an application just asked for more RAM than will fit into the pagefile if the OS needed to swap it completly out.
Part of the problem with the design and redesign of the linux VM is an insistance with sticking with a few core design points that make it 100x harder to write. For instance, virtual memory overcommit spawns a whole bunch of ugly problems that must be solved in order to create a stable and fast system. If the core development team spent some time looking at past OS research then they would completly change their design criteria and a bunch of these problems would go away.
Another perfect example is the OOM killer. If the VMM could properly balance the workload (and it didn't overcommit) then there wouldn't be a need for code to select the 'correct' process to kill. Since the VM cannot balance correctly, the kernel developers spend massive amounts of time trying to write an OOM that functions correctly in the case where the VMM is wedged. This time would be better spent fixing the VMM so it never got into these states.
Little narrow views.. I'm going to complain about Anandtech's treatment of the larger TLB space. I think that the primary reason AMD increased the TLB size is because when running in 64-bit mode the page tables are 4 levels deep. This means that it takes ~2x as long to service a TLB miss. In order to compensate for this extended time there needs to be more or faster TLB's. This is probably the primary reason for the TLB being so high on the list. Increased IPC ha ha ha.. Did anyone accually look at the microarch? Does the 8 extra GP's and resulting lower register spill count mean anything for IPC? Hmmmm. back to computer arch for someone.
I agree. Emacs though, is somewhat frustrating because (the old version I use) it sometimes gets confused when I'm editing code. Then it messes up the syntax highlighting so I have to make it reparse the buffer. This is pretty slow, with anything but small files (less than 250 lines). On my 1.4G machine a big file will lag for a second or two while emacs reparses it. In this respect I like real code editors. I have never seen M$ Visual studio screw up syntax highlighting.
You have got to be joking. The base word.exe is 8.4 megs on my machine. That doesn't include any of the dll's, Active X controls for embedding equations and such or the huge collection of macros.
What I ideally needed was a way to tell GDI that my program would be handling all the updates for a given window, just pass them to me and don't worry about the screen. I suspect it's possible to do this, I bet all these Microsoft products do something similiar, but I was never able to find documentation on it.
That should be as simple as hooking the device context and redirecting it. I saw an example a while back (I think it might have been in the SDK) for hooking notepad and forcing it to draw in a window owned by a diffrent application. I think the problem with VNC is that they want a 'root' window hook that captures a global context for everything and the Windows GDI shortcuts the window parent/child relationship stuff that X does (part of the reason the M$ GDI is so fast) and clips each DC right to the frame buffer. Its just a case of someone thinking like a UNIX geek and trying to write a windows port.
PCanywhere is a good example of the fact that it can be done quickly without to much help from M$. Terminal server was originally written by Citrix. Citrix had M$ help though, I suspect most of the help was in the form of getting multiple User contexts working. In this regard terminal server is much more advanced than VNC on windows. In Unix though VNC is the X server for X clients which makes it behave like Terminal server.
I lost a Seagate 27G 7200rpm IDE drive a couple weeks ago. The power plug got kicked out of my workstation and when it was powered back on the drive refused to spin back up. Seagate replaced it with the 30G drive. Now I'm just waiting for the other drive to fail...
Slashdot Mirror
The first entering probes were the Soviet probes around 1967 IIRC. I don't know what they detected WRT atmosphere composition, but they were primative by today's standards
I don't know exactly which probes were doing what. The article said they used data from both the Russian and US probes. Even if the data didn't come from the original probes ~30 years is still quite a short amount of time to be making significant changes to the atmosphere of a planet.
Possiblely, but unlikely to be the source of the hydrogen sulphide or carbonyl sulphide that this article is talking about. I say that because the information about the chemical composition of the atmosphere was gathered by the very probes which might have infected it. Hence its unlikely that the probes infected the atmosphere and the infection changed the whole composition instantly. I think it more likely that contamination on the sensors screwed with the results.
I agree, the problem is that as a student, or anyone else trying to learn, or play with some of these pieces of software, it is prohibitivly expensive. As a student I couldn't afford the $20k+ cost for a decent VHDL and synthesis package. As a professional now, I still cannot afford it. The lack of reasonably priced tools is one reason why I develop software rather than hardware.
What a joke. Please show me some decent circuit simulation tools that are free, how about a VHLD compiler, GIS toolset, corporate bookeeping program, CAD/CAM software, a modern decent game selection, or any other piece of 'real' software. Just because you can surf the web, type a paper, read your email, or one of a few other common tasks does not mean that there is always free software that provides the functionality a lot of people need or want.
I did something like this with starcraft. I bought a single copy and two expansion packs. Then made up a new serial number for the second starcraft install and ran both at the same time. I haven't bought warcraft III because i'm afraid of wasting a huge amount of time (I was a warcraft II minor demigod, yes on the ladder, not just against friends) and they didn't include a spawn with it. I don't think its fair I have to buy two copies just to play on my network against a friend. Especially because they have in the past allowed this with the spawn mode.
I was talking strictly about Openfirmware machines. PC's are a diffrent animal. Often times a card will "work" in diffrent platforms if the OS has drivers for it and the BIOS/OF doesn't choke on invalid card firmware (if there even is any card firmware). This is another discussion.
It sounds like you want or expect to find a GUI or some configuration tool for these devices. My point is still that, in most cases, this should be completely unnecessary at the BIOS level. The installed device should just be recognized and allotted the necessary resources to operate if drivers are present in the OS, period. What you describe, in the case of a video card, does happen in the case of Windows, where it defaults to its built-in basic drivers when it cannot locate the card's true drivers. Same should happen in most operating systems (and is so for some).
Ok, then without a configuration tool, GUI or text, how do I select which device I boot from, in a list of CDROM, HD1, HD2, RAID, network, etc? How does my machine know how to access the device to load the OS and its drivers? This is one of the many strong points of OF over the PC BIOS. It works on a PC by having the user run though the adapter configuration screens (firmware physically stored on the PCI card) and turn on the ability to boot from the adapter (its called something like "install bios extensions" with adaptec). Newer PC BIOS's are somewhat aware of 3rd party boot devices and often have a SCSI/Other option which just leaves the int 19h (I think thats the correct interrupt) handler active instead of reaquiring the handler after the PCI firmware probe stage. In OF, the user is simply presented with a list of choices that are bootable. The PC bios 'hack' works because nearly all PC users never boot from a device that isn't on the motherboard and directly supported by the BIOS the machine shipped with. I should point out though that sometimes even motherboard devices arn't supported by the BIOS proper. I have seen dell's and other manufactures fire up what looks like PCI configuration firmware to configure onboard adaptec's, IDE raid controllers etc. This is because they don't want to waste the engineering effort to integrate an off the shelf device, with the off the shelf BIOS they bought.
As far as video controllers, well these often tend to work (especially on the PC) because again nearly all of them provide hardware compatibility to basic VGA text and raster modes. This is why those default "I can't find the driver" modes tend to look like crap, because they are 640x480x16. Sometimes on a PC your lucky enough that the video card has a VESA layer in its firmware in which case you can get 800x600x256 and some slightly better resolutions in windows. In this respect the PC's VESA BIOS extensions are similar to OF, which also provides basic screen drawing and manipulation routines for cards that the OS doesn't have drivers for. But, as I pointed out erlier this doesn't mean that your mac video card is going to work in a sun box. Unless something has changed on the mac, you still have to buy the 'mac' version of the video card. Often the only diffrence between the mac version and the PC version is the firmware on the card. If you have multiple heads, I wouldn't be supprised that a number of video cards are completly cross platform. You just can't use them as the boot display. Once the OS comes up and loads its versions of the drivers it could care less what is in the card ROM's.
Still all this crap wasn't my original point, which is that OF doesn't really provide the cross platform abilities it originally claimed it was going to provide. The firmware drivers simply don't work well enough to stick a mac SCSI card in a sun or aix box (all OF machines) and expect to be able to boot from an attached hard drive much less a tape drive. OS support for a particular adapter is another issue, execpt for my other point which is that it doesn't appear OF compliant OS's are good enough to even use the drivers provided by OF if they are present and the OS doesn't have a native driver. Sticking a PC card in a mac is the same problem except its not suppost to work. You might be able to load a OS native driver after the OS comes up but using the adapter to bootstrap the machine is just about impossible.
I'm not even talking about OS level drivers for the video cards. What I'm talking about is that they won't function enough to even display the OF splash screens or provide a text terminal. Besides, OS's that boot from OF and understand OF device trees should be able to function on the bare bones services provided by OF in a particular adapter class. In the case of a video card, if the OS cannot find a native driver it should drop back to the OF services to display its GUI. I don't know of a single OS that can accually do this, even though it is part of the OF spec. I question your statement that SCSI cards work well. I suspect that you have only been using mac SCSI cards in mac's. Try booting from some of those cards in a AIX box or a Solaris box. On the other hand I don't doubt that you have a FC card that claims its cross platform. There are cards that do work on more than one platform, they are extreemly rare though. Usually in these cases the code has a lot of checks to work around platform inconsistancies. BTW: I have done OF development work and I know people who make their money by porting OF drivers from one platform to another.
OF has its own set of problems. Most of which are much harder to overcome then the little anoyance the PC BIOS's provides. For example OF is written in an old Forth dialect and doesn't support interrupts. This means that all your nifty new high speed adapters need to run in polled mode. Quite a problem if the adapter hasn't been designed with polled mode in mind (most of them nowdays).
How about the fact that OF is really just a fancy PCI configuration and driver enviroment. This means that half of the work done by a modern bios/firmware (processor config/selftest, ram config/selftest, initial PCI bridge detection/selftest, etc) accually has to be done before the OF enviroment can even be started.
Anyway, OF was a great idea that never really had the kinks worked out of it. Like java, its cross platform promises never took off except in a few cases because the manufactures (Sun, IBM, Apple, others) couldn't get the basic services to behave similarly enough to the spec that OF pci cards just worked between vendors. Try it, buy some sweet fiber channel cards from Sun and try plugging them into your mac. I will bet money they won't all work. Try plugging a mac video card into your AIX box, I'm sure you can't find a single video card that works in both the mac and the aix box.
This is not unusual. The problem is particularly noticable with the upgrade from 100base to 1000base. A little time tuning the network infrastructure (using non standard MTU, etc) can see huge gains in performace.
Most modern PC's won't have any problem handling the bandwith of 1000base. There is plenty of PCI bandwith and memory bandwith for DMA. A tuned IP stack on a reasonable CPU won't have a problem either. Finding an application that can handle it is going to be a little harder.
If I lived in one of the cities serviced by Cogent. I would already be doing exactly that.
20 users on a T1 will be slow. Try this though.
Cogent. 100Mbits for $1000. Much better deal. Now your 20 users will be _VERY_ happy. Only problem is that you will feel silly with 802.11 tied to a 100mbit line.
Write back caching on the IDE drive solves this problem for writes. Of course with a tranactional system writeback needs to be properly synced. Since IDE doesn't support a fence operation you basically have to turn WB off to guarantee consistancy. For your average workstation or small server user (who doesn't understand all this anyway) its not likely they need that kind of data guarantee, a dropped email isn't the end of the world.
For reads, the outstanding reads don't help much and its more efficient to have the OS do the read ordering because of priority issues. For example a page fault gets moved to the head of the read queue and statified immediatly rather than waiting of existing reads to complete. With the large read caches on the disks grabbing a whole track its not a performace loss to move the head grab a couple sectors and then move the head back to its previous location and read the remaining sectors. The return move will simply be statisfied from the cache.
Actually, the repeal was incomplete. You still cannot do many thing that were once legal. For example distilling your own alcohol is a federal
offense. Until recently brewing your own beer was illegal as well. Many of the 'dry counties' around the US were made that way during
prohibition and they never repealed the local legislation.
This is utter BS, go look up how many transitors the original 8086 had, then compare it with the smallest ARM you can find. The problem with low power x86 has to do with trying to achieve both low power and high performace.
Nice how this sparked a discussion about everything but what the article is accually about. So... in usual /. fasion I will post good techical info, lets see if it gets ignored.
CAN (controller area network) bus, seems to be mostly what he was taking about, and the hint that the information is public? Try this site about CAN. It is an ISO standard and is used for everything from automobile's to factory automation. The author of the above site doesn't have the ISO docs but he does have some good pdf's. If your interrested in tools or more info there is of course google google.
That means that they sent a kernel or library developer out to look at the problem. Accually that is the whole point of the 'debug box' the box gets installed and the developer can just debug it from their office over phone or internet. It basically just provides a control point when the machine is stopped at a breakpoint in kernel space. Linux has much the same functionality, only instead of shipping with every install like the kernel debugger in Nt/W2k/Xp does, it must be compiled in. If any of you accually did kernel developement you would know that _Linus_ is wrong, real developers use debuggers instead of just trying to guess what the problem is, fixing something and rebooting to try it out. Linus has even admitted once or twice to using a debugger.
As far as being closed source, sure thats a big problem when it comes to fixing kernel bugs. On the other hand, I have had to had fix a large number of linux kernel bugs. I don't think i've ever found a real kernel bug in NT. Even so, if I had, then I could probably have fixed it given enough time wandering around in the NT kernel debugger with the symbol set shipped in the DDK's. I am perfectly capable of reading and understanding assembly, especially the way the NT kernel is written. Compare a stack dump in linux with one that comes out of NT. The linux one is littered with unreadable symbols, while Nt has these wordy verbose descriptions, IoRegisterDriverReinitialization(), RtlQueryRegistryValues(), IoSetCompletionRoutine(), IoCallDriver() and KeWaitForSingleObject() kind of stuff.
Same here. I work with linux, but my desktop machine at work is a W2k box. I run two heads and a copy of exceed. All my surfing, code editing etc happens on the windows box. The linux boxes just sit there like dumb headless machines. Its just a matter of having my video cards just work. Quicly too since the drivers are all optimized by the vendors. My web surfing looks nice, and doesn't crash, with IE. I don't have to fight with the mouse when I kick the X resolution up to 2kx1600 on two heads (dumb X problem is still around with the accelleration vs speed issues). All the fancy crap KDE/Gnome/etc do doesn't make up for the absolute smooth user interaction I get from windows. I'm not really supprised at the numbers. I only know a couple of people who accually use linux as a desktop machine and they are running proxies which identify their machines as mac's or windows boxes.
Your right! Handing return codes from every function can make a big mess, this is why it rarely happens in user space. This also why you should use C++, Java, or any other language with structured exception handling. That way the programmer can be 'sloppy' and still handle error conditions. User space programs that are considered 'critical' do a lot better job. This is a easy attitude. If your application can crash then be sloppy. If your writing a database then you had better handle failures in a graceful way. On the other hand you will discover that kernel programmers (Linux is becoming an exception, the Linux kernel code is getting a lot sloppier) are a _LOT_ better since unhanded failures cause the machine to crash. The kernel code can be cleaner too since a lot of functions are written to guarantee they will succeed. If they cannot then the function will automatically retry or deschedule till it can.
Well, obviously you kill the system maintainer for compiling a kernel that won't fit in memory.
This is amusing :> but fails to note that the running size of the kernel is different from the compiled 'text' size. One of the problems is the required data the kernel has to allocate to manage the running processes. The more processes that are running, the more IO that requires kernel buffering, and the more memory being backed on disk increases the number of kernel pages that are locked down. One of the solutions to this problem is paging the kernel data structures. This brings up a different set of problems which are reasonably difficult to solve. These kind of problems require a unified view of kernel behavior in order to fully understand and design around. Slapping this kind of thing onto an existing code base that wasn't designed to support if from day one bring about a huge validation nightmare. All kinds of strange bugs start to crop up because critical code doesn't get properly locked down. Depending on the kernel it can actually be harder than say.. making a UP kernel run on an SMP.
Linux has the ability to dynamically increase the swap memory using regular files if you install swapd.
This is also great but doesn't help when its not running or the disk gets full. In these cases the kernel better be able to deal with it. Depending on something like that to never fail is a good recipie for an OS that crashes when the page file gets full.
You can't avoid overcommit in a usable system.
This is absolute BS. Most OS's don't allow overcommit. Linux is one of the few that does. Basically what this means is that Linux allows an application (or the total system workingset) to exceed the amount of ram+pagefile available. This is completely unacceptable. When an application comes up and asks for memory that is being consumed it should have its memory allocation fail. That is why malloc has the option to return NULL. If it returns NULL then the current application has to deal with it. If it cannot continue then it needs to write to a log and exit. Otherwise the kernel is forced to choose (very ungracefully) what process gets killed when it is unable to find space to swap a page out to get the required page into memory. This is VERY BAD!!!. Sometimes the only pages in RAM are critical to the operating system. Say for instance only kernel pages and pages for init are in memory. Now which do you kill? Hmmm pretty bad hu? Its not a solvable problem. This is why it should be avoided. This discussion has come up in the past but the base kernel developers always say something like "well at that point your system is pretty much screwed up already". Duh! but its not a fatal system reboot. The system that isn't overcommited can unwedge itself with proper scheduling and memory management given enough time, Linux has to reboot. Ever see W2k pop up a dialog that says "Running low on memory increasing page file size"? Thats not because the machine is 'low' on memory. In fact the whole working set may still fit in memory. What that means is that an application just asked for more RAM than will fit into the pagefile if the OS needed to swap it completly out.
Part of the problem with the design and redesign of the linux VM is an insistance with sticking with a few core design points that make it 100x harder to write. For instance, virtual memory overcommit spawns a whole bunch of ugly problems that must be solved in order to create a stable and fast system. If the core development team spent some time looking at past OS research then they would completly change their design criteria and a bunch of these problems would go away.
Another perfect example is the OOM killer. If the VMM could properly balance the workload (and it didn't overcommit) then there wouldn't be a need for code to select the 'correct' process to kill. Since the VM cannot balance correctly, the kernel developers spend massive amounts of time trying to write an OOM that functions correctly in the case where the VMM is wedged. This time would be better spent fixing the VMM so it never got into these states.
Little narrow views.. I'm going to complain about Anandtech's treatment of the larger TLB space. I think that the primary reason AMD increased the TLB size is because when running in 64-bit mode the page tables are 4 levels deep. This means that it takes ~2x as long to service a TLB miss. In order to compensate for this extended time there needs to be more or faster TLB's. This is probably the primary reason for the TLB being so high on the list. Increased IPC ha ha ha.. Did anyone accually look at the microarch? Does the 8 extra GP's and resulting lower register spill count mean anything for IPC? Hmmmm. back to computer arch for someone.
I agree. Emacs though, is somewhat frustrating because (the old version I use) it sometimes gets confused when I'm editing code. Then it messes up the syntax highlighting so I have to make it reparse the buffer. This is pretty slow, with anything but small files (less than 250 lines). On my 1.4G machine a big file will lag for a second or two while emacs reparses it. In this respect I like real code editors. I have never seen M$ Visual studio screw up syntax highlighting.
You have got to be joking. The base word .exe is 8.4 megs on my machine. That doesn't include any of the dll's, Active X controls for embedding equations and such or the huge collection of macros.
That should be as simple as hooking the device context and redirecting it. I saw an example a while back (I think it might have been in the SDK) for hooking notepad and forcing it to draw in a window owned by a diffrent application. I think the problem with VNC is that they want a 'root' window hook that captures a global context for everything and the Windows GDI shortcuts the window parent/child relationship stuff that X does (part of the reason the M$ GDI is so fast) and clips each DC right to the frame buffer. Its just a case of someone thinking like a UNIX geek and trying to write a windows port.
PCanywhere is a good example of the fact that it can be done quickly without to much help from M$. Terminal server was originally written by Citrix. Citrix had M$ help though, I suspect most of the help was in the form of getting multiple User contexts working. In this regard terminal server is much more advanced than VNC on windows. In Unix though VNC is the X server for X clients which makes it behave like Terminal server.
I lost a Seagate 27G 7200rpm IDE drive a couple weeks ago. The power plug got kicked out of my workstation and when it was powered back on the drive refused to spin back up. Seagate replaced it with the 30G drive. Now I'm just waiting for the other drive to fail...