I don't see why that ever happened anyways. They were still making revisions to 8088 machines in 1985 and slowly moving towards the 80286 with a few models. The clone makers were a bit faster off the mark, but they were still making PC-BIOS/DOS machines.
I fail to see how a single-tasking, segmented-memory, 1-meg-max machine could be considered even remotely "professional", when even a lowly CoCo could run a multitasking system (OS-9. The non-Apple one). The IBM-PC was completely and totally a member of the 8-bit home computer club. Real IBMs even had a BASIC ROM!
Windows was a complete bomb too. It was fat, bloated, unresponsive and slow. 386enh mode did nothing for stability. Lack of responsiveness killed user experience, and resulted in RS-232 communication difficulties. What's the point of memory protection if you crash hard anyhow?
Yeah, sure, there were lots of games for the other systems*, but that didn't mean you had to put up with DOS / Win3.x hell just to run business apps.
NT-class Windows addressed some of the issues, but at the expense of uncontrolled bloat, DLL hell, and registry BS.
To give an idea to Win3.x people who buried their heads in the sand, here's a translation of Amiga technologies to modern PC technologies:
AUTOCONFIG -> Plug and Play Datatypes -> codecs/filters RigidDiskBlock(RDB) -> EFI boot (only leaner, faster, and less retarded) Intuition Screens -> Whatever Windows 8 Metro term applies to having those full-screen Metro apps. Only Intuition screens could be shared by apps(feature) but could only tile vertically (limitation) and didn't restrict one to Metro-style only (feature++) Preemptive multitasking -> Name hasn't changed~ Blitter -> GUI hardware acceleration (95% abandoned in Vista, 10% added back to Windows 7). Volume name -> Like a volume label in Linux. Drive name -> like a drive letter in Windows, only it's 30 characters in legacy AmigaDOS instead of 1 or 2. DosPacket interface -> Asynchronous I/O. DosPacket interface -> zero copy read/write. AllocMem/AllocVec -> uhh nothing? Windows/Linux compilers/VMs still brk()s for memory and almost never gives it back, even under Java?
* = the PC was a fairly game-oriented system then, just not as good as the competitors. The irony is that it became the primary game system for a very long time, and is still a major force despite the number of "durp! I just want it to work!" people who have trouble double clicking.
Actually that's 4G address space in the original 68000.
The address registers were fully populated with 32 bits with the very first 68k. Only 24 address lines were actually connected (er, 23, was something odd with the odd addresses if I recall correctly), or 20 address lines in the 68008. Motorola (and Commodore, but NOT Apple) documentation said not to use the upper 8 bits of the address registers as they would one day be connected to address lines.
Lo and behold, the 68020 came out, and it had a full 32 address lines. Commodore's 32-bit clean code was validated, and Apple had to rush to fix code where they were using those "extra" bits as flags.
Also, the 68000, although only possessing a 16-bit-at-a-time ALU and 16 data lines, is effectively a full 32-bit architecture, just a bit pokey. It's lack of 32bit x 32bit = 64bit multiply was pointed out repeatedly by 386 programmers, but by and large, most high level programming languages even today don't support that. (usually they're limited to 32x32=32 or 64x64=64). Since it could do pretty much any 32 (op) 32 = 32 operation, you could write your high level code, and then expect it to be twice as fast on a 68020.
IBM should have used at least the 68008. It wasn't much bigger than an 8088 (used in the IBM PC and XT), being only a 44-pin DIP (vs 40-pin), and had full 68k functionality. The PC-AT could have then used the full-on 68000 instead of the 80286.
I'd like to add to your comment that the x86 front end, although hideously ugly compared to say, the 68k mentioned above, acts basically as an instruction compression engine.
So you have all the advantages of dense CISC-y instructions with a powerful RISC engine under the hood. Memory is still expensive and very small --> is a cache huge? is it cheap? No, and no. CISC-style instructions pack more easily into those tiny spaces, making cache misses less often and less expensive.
RISC didn't win. CISC didn't win. They both lost out to designs that can leverage the advantages of both.
Not entirely. One of the features of Sun's cancelled Rock CPU was something they called Thread Scout. The idea was to run one core ahead of another, skipping most computation, to pre-fault memory addresses.
That was done back in the days with the original 68000. They were put in tandem in some machines, and one processor ran slightly ahead of the other. If it hit a bus fault, the second 68000 was used to recover, as the original 68K could not recover normally from a bus fault. Obviously this was not for performance purposes, but rather for reliability, but it's amazingly similar.
The oh-ten could recover from bus faults, and the 020 had a full-scale (although external) MMU option, so the technique ceased to be used.
Canada is getting this way, at least with the large providers. I think Bell tops out at 75 gigs/month on a Fibe 25 connection (25mbit/sec down, 7mbit/sec up). I think you can eat that up in a single standard work shift.
Of course, I've had a connection with them solidly since 1998, and my grandfathered plan is an actual unlimited data plan, but that means I can't upgrade to a Fibe25 connection (without paying a lot of money for their "data insurance", which is still less than unlimited even if you buy it three times) as I'd have to cancel the old contract.
Cheapass power supplies with crappy PF are putting a higher load on the utility company for no purpose. The power factor is basically how far out of phase the return power is from the grid's phase.
Your actual drain is your current * voltage divided by the power factor.
180W (1.5A @120V) with a 0.67 power factor is 269W of loss at the plug. 180W (1.5A @120V) with a 0.98 power factor is 184W of loss at the plug.
Why would companies spend thousands just to correct the power factor if it had nothing to do with actual load?
The figures I used previously were for real life systems measured directly at the plug with a kill-a-watt meter.
There are other factors involved that aren't measured there (like the efficiency during transformation and rectification), but there's no way the Athlon XP 2500 is a higher power consumer than an i7 920. Also, the high end PSU is rated at over 80% efficient in those jobs too.
Ever measured the power drain on that? Don't forget to factor in power factor. My old Athlon XP system (which was stripped down of various high-drain performance parts when it became a server) has more draw than my i7 potato cooker thanks to it's no-name 350W supply's 0.67 power factor vs. the 0.98 or so power factor of the i7's high end PSU. Never mind that the voltage from the cheapy PSU varies quite a bit and is actually out of tolerance on the 5V side. I'd replace it, but that machine is due for retirement anyhow as it's now a backup to a backup server...
I do a bit of consulting on the side, and most system failures are caused by no name, came-with-the-cheap-case power supplies. It's like the good old C64 era all over again: most of those died due to the epoxy-filled craptastic power supply being wildly out of spec.
This is fully powered up (no sleep states) but not doing any heavy workload. Heavy workload flips those around, of course, but the older PSU is still using an extra 50% power for nothing other than heating the mains wires.
AmigaDOS (released mid 1985) uses 30-character names, including spaces etc, for drive names, volume names (the disk inserted in the drive, even hard drives had this, came in handy in the zip disk era), directory names and filenames. forward slash (/) for the separator, full-colon (:) for the root of the drive in question, and a null string for the current working directory ("").
Commodore 15xx series disk drives for the C64/128 (released at various times, starting in 1982) had 15 character filenames but no subdirectories. Volume names existed but I don't think they did anything. The actual C64/128 etc machines didn't really have a filesystem, the drive had almost as much processing capability of any of those 8-bit machines (6502 CPU and upwards of 8k of memory for some models) and handled all the 'filesystem' details.
MS-DOS really did take us way back. To be fair to CP/M, though, it was more of a 70s OS anyways and should have been laid to rest long before IBM went shopping around to strangle, er, monopolize, er, leverage another new computing industry.
To give an idea of what this has done to the industry, this is how I mount my 'projects' share from various machines: Linux/BSDs:/net/proj/ AmigaOS 3.x: projects: (with an alias of 'proj:') Windows/DOS: P:\ Commodore 128(keyboard style model): I don't have a smb or nfs driver for it. Or a network card. I could get the latter, and *possibly* the former if I cared though.
Your program isn't reflecting the reality of the situation.
Under Windows, merely opening a file for writing always locks it exclusively, unless you use one of the funky shared-write modes.
CreateFile("winblows.txt",GENERIC_WRITE,blah,blah,blah,blah,blah); -- winblows.dat has an exclusive lock on it. You cannot manipulate or delete it until that handle is released.
Under Unix variants, if you simply open a file in write mode, you can still manipulate and delete it. That's why Debian can do updates of running services whereas even the mighty windows 7 (er sorry, windows NT 6.1?) requires a reboot every month to patch in those updates.
The downside of the Unix method is that if you delete a file that's open for writing from another process, the space won't be released until that other process closes the file (or is terminated, which also closes the file). This, however, lets you use the files in a/tmp fashion without having to actually place them in/tmp, with a faster release to boot.
I'm not familiar with OSX ; I would have assumed it's the same as Linux/*BSD/etc, but some of the other posts and tests submitted suggest otherwise.
I wrote a DirectX 3* game many years ago as a test platform.
Most of the accelerator features available on PC platform at the time were either useless or not reliably available from system to system, so it generally just requested a surface and drew things manually (aside from background blits).
I still fire it up for fun every once in a while (yes, it still runs under Windows 7/64, despite being written for Windows 95, unlike 99% of the so-called "AAA" titles which crash and burn with each and every minor unrelated Microsoft update ever released, let alone moving from say Win2K->XP), and it runs fine..except one time my frame rate dropped off to something like 30fps for no reason. Normally it's running at 60fps, using less than 10% of the available render time. (I have vsync on; the game spends most of it's time waiting on a surface flip)
It turned out that my PCIe card dropped from 16x to 1x mode. It refused to return to 16x mode until I turned the machine entirely off. Once I did that though, it came back as 16x and my FPS was restored.
Those graphs are obviously for games/applications that aren't doing any direct rendering and aren't replacing textures very much. There ARE times when bus DOES matter.
Also, average times aren't going to tell the whole picture; do you really want to play an FPS that suddenly lags out while uploading textures for a new enemy that just appeared?
Granted if we're talking about PCIe 2.0 x4, it won't be quite so bad as say having to deal with 1x PCIe or old original low-end PCI, etc, but there will be times when the difference is very pronounced.
* - technically it's DirectX 5, but the only DX5 call it uses is the one that explicitly requests a frequency along with a resolution when setting the display mode. Plus, that was added later. It was originally purely DX3.
Random Ren Aside: I paid attention to the developer documentation. They told me stride(I think they called it 'pitch') isn't ~always~ equal to row length. They were right. They told me to use the QueryPerformanceCounter rather than snagging the TSC directly. They were right. Why can't AAA developers read these same documents?
You can get a USB->Amiga 1200 clockport bridge too.
The clock port is a little 22 pin header on Amiga 1200s (low end Amiga 'keyboard computer') that allow a realtime clock to be installed inexpensively.
Third party manufacturers have made USB controllers for it... amongst other things. You definitely can bridge transports with enough will! Even ones with 4 address lines and 8 data lines hooked up to D16 through D23 of a 32-bit data bus.
You know, I've been meaning to get a CF-to-IDE adapter and plug that into my old Amiga 1200.
You see, it didn't spontaneously write to the OS disk. EVER.
The only times writes occurred there is if you saved prefs, copied files there, or specified it as a location for a file that you're saving.
I think later third party extensions caused writes to be a bit more frequent, and I don't know about the successor OSes (>3.1), but 3.1 and earlier and earlier had this.. read purity thing going on. I'd love to run it on an old one gig CF card, as that would be tons of space for 3.1. Turns out, many years later, that this behavior has some very serious benefits -- it's the perfect OS to run on a flash card.
Hell, the original machine only had 120 -megabytes- of space anyways when it was a primary machine, with like a 20 meg OS partition.
I've never seen performance that good sitting next to the AP, and I've tested a fair number of these with a fair number of devices (~30 APs, 12 network cards of various sorts).
Even if you are getting that performance, that sounds like being tethered with a short ethernet cable. I attach a 50-foot cat5e and just bring it with me everywhere in my unit, I wouldn't want to be tied by a 10-footer.
Also, if 7.2 mbps is the peak speed, what are you going to do if your ISP upgrades you? I've had this same connection from the same ISP (more like, ILEC) and it's been upgraded several times over the years free of charge. Initially it was 1m/256k, then 3m/800k, then 5m, then 6, and then finally 8.5m. They keep on calling and trying to upsell me to the ultra package, which is (currently) 16m. 802.11b would be rather cumbersome at that point... nevermind the disaster waiting to happen should you do apt-get upgrade or hit windowsupdate or such while backing up userdata to a NAS/fileserver..
Finally, don't forget that there's more to performance than just mbps (specially sitting-next-to-the-ap mbps) where wireless suffers. I've noticed that wireless devices tend to go to sleep when not in constant usage, and take significant time (200ms+) to wake up when you click on the next link, etc.
I've found that fat32 drives are faster and more reliable. The only downside being the 4G limitation and that Microsoft disapproves of the patent-resistant/DRM-proof design and lack of unnecessary complication, and thus artificially caps volume size at 32 gigs (not an issue under other OSes, including this old Win98 boot disk I created long ago).
I've never had any issue with ext2/3 personally, aside from the fact that it's a bit slow on massive file deletion.
Oh, fat32's lack of permissions, in a Windows environment, is actually a good thing. I don't know how many times Windows has managed to completely screw up share permissions on my NTFS shares...
Ah, and which partition format will we be using that works with everything? And will this patch add these features to non-Windows boxes, or ones with restricted Admin rights, like most corporate machines?
So you think WPA2 and AES don't have any weaknesses at all? You realize that cannot ever be proven, right? You don't think there's any sideband attacks that could bypass them entirely, or that a weakness could be found any second now? People thought WPA and WEP would be fine too, if you recall..
Your WiFi router included from the LEC could very well not have WPA2 or a proper implementation of it. Should you use WPA1 or WEP then?
Also, even if there is never any attacks found against your specific hardware, or encryption algorithm, given time, a brute force attack that takes seconds will be feasible on a damn cellphone if you don't upgrade. Your AP will eventually reach the limits of it's hardware and your wireless network will be contributing generously to landfill.
Oh well, enjoy your 2% packetloss. BTW, please upgrade your upstream speed, the freeloaders are complaining that their torrents are slow.
No, it's correct in it's original form. It's managing Microsoft's rights to raep the customer base. Exactly like Digital Rights Management. It's like saying "rightsizing", to an extent, as well.
People just don't seem to get the context at all. Try to view it from the corporation's side.
Note that this is in no way unique to Microsoft, just about every large corporation will try to rights manage you, sooner or later. If it's big, and IT, you better have your personal lube ready, because they sure as hell didn't bring any.
Russian Reversal "rights manage YOU !!"-type joke not included.
Almost every computer available? Hardly. From the article: "The technology is available on Windows 7, Vista SP1, Windows Server 2008 and Windows Embedded CE". That's it. The Win 98, 2000, and XP systems you'll find in the wild won't support it. Some of the older systems (ie, XP) can be patched with an update from Microsoft, but are you going to carry a second removable media device with FAT16 or FAT32 around with you and install this patch everywhere you go? And bring XP or later as well for those machines running 98/NT4/2K? I don't believe there's Apple support either, and Linux support is still experimental.
I haven't seen the spec for exFAT (I'm not paying some fee to see a spec for some microsoft cruft), but I imagine it's another vendor-lockin, poor-performance-substitute abomination like NTFS was, or WinFS will be.
Slashdot Mirror
I don't see why that ever happened anyways. They were still making revisions to 8088 machines in 1985 and slowly moving towards the 80286 with a few models. The clone makers were a bit faster off the mark, but they were still making PC-BIOS/DOS machines.
I fail to see how a single-tasking, segmented-memory, 1-meg-max machine could be considered even remotely "professional", when even a lowly CoCo could run a multitasking system (OS-9. The non-Apple one). The IBM-PC was completely and totally a member of the 8-bit home computer club. Real IBMs even had a BASIC ROM!
Windows was a complete bomb too. It was fat, bloated, unresponsive and slow. 386enh mode did nothing for stability. Lack of responsiveness killed user experience, and resulted in RS-232 communication difficulties. What's the point of memory protection if you crash hard anyhow?
Yeah, sure, there were lots of games for the other systems*, but that didn't mean you had to put up with DOS / Win3.x hell just to run business apps.
NT-class Windows addressed some of the issues, but at the expense of uncontrolled bloat, DLL hell, and registry BS.
To give an idea to Win3.x people who buried their heads in the sand, here's a translation of Amiga technologies to modern PC technologies:
AUTOCONFIG -> Plug and Play
Datatypes -> codecs/filters
RigidDiskBlock(RDB) -> EFI boot (only leaner, faster, and less retarded)
Intuition Screens -> Whatever Windows 8 Metro term applies to having those full-screen Metro apps. Only Intuition screens could be shared by apps(feature) but could only tile vertically (limitation) and didn't restrict one to Metro-style only (feature++)
Preemptive multitasking -> Name hasn't changed~
Blitter -> GUI hardware acceleration (95% abandoned in Vista, 10% added back to Windows 7).
Volume name -> Like a volume label in Linux.
Drive name -> like a drive letter in Windows, only it's 30 characters in legacy AmigaDOS instead of 1 or 2.
DosPacket interface -> Asynchronous I/O.
DosPacket interface -> zero copy read/write.
AllocMem/AllocVec -> uhh nothing? Windows/Linux compilers/VMs still brk()s for memory and almost never gives it back, even under Java?
* = the PC was a fairly game-oriented system then, just not as good as the competitors. The irony is that it became the primary game system for a very long time, and is still a major force despite the number of "durp! I just want it to work!" people who have trouble double clicking.
As far as I know, all instructions are implemented in microcode... aside from in 6502s.
Actually that's 4G address space in the original 68000.
The address registers were fully populated with 32 bits with the very first 68k. Only 24 address lines were actually connected (er, 23, was something odd with the odd addresses if I recall correctly), or 20 address lines in the 68008. Motorola (and Commodore, but NOT Apple) documentation said not to use the upper 8 bits of the address registers as they would one day be connected to address lines.
Lo and behold, the 68020 came out, and it had a full 32 address lines. Commodore's 32-bit clean code was validated, and Apple had to rush to fix code where they were using those "extra" bits as flags.
Also, the 68000, although only possessing a 16-bit-at-a-time ALU and 16 data lines, is effectively a full 32-bit architecture, just a bit pokey. It's lack of 32bit x 32bit = 64bit multiply was pointed out repeatedly by 386 programmers, but by and large, most high level programming languages even today don't support that. (usually they're limited to 32x32=32 or 64x64=64). Since it could do pretty much any 32 (op) 32 = 32 operation, you could write your high level code, and then expect it to be twice as fast on a 68020.
IBM should have used at least the 68008. It wasn't much bigger than an 8088 (used in the IBM PC and XT), being only a 44-pin DIP (vs 40-pin), and had full 68k functionality. The PC-AT could have then used the full-on 68000 instead of the 80286.
I'd like to add to your comment that the x86 front end, although hideously ugly compared to say, the 68k mentioned above, acts basically as an instruction compression engine.
So you have all the advantages of dense CISC-y instructions with a powerful RISC engine under the hood. Memory is still expensive and very small --> is a cache huge? is it cheap? No, and no. CISC-style instructions pack more easily into those tiny spaces, making cache misses less often and less expensive.
RISC didn't win. CISC didn't win. They both lost out to designs that can leverage the advantages of both.
And I really like the idea of WinRT being next to the old and buggy Win32, if they get WinRT right.
That's less likely now than it would have been if WinRT had been developed back in the NT4 era.
And it wasn't very likely back then either.
Not entirely. One of the features of Sun's cancelled Rock CPU was something they called Thread Scout. The idea was to run one core ahead of another, skipping most computation, to pre-fault memory addresses.
That was done back in the days with the original 68000. They were put in tandem in some machines, and one processor ran slightly ahead of the other. If it hit a bus fault, the second 68000 was used to recover, as the original 68K could not recover normally from a bus fault. Obviously this was not for performance purposes, but rather for reliability, but it's amazingly similar.
The oh-ten could recover from bus faults, and the 020 had a full-scale (although external) MMU option, so the technique ceased to be used.
Canada is getting this way, at least with the large providers. I think Bell tops out at 75 gigs/month on a Fibe 25 connection (25mbit/sec down, 7mbit/sec up). I think you can eat that up in a single standard work shift.
Of course, I've had a connection with them solidly since 1998, and my grandfathered plan is an actual unlimited data plan, but that means I can't upgrade to a Fibe25 connection (without paying a lot of money for their "data insurance", which is still less than unlimited even if you buy it three times) as I'd have to cancel the old contract.
Bell Fibe 25 pricing
Rogers pricing
(Rogers "Extreme" internet is similar to Fibe 25, although upload speeds are 1/7th as fast..)
And also:
http://en.wikipedia.org/wiki/Castle_Wolfenstein ..which was an interesting game back in the day.
http://en.wikipedia.org/wiki/Power_factor
Cheapass power supplies with crappy PF are putting a higher load on the utility company for no purpose. The power factor is basically how far out of phase the return power is from the grid's phase.
Your actual drain is your current * voltage divided by the power factor.
180W (1.5A @120V) with a 0.67 power factor is 269W of loss at the plug.
180W (1.5A @120V) with a 0.98 power factor is 184W of loss at the plug.
Why would companies spend thousands just to correct the power factor if it had nothing to do with actual load?
The figures I used previously were for real life systems measured directly at the plug with a kill-a-watt meter.
There are other factors involved that aren't measured there (like the efficiency during transformation and rectification), but there's no way the Athlon XP 2500 is a higher power consumer than an i7 920. Also, the high end PSU is rated at over 80% efficient in those jobs too.
http://www3.ttc.ca/About_the_TTC/Projects_and_initiatives/New_Subway_Train/index.jsp
This train seats 404 (heh). The total would be 1,598. I bet in actual usage it exceeds 2,000-2,200 well-sardined people.
188 KJ per person, versus 1 MJ per person in a car (seeing as the average car around here carries 1.0000001 people), in rush hour.
That's a six car train. A ten-car would have almost 2700 people in it by 'spec'.
Ever measured the power drain on that? Don't forget to factor in power factor. My old Athlon XP system (which was stripped down of various high-drain performance parts when it became a server) has more draw than my i7 potato cooker thanks to it's no-name 350W supply's 0.67 power factor vs. the 0.98 or so power factor of the i7's high end PSU. Never mind that the voltage from the cheapy PSU varies quite a bit and is actually out of tolerance on the 5V side. I'd replace it, but that machine is due for retirement anyhow as it's now a backup to a backup server...
I do a bit of consulting on the side, and most system failures are caused by no name, came-with-the-cheap-case power supplies. It's like the good old C64 era all over again: most of those died due to the epoxy-filled craptastic power supply being wildly out of spec.
PSU test results:
AMD Athlon XP 2500+ - 110W @0.67 PF = 164W
Intel i7 920 - 130W @0.98 PF = 133W
This is fully powered up (no sleep states) but not doing any heavy workload. Heavy workload flips those around, of course, but the older PSU is still using an extra 50% power for nothing other than heating the mains wires.
I'd love to play with an 800XL. That's like the 8-bit ancestor to my Amiga lineup.
Nothing meaningful? How about full 3D?
But then again, Quake gave us that.
I call 'em "Quake clones".
AmigaDOS (released mid 1985) uses 30-character names, including spaces etc, for drive names, volume names (the disk inserted in the drive, even hard drives had this, came in handy in the zip disk era), directory names and filenames. forward slash (/) for the separator, full-colon (:) for the root of the drive in question, and a null string for the current working directory ("").
Commodore 15xx series disk drives for the C64/128 (released at various times, starting in 1982) had 15 character filenames but no subdirectories. Volume names existed but I don't think they did anything. The actual C64/128 etc machines didn't really have a filesystem, the drive had almost as much processing capability of any of those 8-bit machines (6502 CPU and upwards of 8k of memory for some models) and handled all the 'filesystem' details.
MS-DOS really did take us way back. To be fair to CP/M, though, it was more of a 70s OS anyways and should have been laid to rest long before IBM went shopping around to strangle, er, monopolize, er, leverage another new computing industry.
To give an idea of what this has done to the industry, this is how I mount my 'projects' share from various machines: /net/proj/
Linux/BSDs:
AmigaOS 3.x: projects: (with an alias of 'proj:')
Windows/DOS: P:\
Commodore 128(keyboard style model): I don't have a smb or nfs driver for it. Or a network card. I could get the latter, and *possibly* the former if I cared though.
Your program isn't reflecting the reality of the situation.
Under Windows, merely opening a file for writing always locks it exclusively, unless you use one of the funky shared-write modes.
CreateFile("winblows.txt",GENERIC_WRITE,blah,blah,blah,blah,blah); -- winblows.dat has an exclusive lock on it. You cannot manipulate or delete it until that handle is released.
Under Unix variants, if you simply open a file in write mode, you can still manipulate and delete it. That's why Debian can do updates of running services whereas even the mighty windows 7 (er sorry, windows NT 6.1?) requires a reboot every month to patch in those updates.
The downside of the Unix method is that if you delete a file that's open for writing from another process, the space won't be released until that other process closes the file (or is terminated, which also closes the file). This, however, lets you use the files in a /tmp fashion without having to actually place them in /tmp, with a faster release to boot.
I'm not familiar with OSX ; I would have assumed it's the same as Linux/*BSD/etc, but some of the other posts and tests submitted suggest otherwise.
Debian 5.0:
rene@tessa:~/test$ cat > ABCD /home/rene/test/ABCD
^Z
[1]+ Stopped cat > ABCD
rene@tessa:~/test$ lsof | grep ABCD
cat 3263 rene 1w REG 3,1 0 429757
rene@tessa:~/test$ mv ABCD EFGH
rene@tessa:~/test$ ls
EFGH
rene@tessa:~/test$ fg
cat > ABCD
abcd's contents
rene@tessa:~/test$ ls
EFGH
rene@tessa:~/test$ cat EFGH
abcd's contents
Writing into a file simultaneously from multiple handles is possible but not advised.
I wrote a DirectX 3* game many years ago as a test platform.
Most of the accelerator features available on PC platform at the time were either useless or not reliably available from system to system, so it generally just requested a surface and drew things manually (aside from background blits).
I still fire it up for fun every once in a while (yes, it still runs under Windows 7/64, despite being written for Windows 95, unlike 99% of the so-called "AAA" titles which crash and burn with each and every minor unrelated Microsoft update ever released, let alone moving from say Win2K->XP), and it runs fine..except one time my frame rate dropped off to something like 30fps for no reason. Normally it's running at 60fps, using less than 10% of the available render time. (I have vsync on; the game spends most of it's time waiting on a surface flip)
It turned out that my PCIe card dropped from 16x to 1x mode. It refused to return to 16x mode until I turned the machine entirely off. Once I did that though, it came back as 16x and my FPS was restored.
Those graphs are obviously for games/applications that aren't doing any direct rendering and aren't replacing textures very much. There ARE times when bus DOES matter.
Also, average times aren't going to tell the whole picture; do you really want to play an FPS that suddenly lags out while uploading textures for a new enemy that just appeared?
Granted if we're talking about PCIe 2.0 x4, it won't be quite so bad as say having to deal with 1x PCIe or old original low-end PCI, etc, but there will be times when the difference is very pronounced.
* - technically it's DirectX 5, but the only DX5 call it uses is the one that explicitly requests a frequency along with a resolution when setting the display mode. Plus, that was added later. It was originally purely DX3.
Random Ren Aside: I paid attention to the developer documentation. They told me stride(I think they called it 'pitch') isn't ~always~ equal to row length. They were right. They told me to use the QueryPerformanceCounter rather than snagging the TSC directly. They were right. Why can't AAA developers read these same documents?
You can get a USB->Amiga 1200 clockport bridge too.
The clock port is a little 22 pin header on Amiga 1200s (low end Amiga 'keyboard computer') that allow a realtime clock to be installed inexpensively.
Third party manufacturers have made USB controllers for it... amongst other things. You definitely can bridge transports with enough will! Even ones with 4 address lines and 8 data lines hooked up to D16 through D23 of a 32-bit data bus.
You know, I've been meaning to get a CF-to-IDE adapter and plug that into my old Amiga 1200.
You see, it didn't spontaneously write to the OS disk. EVER.
The only times writes occurred there is if you saved prefs, copied files there, or specified it as a location for a file that you're saving.
I think later third party extensions caused writes to be a bit more frequent, and I don't know about the successor OSes (>3.1), but 3.1 and earlier and earlier had this .. read purity thing going on. I'd love to run it on an old one gig CF card, as that would be tons of space for 3.1. Turns out, many years later, that this behavior has some very serious benefits -- it's the perfect OS to run on a flash card.
Hell, the original machine only had 120 -megabytes- of space anyways when it was a primary machine, with like a 20 meg OS partition.
So, for some OSes, it would be the perfect media.
Totally agreed there, but you forgot "Registers" or "Register File" at the top of that speed progression.
Flash is going to run into the quirky nature of low-nanometer electronics before long, too.
I've never seen performance that good sitting next to the AP, and I've tested a fair number of these with a fair number of devices (~30 APs, 12 network cards of various sorts).
Even if you are getting that performance, that sounds like being tethered with a short ethernet cable. I attach a 50-foot cat5e and just bring it with me everywhere in my unit, I wouldn't want to be tied by a 10-footer.
Also, if 7.2 mbps is the peak speed, what are you going to do if your ISP upgrades you? I've had this same connection from the same ISP (more like, ILEC) and it's been upgraded several times over the years free of charge. Initially it was 1m/256k, then 3m/800k, then 5m, then 6, and then finally 8.5m. They keep on calling and trying to upsell me to the ultra package, which is (currently) 16m. 802.11b would be rather cumbersome at that point... nevermind the disaster waiting to happen should you do apt-get upgrade or hit windowsupdate or such while backing up userdata to a NAS/fileserver..
Finally, don't forget that there's more to performance than just mbps (specially sitting-next-to-the-ap mbps) where wireless suffers. I've noticed that wireless devices tend to go to sleep when not in constant usage, and take significant time (200ms+) to wake up when you click on the next link, etc.
I've found that fat32 drives are faster and more reliable. The only downside being the 4G limitation and that Microsoft disapproves of the patent-resistant/DRM-proof design and lack of unnecessary complication, and thus artificially caps volume size at 32 gigs (not an issue under other OSes, including this old Win98 boot disk I created long ago).
I've never had any issue with ext2/3 personally, aside from the fact that it's a bit slow on massive file deletion.
Oh, fat32's lack of permissions, in a Windows environment, is actually a good thing. I don't know how many times Windows has managed to completely screw up share permissions on my NTFS shares...
Ah, and which partition format will we be using that works with everything? And will this patch add these features to non-Windows boxes, or ones with restricted Admin rights, like most corporate machines?
So you think WPA2 and AES don't have any weaknesses at all? You realize that cannot ever be proven, right? You don't think there's any sideband attacks that could bypass them entirely, or that a weakness could be found any second now? People thought WPA and WEP would be fine too, if you recall..
Your WiFi router included from the LEC could very well not have WPA2 or a proper implementation of it. Should you use WPA1 or WEP then?
Also, even if there is never any attacks found against your specific hardware, or encryption algorithm, given time, a brute force attack that takes seconds will be feasible on a damn cellphone if you don't upgrade. Your AP will eventually reach the limits of it's hardware and your wireless network will be contributing generously to landfill.
Oh well, enjoy your 2% packetloss. BTW, please upgrade your upstream speed, the freeloaders are complaining that their torrents are slow.
No, it's correct in it's original form. It's managing Microsoft's rights to raep the customer base. Exactly like Digital Rights Management. It's like saying "rightsizing", to an extent, as well.
People just don't seem to get the context at all. Try to view it from the corporation's side.
Note that this is in no way unique to Microsoft, just about every large corporation will try to rights manage you, sooner or later. If it's big, and IT, you better have your personal lube ready, because they sure as hell didn't bring any.
Russian Reversal "rights manage YOU !!"-type joke not included.
Almost every computer available? Hardly. From the article: "The technology is available on Windows 7, Vista SP1, Windows Server 2008 and Windows Embedded CE". That's it. The Win 98, 2000, and XP systems you'll find in the wild won't support it. Some of the older systems (ie, XP) can be patched with an update from Microsoft, but are you going to carry a second removable media device with FAT16 or FAT32 around with you and install this patch everywhere you go? And bring XP or later as well for those machines running 98/NT4/2K? I don't believe there's Apple support either, and Linux support is still experimental.
I haven't seen the spec for exFAT (I'm not paying some fee to see a spec for some microsoft cruft), but I imagine it's another vendor-lockin, poor-performance-substitute abomination like NTFS was, or WinFS will be.