In the old Amiga days, some formats used prefixes.
mod.* instead of *.mod (or in the classic manner, "mod.#?")
This has a small advantage in file type comparison, and a larger advantage that it will make your files sort type (and then name) automagically when passed through a sorting list command or viewed in a file requester that sorted.
It wasn't practiced too widely, but that didn't matter as a typical GUI application used the system file requesters, which had a filter field where you could type something like, "mod.#?" if you chose that path.
> never really cared for having one driver that handled umpteen different devices, makes me suspicious of bloat
Eh, don't worry about that. Everything is based off of RealTek 8139 chips anyways. SMC 1211tx? RTL8139. D-Link 538? RTL8139. nVidia nForce2 network controller? enhanced RTL8139 (8100-series). Intel Pentium 4? RTL8139. That light switch over there? RTL8139. Slashdot servers? A Beowulf cluster of RTL8139s. The universe? A huge collection of quantum-sized RTL8139s.
Well, okay, that started getting silly around Pentium 4, but so many different models and products are really just the same thing with a different logo/model number/color.
I'm more concerned about products that have different drivers for the same model number. I think, for example, some DLink cards are based off of the excellent tulip chip before a certain revision, and then the crappy rtl8139 chip afterwards. (I think it was the 530 card. A good warning sign is that it's suddenly $15 instead of $45)
Hmmm, Amiga 300.. Long awaited, never released PDA or tablet?
Woot!
Really offtopic: I picked up a new Asus notebook recently, and it consumes almost three times the power of an Amiga 1200 with an 030 accellerator. It made my old power inverter (50W) fall over in a very bad way. What ever happened to the people saying that the custom chips ate too much power? Was going to McGuyver an external battery pack out of NiMH D-cells, until I realized that I'd need literally 45 to get any decent extra run time out of them. The wiring would also have to support 3.5 amps at ~19v. Gah!
> A proprietary XML file is not at all proprietary compared to a binary file. They're easy for even a novice programmer to figure out how to read.
I dunno, I always found EA/Commodore IFF files to be easy enough to read. PNGs, being inspired by IFFs, are pretty easy too despite the zlib requirements. They're all happy binary files, too. It's the clear and concise documentation that makes a good standard, not wether it's some fancy new ASCII-SGML-etc-text standard or not.
I'm pretty sure (as in absolutely certain, as in being a developer for this system) that my Amiga 500 did passing-by-register with it's "16-bit" 68000 CPU.
Of course, this "16-bit" processor was really more 32-bit than say, a 386 based design, as it had eight 32-bit data registers, and eight 32-bit address registers which could address a 4GB linear address space.
The OS itself used all pass-by-register interfaces, which used an address register plus offset jumptable calling system that was lightning fast, but you could compile your binaries to also use pass-by-register or the more traditional pass-by-stack system. Pass-by-register programs generally saw a performance increase between 10% and 800%, depending on how function-happy/OS-call-happy they were.
It's nice to see that the rest of the industry it's finally catching up. Datatypes to Codecs, register to register,.library to.so/.dll, finally.
Strikes me that mainstream progress is really just re-implementing old ideas from non-mainstream sources.
PS. Just a little note to those who thought your ISA didn't matter (ISA as in instruction set architecture, not as in that nasty crappy IBM bus), I say, "Ha!"
Actually, the new process might take less energy to switch states than current processes, (higher efficiency) thusly creating less heat. CMOS chips, for instance, ran cooler than NMOS equivalents, as I recall.
---
And in reply to the parent of the parent of this post, I do own at least four production-scale, original stock computers, which have no fans and run pretty much cool. A Commodore 128, Amiga 500 (x2) and Amiga 1200. None of these machines have any moving parts in their stock configuration save the floppy drives, which normally don't move except during loading. They neither have nor require any fans, not even in the power supplies.
That was basically the way in the old days. PCs had power supply fans, and many other machines did not. Cocos, Ataris, etc, also did not have fans. Those old Commodore boxes were pretty damned useful too - the 1200 could chat on IRC, compile software in the background, edit source, and surf web pages with only a 4 meg ram upgrade card (total 6 megs - 2 megs shared video/cpu, 4 megs dedicated cpu ram) and a hard drive. Using only 23 watts of power, too. Couple that with a very power misery LCD and you could have a useful little box (well, keyboard, really) for the power of a lightbulb. None of this 600 watt PC nonsense. (Even my more modest 350W PC makes the lights dim slightly when I flick on the switch at the back of the PSU..ow)
> I look after my disks so I don't need to make backups of them
There's been evidence that CD-ROMs, including pressed-at-the-factory variety, can become unglued over time, causing data loss, regardless of how well looked-after they are. You may want to back up your more expensive titles you own.
Isn't PDF some sort of bastardization of Microsoft's.DOC format? IANAPDFE (I am not a PDF expert), but I'm pretty sure I read that somewhere when trying to figure out how to read a PDF using my own code..
Anyhow, yes, that would make the comparison fairer. Or, if there was some way to take MS Office's preloading out.. (I imagine it's more than just that OSA9 thing in the startup folder)
Well, the decrease in monitor depth and reduction of eye-strain while coding is desirable, but I still notice the lack of responsiveness on the 16-20ms models for gaming.
Also, for many games, a resolution of 800x600 is perfectly adequate (Jedi *, non-railgun Q3, Homeworld series - games where long range doesn't matter) and offers a tremendous speed boost. Some games, such as Halo, are unplayable at resolutions higher than 640x480 with all options off on this crappy GeForce 5200 board (The 4200 died and I quickly grabbed the cheapest off the shelf board I could find; what a disappointment when I found that it was noticibly SLOWER than the 4200 - a 64 meg, high-bandwidth memory model).. Remember that extra pixelage is not only increased data for the 3D engine to render, it also takes a greater toll on memory bandwidth during display.
(Damn, but I need a new video board. Maybe I'll get an ATI this time..)
> In any event, my own experiences of Word 2000 on Win2000, with P3's is that of 30+ second waits. Simply unacceptable, when forced to use it at work, I'd use notepad instead.
Even on the P3 machine here, it was only in the 5-ish second times (Unofficial~). I wonder if there's a memory issue on those systems; the systems I build are typically over spec when it comes to RAM.
That system was a P3-1000, 512 megs of PC133 SDR, and um.. Win2000 with Word2000 installed. When I install microsoft products I tend to use minimal possible installs and avoid the "install from CD on first use" crap, which may also impact performance.
The increased RAM, minimized installs and such may have significant performance gains, although I suspect they may be somewhat offset by the fact that I prefer smaller, slower hard drives, due to the decrease in cost~
Hmm, maybe I should install Win2000/Word2000 on that machine again, using a spare drive. (it's currently a Debian webserver) It's other performance metrics were actually superior to the P4..
Oh well, office products are all bloated crap anyways. vi/editplus, please.
OO takes 58 seconds to open on my P4 test machine, and word about 4.5 seconds. (Both tests performed after a clean boot; P4 1400mhz, old junker with a 40 gig drive and 256 megs of old SDRAM. OSes are Redhat 8 for OO and Windows 2000 for Word).
I don't have OO on my main system (2500 AthlonXP; 512 megs DDR; slightly more recent 120GB HD) but Word takes about 2.5 seconds on this system to load from a clean boot.
While I think Microsoft is mentioned in the bible ("Agent of the Beast", I believe they said), and I liked certain parts of your post, (the asshattery part is very true on both fronts and I use plain text editors as much as possible) I dislike any distortion of fact, regardless of who the fact may be appealing to.
In any case, reading those.doc files properly ten years from now will be rather difficult, I imagine. That's why I use plain text with soft line wrapping... that hasn't changed much in the 20 years I've been in computing. (Well cept for the line ends, but it's pretty trivial to convert MacAmiga/UnixDOS files)
I'll stick with my $150 CDN (something like 200ish euros) 10ms CRT, thank you very much. The fact that it can display multiple resolutions other than "native" is quite appealing, and 450 euros would be enough for me to buy a whole new mobo+CPU+memory combo. and case... and decent PSU..
Actually it's probably significantly faster than 10ms, but that's the effective speed at 100hz.
Oh well.
> Another option would have been limited battery life for the flashlight
A mag lasts how long on plain, off-the-shelf alkaline D cells? 8 hours? 10? How much longer if it was some sophisticated led-based system?
That was one thing that pissed me off a lot in Halo - you have a micro-sized fusion reactor on your back that provides enough power for a suit of power armor that can flip a main battle tank over, as well as generate a shield strong enough to deflect plasma fire.. and your flashlight, about as bright as a three cell mag light light, runs out of batteries in five minutes.. (and it does recharge from the pack, too) Dammit!!
(And the damned marines have lights that last for the whole mission)
Anyways, a nice bright six cell mag with an upgraded bulb would quite easily blind some sort of creature with excellent night vision.. unless the system it uses for sight is more flexible than a human's, of course.
I find it sort of interesting that people seem to lump software into two very generalized categories:
- Secure OSS/Free software - Insecure, buggy, proprietary Microsoft software.
What happened to non-Microsoft proprietary software? While you don't have the OSS and Free benefits with other proprietary vendors, they tend to be a lot better than our old friend Bill.
Eudora and Opera, for instance, are much better than Outbreak (heh, that's a good one, and approriate too) and IE in terms of stability and security.
1) Integrated motherboards consolidating most functions into a few chips with the Apple ][,
Eh, most old 8-bit systems did that. Back in the 80s microcomputer wars, the IBM croud always maintained that integrated designs were un-upgradable and therefore inferior. Not that I necessarily agree, but this is a somewhat contended point
2) Plug and Play compatibility with NUBUS,
Is Nubus before or after Zorro-II ? (I honestly don't know but I imagine it's close in either case)
4) First to use small form floppies with the Apple ][c
That was April 84 wasn't it? I believe that's around the same time Atari came up with it's ST system, also based on 3" floppies. the Amiga wasn't far behind in 85 with the same floppies.
5) First to support on board sound and graphics with Macintsoh,
Like a Commodore 64, some three years earlier? And most other microcomputers? Funny that you'd call blitterless monochromatic magic, "graphics".
6) First to include built in networking with Macintosh,
I dunno, my C64 came with a serial port and user port too..
9) First to develop the laptop form factor as we know it with the Powerbook,
My 386 laptop, around the exact same time, is also the same shape as a modern laptop. Come to think of it, my friend's ancient 286 laptop from years before looks just like my 386 laptop, only white instead of gray...
10) First to leverage the GPU for routine interface with OS X,
The Amiga 1000 ('85) used it's GPU (Agnus) for almost everything, including blitting (user accessable API included) and DMA (disk access, etc). Technically it didn't use OS X, though.
11) First speech technology with the Apple ][,
That's cool, but could you copy text files to the voice: device via CLI or GUI to make it read them?
12) First virtual programming environment with Hypercard,
Is that like the 8086 or 80286 bridgeboards that can go into any Zorro-II Amiga, that contain a complete PC?
15) First cross platform standard for multi-media with Quicktime,
What about mpegs?
16) The first "multimedia" PC with the MacTV that integrated a television with stereo CD back in 1993 or so. We could go on and on here, but you get the point.
That was many years after the Commodore CDTV and possibly even after the CDTV's successor, the CD^32. Granted that's not with a built-in TV, but at the rate CRTs blow, having one built-in would be more accurately described as a "design flaw". All of my original C64 stuff, Amiga boxen, and PC boxen have long outlasted the vast majority of my CRTs, save a 12-year-old monovga monitor that I gave to Goodwill last year. Well, technically my Amiga 500 doesn't tell time properly and has some other timing problems due to one of the CIA chips being damaged, but I could drop in a replacement chip for $15.. but aside from that, all the boxes have outlived their CRTs by a wide margin. I imagine the same would be true for LCDs.
> It's a cheap architecture (actually the same idea as the PC-jr video/CPU memory!) but not good for performance at all.
Actually, that's not true. Amiga machines used that to great advantage in the old days, and a P3 with a 133mhz front side bus doesn't have ANY other use for all that bandwidth anyways. Xboxen have RDRAM if I recall correctly, which is way beyond the old non-DDR SDRAM spec that the P3 was designed for. The memory probably gets bored waiting for the CPU.:P
The upside of unified memory architecture (I do believe that's what SGI called it when they were going all nuts about it) is that the CPU has very, VERY direct access to the video memory, and the GPU has very, VERY direct access to the system memory, as they are one and the same...
Of course, I suppose Xboxen don't have any "Fast RAM" (dedicated, CPU-only, seperate bus RAM) like the old Amigas, but still, it does work well enough for the Xbox.
Of course, Xboxen don't have to worry about things like this article's topic, as they all have a perfectly uniform specification. Kinda handy when you don't have to cater to the P4 Extreme/Athlon64 market at the same time as the 386SX market.
> I'll go off on a tangent here and compare current copy prevention mechanisms to the software copy prevention mechanisms from the eighties. Who remembers things like "off disk copy protection", or disks that were purposely damaged to as to be uncopyable?
I remember this all too well, and it's unfortunately coming back. Many CD based games use copy protection techniques to encode marginally readable bits and such, and look for these bits as coming back randomly on successive reads. This makes the game impossible to copy without modifying the executable to skip over this protection, as well as requiring the CD in the drive to play. So much for backing up my software! I'm of the mind that such games should come with two or three copies of the CD, all in their own seperate jewel case, for backup purposes. (The hilarious thing is that the pirates have already created solutions for these schemes, it only really stops legit users from making backups at the end of the day)
> I'm not going to be ignorant about the problem of piracy by claiming it's not a problem at all, it's the methods of preventing it I question...
Actually, I have a suspicion that most pirates wouldn't buy if they couldn't copy anyways. They'd just go without or tape from the radio, I bet.
Then, there's always that patch cable from the CD player to the Mic In jack on the back of the machine, plus the old sneaker net....
"Then, I realized that I had just assumed all other people are like me: wanting to do their best job at coding and make sure it's code that will work and be maintainable for years to come"
When I first started my most recent job, I had a vision like this also. Then I discovered our log downloading was a blind shell script. With no detection for either missing logs or half-downloaded logs. Then I discovered that the PREVIOUS iteration was ALSO a shell script, only in a slightly different style (but still hard-coded addresses and such). Then I discovered the system BEFORE that was a series of RSH commands, also blind, also hardcoded, AND completely replaced for no reason whatsoever.
I was horrified. It was awful. Totally against everything I believed in. My job was cut out for me: The hours of checking for missing junk had to go!
I implemented over a few days a Perl-based downloader that had the following features: - "+EOF" check to determine that the whole log was downloaded (a simple change to the webservers' rotate logs script) - Additional checks to see that the download command didn't abort with an unusual error level - Basic download throttling. It's a lot faster downloading 6 logs at once rather than 384 at once. - Easily updated text configuration file (never made the CGI to administrate that, but it was dead easy in VI anyways) - Descriptive variable names and clear processi within the script - External documentation which included justification for all features employed as well as explanations of optimizations and whatnot - Detection of changes to the domain names for the websites that may indicate that additional servers were added (or removed) from a given domain - Support for multiple download protocols (SSH and FTP implemented initially) - Support for a "download caching" area, as the hardware of the time was a big, faulty raid array that topped out at 250k/sec effective write speed (adding a 36G drive to download one day's of logs helped tremendously, and the logs could then be gzip-piped over to the dog slow raid at a reasonable rate (2.5 megs/sec effective with gzip))
To make a long story short, this system was everything the predecessors' systems were not: Elegant, extendable, maintainable, documented, fast, but (leaving out the configuration file) short. I no longer had to hunt for hours to find missing logs or run manual checks and harass system administrators to figure out if any hosts had been added/removed from domains, etc. Everything ran smoothly, and I had little to do but sit, relax, and try not to laugh at management's horrible new ideas. Any inebriated monkey could manage the new, improved system.
Unfortunately, as I was no longer critical to the operation, and an inebriated monkey was a bit cheaper than my paycheque, management gave me the old heave-ho.
I guess the previous maintainers who wrote poorly maintainable, useless code knew something I didn't.. doh!
The difference, a small but important one, is that Rockstar isn't shoving copies of GTA through your mail slot or emailing it to you..
I could care less about penis pumps, sex toys, porn, and generic viagra, but I DO mind people clogging my email server..
Nobody's forcing you to buy GTA. The spammers ARE, however, forcing you to download and sort through dozens of emails every day. Let them buy banner ads and billboards instead, just not on my penny!
> I just wish IFF had survived the death of the Amiga as a mainstream platform.
Actually in many ways it did; PNG and FLACC and such tend to use an IFF-like structure, and indeed, PNG credits IFF in the documentation. I've noticed that the graphics programs I work with (Photoshop 4, Paint Shop Pro 6) tend to have 'iff' in their Export lists. New ones may not support IFF, but at least those two did.
IFF would have done even better though, if it had had better, more official support for things like "chunky" (byte-oriented rather than bitplane-oriented) graphics, 15, 16, and 24 bit modes, etc.
Heck, you could lay out a spec for ILB\1 (ILBM next generation) and support all these things. IFF exists as a concept as well as a specification, and can be adapted. The only downside to doing this is that I think the "2-byte align" nonsense is part of the IFF spec. It's almost as bad as that "4-byte" row-align crap in windows and os/2 "bmp" format.
Anyways, I think I'll get out my RKRM: Libs book and see about drafting a spec for some of my own programming projects. If there's that 2-byte nonsense, I may very well lay down an IFF\2 spec or something:P (Nonsense because data alignment is pretty darn well meaningless on disk unless you're talking about 512-byte alignment:P)
Slashdot Mirror
In the old Amiga days, some formats used prefixes.
mod.* instead of *.mod (or in the classic manner, "mod.#?")
This has a small advantage in file type comparison, and a larger advantage that it will make your files sort type (and then name) automagically when passed through a sorting list command or viewed in a file requester that sorted.
It wasn't practiced too widely, but that didn't matter as a typical GUI application used the system file requesters, which had a filter field where you could type something like, "mod.#?" if you chose that path.
> never really cared for having one driver that handled umpteen different devices, makes me suspicious of bloat
Eh, don't worry about that. Everything is based off of RealTek 8139 chips anyways. SMC 1211tx? RTL8139. D-Link 538? RTL8139. nVidia nForce2 network controller? enhanced RTL8139 (8100-series). Intel Pentium 4? RTL8139. That light switch over there? RTL8139. Slashdot servers? A Beowulf cluster of RTL8139s. The universe? A huge collection of quantum-sized RTL8139s.
Well, okay, that started getting silly around Pentium 4, but so many different models and products are really just the same thing with a different logo/model number/color.
I'm more concerned about products that have different drivers for the same model number. I think, for example, some DLink cards are based off of the excellent tulip chip before a certain revision, and then the crappy rtl8139 chip afterwards. (I think it was the 530 card. A good warning sign is that it's suddenly $15 instead of $45)
Hmmm, Amiga 300.. Long awaited, never released PDA or tablet?
Woot!
Really offtopic: I picked up a new Asus notebook recently, and it consumes almost three times the power of an Amiga 1200 with an 030 accellerator. It made my old power inverter (50W) fall over in a very bad way. What ever happened to the people saying that the custom chips ate too much power? Was going to McGuyver an external battery pack out of NiMH D-cells, until I realized that I'd need literally 45 to get any decent extra run time out of them. The wiring would also have to support 3.5 amps at ~19v. Gah!
Red alert, shields up! Close the USB ports!
I read the article title as, "attacking via USB".. Once if by LAN, twice if by USB?
> If, as the Counting Crows put it,
> "They took all the trees, and put em in a tree museum
> And they charged the people a dollar and a half to see them..."
I just find it interesting that this particular song was chosen as an example.
How many artists have sung this particular song? Eight? Nine? More? Oh well.
> A proprietary XML file is not at all proprietary compared to a binary file. They're easy for even a novice programmer to figure out how to read.
I dunno, I always found EA/Commodore IFF files to be easy enough to read. PNGs, being inspired by IFFs, are pretty easy too despite the zlib requirements. They're all happy binary files, too. It's the clear and concise documentation that makes a good standard, not wether it's some fancy new ASCII-SGML-etc-text standard or not.
Damn, talk about progress.
.library to .so/.dll, finally.
I'm pretty sure (as in absolutely certain, as in being a developer for this system) that my Amiga 500 did passing-by-register with it's "16-bit" 68000 CPU.
Of course, this "16-bit" processor was really more 32-bit than say, a 386 based design, as it had eight 32-bit data registers, and eight 32-bit address registers which could address a 4GB linear address space.
The OS itself used all pass-by-register interfaces, which used an address register plus offset jumptable calling system that was lightning fast, but you could compile your binaries to also use pass-by-register or the more traditional pass-by-stack system. Pass-by-register programs generally saw a performance increase between 10% and 800%, depending on how function-happy/OS-call-happy they were.
It's nice to see that the rest of the industry it's finally catching up. Datatypes to Codecs, register to register,
Strikes me that mainstream progress is really just re-implementing old ideas from non-mainstream sources.
PS. Just a little note to those who thought your ISA didn't matter (ISA as in instruction set architecture, not as in that nasty crappy IBM bus), I say, "Ha!"
Actually, the new process might take less energy to switch states than current processes, (higher efficiency) thusly creating less heat. CMOS chips, for instance, ran cooler than NMOS equivalents, as I recall.
---
And in reply to the parent of the parent of this post, I do own at least four production-scale, original stock computers, which have no fans and run pretty much cool. A Commodore 128, Amiga 500 (x2) and Amiga 1200. None of these machines have any moving parts in their stock configuration save the floppy drives, which normally don't move except during loading. They neither have nor require any fans, not even in the power supplies.
That was basically the way in the old days. PCs had power supply fans, and many other machines did not. Cocos, Ataris, etc, also did not have fans. Those old Commodore boxes were pretty damned useful too - the 1200 could chat on IRC, compile software in the background, edit source, and surf web pages with only a 4 meg ram upgrade card (total 6 megs - 2 megs shared video/cpu, 4 megs dedicated cpu ram) and a hard drive. Using only 23 watts of power, too. Couple that with a very power misery LCD and you could have a useful little box (well, keyboard, really) for the power of a lightbulb. None of this 600 watt PC nonsense. (Even my more modest 350W PC makes the lights dim slightly when I flick on the switch at the back of the PSU..ow)
> I look after my disks so I don't need to make backups of them
There's been evidence that CD-ROMs, including pressed-at-the-factory variety, can become unglued over time, causing data loss, regardless of how well looked-after they are. You may want to back up your more expensive titles you own.
Isn't PDF some sort of bastardization of Microsoft's .DOC format? IANAPDFE (I am not a PDF expert), but I'm pretty sure I read that somewhere when trying to figure out how to read a PDF using my own code..
Anyhow, yes, that would make the comparison fairer. Or, if there was some way to take MS Office's preloading out.. (I imagine it's more than just that OSA9 thing in the startup folder)
Well, the decrease in monitor depth and reduction of eye-strain while coding is desirable, but I still notice the lack of responsiveness on the 16-20ms models for gaming.
.. Remember that extra pixelage is not only increased data for the 3D engine to render, it also takes a greater toll on memory bandwidth during display.
Also, for many games, a resolution of 800x600 is perfectly adequate (Jedi *, non-railgun Q3, Homeworld series - games where long range doesn't matter) and offers a tremendous speed boost. Some games, such as Halo, are unplayable at resolutions higher than 640x480 with all options off on this crappy GeForce 5200 board (The 4200 died and I quickly grabbed the cheapest off the shelf board I could find; what a disappointment when I found that it was noticibly SLOWER than the 4200 - a 64 meg, high-bandwidth memory model)
(Damn, but I need a new video board. Maybe I'll get an ATI this time..)
I wouldn't want the redhat boot time to get any longer ... it's already like a minute ten on that system.
And I wouldn't use it on Debian as I use the stable tree - great for servers, bad for desktops (KDE 2.2.2 anybody~?)
That, and well, you know, I load these apps pretty infrequently anyways..
> In any event, my own experiences of Word 2000 on Win2000, with P3's is that of 30+ second waits. Simply unacceptable, when forced to use it at work, I'd use notepad instead.
Even on the P3 machine here, it was only in the 5-ish second times (Unofficial~). I wonder if there's a memory issue on those systems; the systems I build are typically over spec when it comes to RAM.
That system was a P3-1000, 512 megs of PC133 SDR, and um.. Win2000 with Word2000 installed. When I install microsoft products I tend to use minimal possible installs and avoid the "install from CD on first use" crap, which may also impact performance.
The increased RAM, minimized installs and such may have significant performance gains, although I suspect they may be somewhat offset by the fact that I prefer smaller, slower hard drives, due to the decrease in cost~
Hmm, maybe I should install Win2000/Word2000 on that machine again, using a spare drive. (it's currently a Debian webserver) It's other performance metrics were actually superior to the P4..
Oh well, office products are all bloated crap anyways. vi/editplus, please.
Eeh you have that all backwards.
.doc files properly ten years from now will be rather difficult, I imagine. That's why I use plain text with soft line wrapping... that hasn't changed much in the 20 years I've been in computing. (Well cept for the line ends, but it's pretty trivial to convert MacAmiga/UnixDOS files)
OO takes 58 seconds to open on my P4 test machine, and word about 4.5 seconds. (Both tests performed after a clean boot; P4 1400mhz, old junker with a 40 gig drive and 256 megs of old SDRAM. OSes are Redhat 8 for OO and Windows 2000 for Word).
I don't have OO on my main system (2500 AthlonXP; 512 megs DDR; slightly more recent 120GB HD) but Word takes about 2.5 seconds on this system to load from a clean boot.
While I think Microsoft is mentioned in the bible ("Agent of the Beast", I believe they said), and I liked certain parts of your post, (the asshattery part is very true on both fronts and I use plain text editors as much as possible) I dislike any distortion of fact, regardless of who the fact may be appealing to.
In any case, reading those
I'll stick with my $150 CDN (something like 200ish euros) 10ms CRT, thank you very much. The fact that it can display multiple resolutions other than "native" is quite appealing, and 450 euros would be enough for me to buy a whole new mobo+CPU+memory combo. and case... and decent PSU.. Actually it's probably significantly faster than 10ms, but that's the effective speed at 100hz. Oh well.
> Another option would have been limited battery life for the flashlight
A mag lasts how long on plain, off-the-shelf alkaline D cells? 8 hours? 10? How much longer if it was some sophisticated led-based system?
That was one thing that pissed me off a lot in Halo - you have a micro-sized fusion reactor on your back that provides enough power for a suit of power armor that can flip a main battle tank over, as well as generate a shield strong enough to deflect plasma fire.. and your flashlight, about as bright as a three cell mag light light, runs out of batteries in five minutes.. (and it does recharge from the pack, too) Dammit!!
(And the damned marines have lights that last for the whole mission)
Anyways, a nice bright six cell mag with an upgraded bulb would quite easily blind some sort of creature with excellent night vision.. unless the system it uses for sight is more flexible than a human's, of course.
I find it sort of interesting that people seem to lump software into two very generalized categories:
- Secure OSS/Free software
- Insecure, buggy, proprietary Microsoft software.
What happened to non-Microsoft proprietary software? While you don't have the OSS and Free benefits with other proprietary vendors, they tend to be a lot better than our old friend Bill.
Eudora and Opera, for instance, are much better than Outbreak (heh, that's a good one, and approriate too) and IE in terms of stability and security.
1) Integrated motherboards consolidating most functions into a few chips with the Apple ][,
Eh, most old 8-bit systems did that. Back in the 80s microcomputer wars, the IBM croud always maintained that integrated designs were un-upgradable and therefore inferior. Not that I necessarily agree, but this is a somewhat contended point
2) Plug and Play compatibility with NUBUS,
Is Nubus before or after Zorro-II ? (I honestly don't know but I imagine it's close in either case)
4) First to use small form floppies with the Apple ][c
That was April 84 wasn't it? I believe that's around the same time Atari came up with it's ST system, also based on 3" floppies. the Amiga wasn't far behind in 85 with the same floppies.
5) First to support on board sound and graphics with Macintsoh,
Like a Commodore 64, some three years earlier? And most other microcomputers? Funny that you'd call blitterless monochromatic magic, "graphics".
6) First to include built in networking with Macintosh,
I dunno, my C64 came with a serial port and user port too..
9) First to develop the laptop form factor as we know it with the Powerbook,
My 386 laptop, around the exact same time, is also the same shape as a modern laptop. Come to think of it, my friend's ancient 286 laptop from years before looks just like my 386 laptop, only white instead of gray...
10) First to leverage the GPU for routine interface with OS X,
The Amiga 1000 ('85) used it's GPU (Agnus) for almost everything, including blitting (user accessable API included) and DMA (disk access, etc). Technically it didn't use OS X, though.
11) First speech technology with the Apple ][,
That's cool, but could you copy text files to the voice: device via CLI or GUI to make it read them?
12) First virtual programming environment with Hypercard,
Is that like the 8086 or 80286 bridgeboards that can go into any Zorro-II Amiga, that contain a complete PC?
15) First cross platform standard for multi-media with Quicktime,
What about mpegs?
16) The first "multimedia" PC with the MacTV that integrated a television with stereo CD back in 1993 or so. We could go on and on here, but you get the point.
That was many years after the Commodore CDTV and possibly even after the CDTV's successor, the CD^32. Granted that's not with a built-in TV, but at the rate CRTs blow, having one built-in would be more accurately described as a "design flaw". All of my original C64 stuff, Amiga boxen, and PC boxen have long outlasted the vast majority of my CRTs, save a 12-year-old monovga monitor that I gave to Goodwill last year. Well, technically my Amiga 500 doesn't tell time properly and has some other timing problems due to one of the CIA chips being damaged, but I could drop in a replacement chip for $15.. but aside from that, all the boxes have outlived their CRTs by a wide margin. I imagine the same would be true for LCDs.
> It's a cheap architecture (actually the same idea as the PC-jr video/CPU memory!) but not good for performance at all.
:P
Actually, that's not true. Amiga machines used that to great advantage in the old days, and a P3 with a 133mhz front side bus doesn't have ANY other use for all that bandwidth anyways. Xboxen have RDRAM if I recall correctly, which is way beyond the old non-DDR SDRAM spec that the P3 was designed for. The memory probably gets bored waiting for the CPU.
The upside of unified memory architecture (I do believe that's what SGI called it when they were going all nuts about it) is that the CPU has very, VERY direct access to the video memory, and the GPU has very, VERY direct access to the system memory, as they are one and the same...
Of course, I suppose Xboxen don't have any "Fast RAM" (dedicated, CPU-only, seperate bus RAM) like the old Amigas, but still, it does work well enough for the Xbox.
Of course, Xboxen don't have to worry about things like this article's topic, as they all have a perfectly uniform specification. Kinda handy when you don't have to cater to the P4 Extreme/Athlon64 market at the same time as the 386SX market.
> I'll go off on a tangent here and compare current copy prevention mechanisms to the software copy prevention mechanisms from the eighties. Who remembers things like "off disk copy protection", or disks that were purposely damaged to as to be uncopyable?
I remember this all too well, and it's unfortunately coming back. Many CD based games use copy protection techniques to encode marginally readable bits and such, and look for these bits as coming back randomly on successive reads. This makes the game impossible to copy without modifying the executable to skip over this protection, as well as requiring the CD in the drive to play. So much for backing up my software! I'm of the mind that such games should come with two or three copies of the CD, all in their own seperate jewel case, for backup purposes. (The hilarious thing is that the pirates have already created solutions for these schemes, it only really stops legit users from making backups at the end of the day)
> I'm not going to be ignorant about the problem of piracy by claiming it's not a problem at all, it's the methods of preventing it I question...
Actually, I have a suspicion that most pirates wouldn't buy if they couldn't copy anyways. They'd just go without or tape from the radio, I bet.
Then, there's always that patch cable from the CD player to the Mic In jack on the back of the machine, plus the old sneaker net....
> Meanwhile over in Windows Land, Joe sixpack can't even load the program because he has about 10% resources free
The NT-series windows (NT, 2K, XP) use automatically extending resource stacks. That issue is a thing of the past.
Of course, there are still many outstanding issues such as registry rot, badly written drivers, useless new security holes, err, features, etc...
"Then, I realized that I had just assumed all other people are like me: wanting to do their best job at coding and make sure it's code that will work and be maintainable for years to come"
When I first started my most recent job, I had a vision like this also. Then I discovered our log downloading was a blind shell script. With no detection for either missing logs or half-downloaded logs. Then I discovered that the PREVIOUS iteration was ALSO a shell script, only in a slightly different style (but still hard-coded addresses and such). Then I discovered the system BEFORE that was a series of RSH commands, also blind, also hardcoded, AND completely replaced for no reason whatsoever.
I was horrified. It was awful. Totally against everything I believed in. My job was cut out for me: The hours of checking for missing junk had to go!
I implemented over a few days a Perl-based downloader that had the following features:
- "+EOF" check to determine that the whole log was downloaded (a simple change to the webservers' rotate logs script)
- Additional checks to see that the download command didn't abort with an unusual error level
- Basic download throttling. It's a lot faster downloading 6 logs at once rather than 384 at once.
- Easily updated text configuration file (never made the CGI to administrate that, but it was dead easy in VI anyways)
- Descriptive variable names and clear processi within the script
- External documentation which included justification for all features employed as well as explanations of optimizations and whatnot
- Detection of changes to the domain names for the websites that may indicate that additional servers were added (or removed) from a given domain
- Support for multiple download protocols (SSH and FTP implemented initially)
- Support for a "download caching" area, as the hardware of the time was a big, faulty raid array that topped out at 250k/sec effective write speed (adding a 36G drive to download one day's of logs helped tremendously, and the logs could then be gzip-piped over to the dog slow raid at a reasonable rate (2.5 megs/sec effective with gzip))
To make a long story short, this system was everything the predecessors' systems were not: Elegant, extendable, maintainable, documented, fast, but (leaving out the configuration file) short. I no longer had to hunt for hours to find missing logs or run manual checks and harass system administrators to figure out if any hosts had been added/removed from domains, etc. Everything ran smoothly, and I had little to do but sit, relax, and try not to laugh at management's horrible new ideas. Any inebriated monkey could manage the new, improved system.
Unfortunately, as I was no longer critical to the operation, and an inebriated monkey was a bit cheaper than my paycheque, management gave me the old heave-ho.
I guess the previous maintainers who wrote poorly maintainable, useless code knew something I didn't.. doh!
The difference, a small but important one, is that Rockstar isn't shoving copies of GTA through your mail slot or emailing it to you..
I could care less about penis pumps, sex toys, porn, and generic viagra, but I DO mind people clogging my email server..
Nobody's forcing you to buy GTA. The spammers ARE, however, forcing you to download and sort through dozens of emails every day. Let them buy banner ads and billboards instead, just not on my penny!
Ew imperial measure ;-P
Actually 365.25 days per year doesn't take into account the extended rules for leap years.
Remember:
+ Every 4th year is a leapyear
- Unless it's evenly divisible by 100.
- UNLESS that is evenly divisible by 400.
Thus the year 1988 is a leap year (every 4th), but 1900 is not, but 2000 IS.
(2000 is divisible by 4, 100 and 400, 1900 is divisible by 4 and 100, and 1988 by 4 only, er, that is, in a remainderless fashion)
Thus I think a year is in fact.. um.. well something like 365.2425, er, I think.
> I just wish IFF had survived the death of the Amiga as a mainstream platform.
:P (Nonsense because data alignment is pretty darn well meaningless on disk unless you're talking about 512-byte alignment :P)
Actually in many ways it did; PNG and FLACC and such tend to use an IFF-like structure, and indeed, PNG credits IFF in the documentation. I've noticed that the graphics programs I work with (Photoshop 4, Paint Shop Pro 6) tend to have 'iff' in their Export lists. New ones may not support IFF, but at least those two did.
IFF would have done even better though, if it had had better, more official support for things like "chunky" (byte-oriented rather than bitplane-oriented) graphics, 15, 16, and 24 bit modes, etc.
Heck, you could lay out a spec for ILB\1 (ILBM next generation) and support all these things. IFF exists as a concept as well as a specification, and can be adapted. The only downside to doing this is that I think the "2-byte align" nonsense is part of the IFF spec. It's almost as bad as that "4-byte" row-align crap in windows and os/2 "bmp" format.
Anyways, I think I'll get out my RKRM: Libs book and see about drafting a spec for some of my own programming projects. If there's that 2-byte nonsense, I may very well lay down an IFF\2 spec or something