- no real need for update. S939 and S940 were quite adequate.
- no real performance gain with DDR-2. A simple CPU socket change can't help here.
- CPU core itself hasn't chhanged much. Latest dual core model, like 285 are not that differrent from plain old 240. It has two cores, but cores per se aren't much faster or lower power than old ones...
- People have realised that all technological breakthroughs are aimed at AMD's gain, not customer's benefit. Take HT channels, for example. AMD has been showing them as the next technowonder that will change computing world and bring us cheap, high performance multiCPU systems. In reality, on 2-CPU boards it can hardly show any advantage and on 4 and 8-way systems where it does mean something prices are so high that they practically don't exist for mere mortals.
You are wrong,at least if you use efficient switching power supply.
Charging 1.2V/2500mAh cell in 1 minute would theoretically take current of 60x2.5A=150A, but at some 1.5V that would mean power of cca 230W. At 230V of mains voltage your current draw would be cca 1A. High output current doesn't neccesarily mean high input current.
If things were working as you say, at some 100A feeding CPU in your machine, your electricity bills would be _VERY_ interesting...
Errm. My bad. Linux is under GPL, so similar restrictions apply to linked modules also.
FWIW, Linus says that modules, based on work, DERIVED from kernel have to be under GPL and that thus this limitation doesn't apply for non-derived modules.
What is criterion for "derived" here ? Well, that seems to be gray area, but he says:
/SNIP/
There's a clarification that user-space programs that use the standard system call interfaces aren't considered derived works, but even that isn't an exception" - it's just a statement of a border of what is clearly considered a "derived work". User programs are _clearly_ not derived works of the kernel, and as such whatever the kernel license is just doesn't matter.
And in fact, when it comes to modules, the GPL issue is exactly the same. The kernel _is_ GPL. No ifs, buts and maybe's about it. As a result, anything that is a derived work has to be GPL'd. It's that simple.
Now, the "derived work" issue in copyright law is the only thing that leads to any gray areas. There are areas that are not gray at all: user space is clearly not a derived work, while kernel patches clearly _are_ derived works.
But one gray area in particular is something like a driver that was originally written for another operating system (ie clearly not a derived work of Linux in origin). At exactly what point does it become a derived work of the kernel (and thus fall under the GPL)?
THAT is a gray area, and _that_ is the area where I personally believe that some modules may be considered to not be derived works simply because they weren't designed for Linux and don't depend on any special Linux behaviour.
Basically:
- anything that was written with Linux in mind (whether it then _also_ works on other operating systems or not) is clearly partially a derived work. - anything that has knowledge of and plays with fundamental internal Linux behaviour is clearly a derived work. If you need to muck around with core code, you're derived, no question about it.
Historically, there's been things like the original Andrew filesystem module: a standard filesystem that really wasn't written for Linux in the first place, and just implements a UNIX filesystem. Is that derived just because it got ported to Linux that had a reasonably similar VFS interface to what other UNIXes did? Personally, I didn't feel that I could make that judgment call. Maybe it was, maybe it wasn't, but it clearly is a gray area.
Personally, I think that case wasn't a derived work, and I was willing to tell the AFS guys so.
Does that mean that any kernel module is automatically not a derived work? HELL NO! It has nothing to do with modules per se, except that non-modules clearly are derived works (if they are so central to the kenrel that you can't load them as a module, they are clearly derived works just by virtue of being very intimate - and because the GPL expressly mentions linking).
So being a module is not a sign of not being a derived work. It's just one sign that _maybe_ it might have other arguments for why it isn't derived.
Linus
/SNIP from next post/...
That has changed, and the kernel module interfaces we have today are MUCH more extensive than they were back in '95 or so. These days modules are used for pretty much everything, including stuff that is very much "internal kernel" stuff and as a result the kind of historic "implied barrier" part of modules really has weakened, and as a result there is not a very strong argument for being an independent work from just the fact that you're a module.
Similarly, historically there was a much stronger argument for things like AFS and some of the binary drivers (long forgotten now) for having been developed totally independently of Linux: they literally were developed before Linux even existed, by people who had zero knowledge of Linux. That tends to strengthen
Why does it matter if it violates GPL ?
AFAIK kernel is LGPL and allows linking in closed source drivers.
What are you trying to say- that "emerge nvidia-kernel" on Gentoo is illegal ?
I would personally trust my life to INTEGRITY-178B [mil-embedded.com]from Green Hills -- which does have a microkernel architecture, before I would trust my life to a huge monolithic blob of code such as the Linux kernel.
But can that "Integrity" play DVD while transfering data intensively through several protocols at once (e.g. SMB, NFS etc), is it able to run F.E.A.R or Quake at decent framerate and how much does it cost ?
You are comparing apples to oranges. Flight approved gear has to meet very different requirements and raw CPU horsepower usually isn't one of them. Sure, they might have to have deterministic response time, but OTOH they do run in a very controlled environment. You probably can't just log in from pilot's seat and install fresh DivX player on it...
I'd LOVE to se that "Integrity" of yours running Gentoo and a pilot with the balls of steel, doing "emerge --sync ; emerge -uD world" before each flight.
I don't see why all the fuss is about. As OP said, about only thing that this might be good for, is ECC.
On the minus side, there will be more wasted bits as a result of having integral number of sectors per track, so on average there will be 1/2 sector=2Kbytes wasted instead of previous 256 bytes/track. But OTOH, smaller number of sectors mean less wasted bits for sector headers and tails...
Everything else is just about the same. Modern PATA/SATA disk transfer data by multisector transfers, so it's about the same if you transfer 16x512bytes or 2x4096 bytes per request, all buffering on disk etc being the same.
Some visible difference is to be expected, but nothing to get excited for...
Mine works on 300V DC (Europe, mains voltage 230V DC) without a problem.
Even more, if one has a bit newer unit with cos phi correction, one can take correction subunit out, since it's not needed for DC and get better efficiency. Only snag is that at least my PSU unit wants 400V DC after power correction unit amputation, since this is what it had been output at that point by old circuitry...
While Adobe has been edging toward Linux for some time now, it also took its own sweet time in bringing the latest version of Adobe Reader, aka Acrobat, to Linux. After all, Adobe didn't even release Version 6 for Linux.
How come then, that I have Acrobat 7.0 emerged on my Gentoo for some time now ?
So what ? If you use your algorithm carefully and with long key, this should be so rare that cards would have to be replaced due to wear&tear if not something else, so this shouldn't be a problem.
But Iran is the one that is calm.
Every time they agreed and complied with foreign demands, new demands were made.
Why are they effectively forbidden from using the nuclear energy ? Because they MIGHT bomb us ?
What about just anyone else ? North Korea for example ?
Or even US ? After all, US president will have/if he doesn't already/ the power to use nuclear force without consulting anyone.
So, why again are the Iranians bad guys ?
Re:Atari's Jackintosh was a weak copy
on
Happy Birthday, Amiga
·
· Score: 2, Informative
While it is true that TOS was much simpler than AMigaDOS, I have to point several inacuracies/ommisions:
- Atari's RF shield was NOT soldered on. At least not in typical case. I must have serviced/expanded at least 500+ various Atari ST's (ST,STM, STFM, Mega ST etc) and I have NEVER seen soldered-on RF shield on Atari.
They had hinges in some 10 places ( which needed to be straightened up before separating halves of the shield) ant they were screwed-on to the bottom plastic part of the computer. I used to be able to take Atari apart in less than five minutes without special effort.
-Although with theoretically weaker graphics, Atari ST was much more suitable for serious CAD or DTP work, since it had really nice monochrome monitor- SM-124. With it relatively long persistance phosphor and solid 72 Hz refresh rate, it was quite suitable for long work hours.
All that Amiga was capable of (at least with off-the shelf-equipment) was 50 Hz on low-persistence colour monitor (or 60 Hz in the US, with lower resolution) and if one wanted to use hers much praised high resolution modes, he had to risk epileptic attack with 25/30 Hz refresh rate ( two interlaced halves at 50/60 Hz), when picture was blinking like hell.
Besides, all that multitasking and nice graphics didn't come without the price. Atari's 68000 ran on full 8 MHz and in practice it was measurably faster than Amiga.
Also TOS was not a problem for ST, since on could burn alternative TOS in eproms and stick them in the machine and thet was before TOS-2.0.7, which came in with IDE disk support...
I liked Atari much better than Amiga for its simplicity and focus on the goal- to have as fast machine as possible per given budget and graphics useable for office work.
Unexpanded QL was totaly uninterested for anything, happening over 256Kb (and so it couldn't have had I/O at 768 Kb). If nothing else claimed adresses over 256 Kb, its adress space would just alias on the bound of 256K-ie. first kilobyte would be seen also as 257-th, 513-th etc.
IIRC this area (768K-1024K) was meant to be used for expansion cards, but this was not forced.
After power-up, system would just scan that area for magic words at 16 K boundaries and if it did not found anything there, it would just leave it to RAM test-check routines to determine the top of RAM. At least my Minerva ROM (ingenius replacement from some enthusiast) did this.
My QL had its 2,5Mb of ram as one address area, without holes and everything worked perfectly.
I had on it floppy interface for 720/144 Mb disks ( but never made driver for 1,44 Mb floppies, just used official 720 Kb ROM) and Nasta's (QBIde) IDE driver, so my QL had modern IDE drive !
Later I have soldered on top of that Atari/Amiga mouse interface, some I/O lines etc- everything, except IDE used I/O in th 96Kb-128Kb region and IDE used I/O in its own 16Kb chunk, IIRC it was 64Kb-80Kb on my machine...
1. Sinclair's QL had an I/O area between 96th and 128th Kb.
2. WIth QL, adressing is a matter of agreement.
External periphery was meant to monitor CPU activity and at the relevant moment signal to the rest of the machine "this cycle is for me.Everyone else, please ignore it."
IIRC, this mechanism works for adresses that are initially not occupied (ie over 256Kb on standard QL).
3. QL's were often expanded over 1Mb. It is true that ordinary 68008 has 20 adress pins and 1 Mb address range, but 68008FN ( in PLCC package) has 22 adress pins and 4Mb address range.
This is BTW how I expanded my machine to 2.5 Mb.
If I cared to fit in 68EC000, I could go up to 15* Mb...
4. There were quite some cards ( ie. Gold Card with 68000 on 32 Mhz and some models with up to 68040) and I have seen the QL successor in the form of the AT motherboard with 68040, ISA slots, standard DRAM 72-pin SIMMs etc.
QL wasn't a bad machine. Some hardware parts were pretty crappy, but hardware concepts were dead simple and quite easily extensible.
Also, it had colour graphic, multiutasking OS etc...
Although these things were cool three years ago, many things have changed since then.
If you absolutely need every cubic cm of space, they might be worth a look. Otherwise, forget it.
They are quite expensive, they have no drivers or some lousy drivers and their speed sucks.
If you can, use flexATX board with some Duron or Athlon or Pentium M or something similar and downlock it to get lower power drain.
It will have comparable price but still be much faster than mini-ITX.
VIA is charging the hell out of their customers.
If I could get some small board with a decent MIPS core and graphics and run conventional Linux (with modern and bug free drivers), I would forget about EPIA in a nanosecond.
Some 70% machines in use today have good old PATA discs. How do you think that Linux works on them ?
Besides, all of my external PATA cards are from Promise and I can assure you that they work with vanilla kernel 2.6. There IS module for Promise cards and it CAN be compiled in kernel !
This is not necessarily true. The difference in speed you'll get with a properly arranged MMU will be negligable.
Only if you have MMU onboard, but don't use it. Otherwise, changing from user adress space to kernel's and back should cost you something in terms of cpent CPU cycles and cache trashing.
If all processes share same address space, many things in kernel become faster and easier.
AMD is patenting this as a way of *getting around* of SOI disadvantages. SOI means silicon on insulator , which is in this case SiO2, which is also excellent thermal (not only electrical) insulator. AMD says that SiO2 conducts heat at least hundred times less than silicon.
What they are saying is that transistors on SOI might behave better, but they are certainly running hotter than their classic countepairs, since layer of SiO2 stands between them and the cooling system.
So AMD is proposing several schemes of embedding TEC device into the insulating layer in the silicon. This layer would:
1. Decrease overall thermal resisstance of the cooling path
2. When powered on, offer bigger thermal diferential, since it could cool embedded side of the TEC significantly below the cooler temperature.
It is unclear if they intend to use this on the whole chip, or just the especially hot areas...
Slashdot Mirror
- no real need for update. S939 and S940 were quite adequate.
- no real performance gain with DDR-2. A simple CPU socket change can't help here.
- CPU core itself hasn't chhanged much. Latest dual core model, like 285 are not that differrent from plain old 240. It has two cores, but cores per se aren't much faster or lower power than old ones...
- People have realised that all technological breakthroughs are aimed at AMD's gain, not customer's benefit. Take HT channels, for example. AMD has been showing them as the next technowonder that will change computing world and bring us cheap, high performance multiCPU systems. In reality, on 2-CPU boards it can hardly show any advantage and on 4 and 8-way systems where it does mean something prices are so high that they practically don't exist for mere mortals.
These things are cruising through the Bagdad for a few years now...
You are 3 decimal places off.
At 500 Ghz 1/4 wavelength is more like 150 micrometers or 0.15mm, assuming relative permeability and dielectricity =1...
You are wrong,at least if you use efficient switching power supply.
Charging 1.2V/2500mAh cell in 1 minute would theoretically take current of 60x2.5A=150A, but at some 1.5V that would mean power of cca 230W. At 230V of mains voltage your current draw would be cca 1A. High output current doesn't neccesarily mean high input current.
If things were working as you say, at some 100A feeding CPU in your machine, your electricity bills would be _VERY_ interesting...
FWIW, Linus says that modules, based on work, DERIVED from kernel have to be under GPL and that thus this limitation doesn't apply for non-derived modules.
What is criterion for "derived" here ? Well, that seems to be gray area, but he says:
Why does it matter if it violates GPL ? AFAIK kernel is LGPL and allows linking in closed source drivers. What are you trying to say- that "emerge nvidia-kernel" on Gentoo is illegal ?
I would personally trust my life to INTEGRITY-178B [mil-embedded.com]from Green Hills -- which does have a microkernel architecture, before I would trust my life to a huge monolithic blob of code such as the Linux kernel.
But can that "Integrity" play DVD while transfering data intensively through several protocols at once (e.g. SMB, NFS etc), is it able to run F.E.A.R or Quake at decent framerate and how much does it cost ?
You are comparing apples to oranges. Flight approved gear has to meet very different requirements and raw CPU horsepower usually isn't one of them.
Sure, they might have to have deterministic response time, but OTOH they do run in a very controlled environment. You probably can't just log in from pilot's seat and install fresh DivX player on it...
I'd LOVE to se that "Integrity" of yours running Gentoo and a pilot with the balls of steel, doing "emerge --sync ; emerge -uD world" before each flight.
I don't see why all the fuss is about. As OP said, about only thing that this might be good for, is ECC.
On the minus side, there will be more wasted bits as a result of having integral number of sectors per track, so on average there will be 1/2 sector=2Kbytes wasted instead of previous 256 bytes/track. But OTOH, smaller number of sectors mean less wasted bits for sector headers and tails...
Everything else is just about the same. Modern PATA/SATA disk transfer data by multisector transfers, so it's about the same if you transfer 16x512bytes or 2x4096 bytes per request, all buffering on disk etc being the same.
Some visible difference is to be expected, but nothing to get excited for...
PSU init in PC should work on DC as it is.
Mine works on 300V DC (Europe, mains voltage 230V DC) without a problem.
Even more, if one has a bit newer unit with cos phi correction, one can take correction subunit out, since it's not needed for DC and get better efficiency. Only snag is that at least my PSU unit wants 400V DC after power correction unit amputation, since this is what it had been output at that point by old circuitry...
How come then, that I have Acrobat 7.0 emerged on my Gentoo for some time now ?
So what ? If you use your algorithm carefully and with long key, this should be so rare that cards would have to be replaced due to wear&tear if not something else, so this shouldn't be a problem.
But Iran is the one that is calm. Every time they agreed and complied with foreign demands, new demands were made. Why are they effectively forbidden from using the nuclear energy ? Because they MIGHT bomb us ? What about just anyone else ? North Korea for example ? Or even US ? After all, US president will have /if he doesn't already/ the power to use nuclear force without consulting anyone.
So, why again are the Iranians bad guys ?
Same here... :o/
While it is true that TOS was much simpler than AMigaDOS, I have to point several inacuracies/ommisions:
- Atari's RF shield was NOT soldered on. At least not in typical case. I must have serviced/expanded at least 500+ various Atari ST's (ST,STM, STFM, Mega ST etc) and I have NEVER seen soldered-on RF shield on Atari.
They had hinges in some 10 places ( which needed to be straightened up before separating halves of the shield) ant they were screwed-on to the bottom plastic part of the computer.
I used to be able to take Atari apart in less than five minutes without special effort.
-Although with theoretically weaker graphics, Atari ST was much more suitable for serious CAD or DTP work, since it had really nice monochrome monitor- SM-124. With it relatively long persistance phosphor and solid 72 Hz refresh rate, it was quite suitable for long work hours.
All that Amiga was capable of (at least with off-the shelf-equipment) was 50 Hz on low-persistence colour monitor (or 60 Hz in the US, with lower resolution) and if one wanted to use hers much praised high resolution modes, he had to risk epileptic attack with 25/30 Hz refresh rate ( two interlaced halves at 50/60 Hz), when picture was blinking like hell.
Besides, all that multitasking and nice graphics didn't come without the price. Atari's 68000 ran on full 8 MHz and in practice it was measurably faster than Amiga.
Also TOS was not a problem for ST, since on could burn alternative TOS in eproms and stick them in the machine and thet was before TOS-2.0.7, which came in with IDE disk support...
I liked Atari much better than Amiga for its simplicity and focus on the goal- to have as fast machine as possible per given budget and graphics useable for office work.
Unexpanded QL was totaly uninterested for anything, happening over 256Kb (and so it couldn't have had I/O at 768 Kb). If nothing else claimed adresses over 256 Kb, its adress space would just alias on the bound of 256K-ie. first kilobyte would be seen also as 257-th, 513-th etc.
IIRC this area (768K-1024K) was meant to be used for expansion cards, but this was not forced.
After power-up, system would just scan that area for magic words at 16 K boundaries and if it did not found anything there, it would just leave it to RAM test-check routines to determine the top of RAM. At least my Minerva ROM (ingenius replacement from some enthusiast) did this.
My QL had its 2,5Mb of ram as one address area, without holes and everything worked perfectly. I had on it floppy interface for 720/144 Mb disks ( but never made driver for 1,44 Mb floppies, just used official 720 Kb ROM) and Nasta's (QBIde) IDE driver, so my QL had modern IDE drive !
Later I have soldered on top of that Atari/Amiga mouse interface, some I/O lines etc- everything, except IDE used I/O in th 96Kb-128Kb region and IDE used I/O in its own 16Kb chunk, IIRC it was 64Kb-80Kb on my machine...
You are wrong on a couple of points:
1. Sinclair's QL had an I/O area between 96th and 128th Kb.
2. WIth QL, adressing is a matter of agreement. External periphery was meant to monitor CPU activity and at the relevant moment signal to the rest of the machine "this cycle is for me.Everyone else, please ignore it."
IIRC, this mechanism works for adresses that are initially not occupied (ie over 256Kb on standard QL).
3. QL's were often expanded over 1Mb. It is true that ordinary 68008 has 20 adress pins and 1 Mb address range, but 68008FN ( in PLCC package) has 22 adress pins and 4Mb address range. This is BTW how I expanded my machine to 2.5 Mb. If I cared to fit in 68EC000, I could go up to 15* Mb...
4. There were quite some cards ( ie. Gold Card with 68000 on 32 Mhz and some models with up to 68040) and I have seen the QL successor in the form of the AT motherboard with 68040, ISA slots, standard DRAM 72-pin SIMMs etc.
QL wasn't a bad machine. Some hardware parts were pretty crappy, but hardware concepts were dead simple and quite easily extensible. Also, it had colour graphic, multiutasking OS etc...
Although these things were cool three years ago, many things have changed since then.
If you absolutely need every cubic cm of space, they might be worth a look. Otherwise, forget it.
They are quite expensive, they have no drivers or some lousy drivers and their speed sucks.
If you can, use flexATX board with some Duron or Athlon or Pentium M or something similar and downlock it to get lower power drain.
It will have comparable price but still be much faster than mini-ITX.
VIA is charging the hell out of their customers.
If I could get some small board with a decent MIPS core and graphics and run conventional Linux (with modern and bug free drivers), I would forget about EPIA in a nanosecond.
VIA's support for Linux on EPIA boards is crap and I can't compile accelerated framebuffer for CLE266 and vesafb doesn't work for EPIA.
X11 driver works, but I need terminal emulation on framebuffer and also directFB should be quite a bit faster than X11.
VIA is offering source, but that source doesn't compile on 2.6.10 or 2.6.11.
It seems that there were quite some changes in fbdev in that time and I can't make that source to work with 2.6.11.
What are you talking about ?
Some 70% machines in use today have good old PATA discs. How do you think that Linux works on them ?
Besides, all of my external PATA cards are from Promise and I can assure you that they work with vanilla kernel 2.6. There IS module for Promise cards and it CAN be compiled in kernel !
This is not necessarily true. The difference in speed you'll get with a properly arranged MMU will be negligable.
Only if you have MMU onboard, but don't use it. Otherwise, changing from user adress space to kernel's and back should cost you something in terms of cpent CPU cycles and cache trashing.
If all processes share same address space, many things in kernel become faster and easier.
He was probably talking about Gentoo (Larry the Cow etc)
why is all this complication with CO2 neccessary.
Why not just make a helicopter ?
Atmosphere is thin, but if they can fly conventional wing in it, why not use rotor blades ?
Since they would probably have to be big, they could mount sollar cells right on the blades.
That could take care of the dust buildup too...
If you can't believe it, read the text of the patent .
I have basically just repeated what the patent says...
AMD is patenting this as a way of *getting around* of SOI disadvantages. SOI means silicon on insulator , which is in this case SiO2, which is also excellent thermal (not only electrical) insulator. AMD says that SiO2 conducts heat at least hundred times less than silicon.
What they are saying is that transistors on SOI might behave better, but they are certainly running hotter than their classic countepairs, since layer of SiO2 stands between them and the cooling system.
So AMD is proposing several schemes of embedding TEC device into the insulating layer in the silicon. This layer would:
1. Decrease overall thermal resisstance of the cooling path
2. When powered on, offer bigger thermal diferential, since it could cool embedded side of the TEC significantly below the cooler temperature.
It is unclear if they intend to use this on the whole chip, or just the especially hot areas...