I don't know how the Atari 800 compared to the Commodore 64
The Atari 800 beat the C64 hands down when it came to color palette. The Atari had a standard palette of 128 colors while the C64 had only 16 colors. And while both systems had a total of 8 sprites, half of them on the Atari were crippled. All 8 on the C64 were fully versatile.
If you used horizontal screen resolutions of 160px, both were limited to about 4 simultaneous colors. But the Atari included a 80px horizontal screen resolution that could display 16 simultaneous colors. On the Atari, you could change those colors every scanline, while on the Commodore you could set it for each 4×8 pixel block (or 8×8 block in hi-res mode).
This image is what mode 9 looked like on an Atari. You might have been able to do something similar with the Commodore 16 and Plus/4 which had a 121 color palette, but those machines never saw widespread adoption. It wasn't until the Amiga that Commodore had something that could best it.
Re:I always like to point out that
on
Atari Turns 40 Today
·
· Score: 3, Interesting
Agreed. The Atari 2600 was an incredibly memory restricted device. It was perhaps its greatest fault. I've done some programming for the 2600 and it is a very difficult system to develop software for because of it.
I can only imagine what the platform would have been like if they had included 512 bytes of memory (zero page plus stack) instead of the stock 128 bytes included in the MOS Technologies RIOT chip. Having all 13 address lines of the CPU going to the cartridge slot would have also made a huge difference. Bank switching around the ROM when it is larger than 4KB really sucks.
Heck, I wonder what things would have been like if MOS Technologies would have released a 28-pin package 650x variant that multiplexed the address and data bus to expose all 16 address lines. With the latch pin, you'd only need to dump one signal line (or the phase2 clock line) from the 6502. Heck, it could have replaced ever other 28-pin variant in the 650x series.
Annoy enough people with the OS and you're going to get people to install alternative shells
Last I checked, new releases of Directory Opus were still being released. I had no problem replacing Workbench back in the day. I'd have no problem doing it with Explorer tomorrow if Microsoft doesn't fix their UI mess.
Recently we put some higher-end drives in our servers and we love the hell out of them.
There have been a couple of reports that just came out that suggest that SSDs can pay for themselves in many server environments. It isn't just the power savings (remember that non-residential customers often get charged more per kWh), but that many servers are often disk I/O bound. When you replace spinning platter drives with SSDs, you might be able to cut your server count in half. Admins have found that they can completely eliminate caching web servers because the app servers can crank out so much.
They don't change stuff every month, but they change everything on a new version.
False. Not every bump of a Windows kernel version eliminates backwards compatibility with an older video driver. Generally speaking, neighboring versions of the same series can utilize the older OS video driver on the newer OS. I can personally confirm getting Win95 drivers to work on Win98, Windows NT4 drivers to work on Win2K (NT5) and Vista (NT6) drivers to work on Win7 (NT6.1).
Try to use a windows ME display driver on windows 7
WinME was part of the 9x series. Win7 is part of the NT6 series. NT and 9x never shared a common kernel interface for anything. They were two completely different operating systems that shared a common API (Win32/WinAPI).
But they don't complain because that is how windows is
They don't complain because the 9x series was phased out over a decade ago. The only major change to the kernel driver interface since then came with Vista. And when that change was proposed, they worked with partners far in advance.
Can I take a video driver for kernel 2.0.37 and get it to build easily with kernel 3.2.18?
At a minimum, it places an extra burden on other kernel developers, unless those changes are being made in common header files that propagate out with each new build. At most, you're playing a game of chicken with a major partner who could dump all support of your kernel and back a competing free Unix-like OS.
Every time the kernel changes, the video driver must be updated.
I see that as a problem with the kernel developers, not the video driver developers.
I've read elsewhere that developers from Nvidia are frustrated over the volatility of the Linux kernel interface to the graphics subsystem. It changes frequently and often with little advanced notification. You don't hear that complaint about Windows, MacOS or FreeBSD.
Commodore could perhaps have had a cheap 030 machine ready for early 1994 with a decent port of Doom
Maybe. But Commodore had entered a joint venture with HP to use PA-7100 processors by that point. Entry level machines might have used a PA-7100/33 rather than a MC68030/25.
If you're going to get Doom on the Amiga I think you need to go back as far as 1986
I think you need to go back a few more years than that. Commodore might have done better had their board of directors ousted Tramel and his sons earlier than they did. Tramel's business strategy of selling deeply discounted low-end computers kept it out of the much more lucrative business computer market. It also resulted in a number of home computers that had no market. An earlier ouster might have also prevented him from spinning up Atari after Warner dumped it, lessening the fragmentation of the home market with the Atari ST.
I mean, imagine if Commodore had released the Commodore 900 in 1982 instead of the CBM-II series. Things might have been very, very different.
As far as CPU goes, any 020 is likely too slow... a 16MHz 030 is better, but is still slower than the 25MHz minimum requirement of PC Doom
True, but I don't see Commodore releasing a 68EC030/25 as their entry level processor in 1992. Even over at Apple where Gassée was busy pushing high-end systems, they still released the Mac LC with only a 68020/16.
I guess a good question to ask is how much more would it cost to have produced an A1200 with a 68EC030/16 versus a 68EC020/16. More expensive chip and socket, an extra eight memory bus lines on the motherboard and so on. Also, would they have run it at its native 16MHz like in the A3000 or a NTSC colorsync multiple of 14.32MHz.
The problem C= had with producing the chipsets, etc, was almost 100% politics.
I see two surprising things. First, that the board of directors would have allowed Sydnes to kill the A3000+ project without anything else in the pipeline. Second, that Commodore was so seriously decentralized. For a company as small as Commodore, you'd think that board of directors would have been more involved in calling the shots.
I'm NOT surprised by the price constraints with the A4000. Commodore was never able to shake Tramiel's mantra of "for the masses, not the classes". It is rather sad that we didn't have an A3000p-derived 68040 AGA system. It would have still been significantly cheaper than the [68040 equipped] Mac Quadra 700, Mac Quadra 900 or the [SuperSparc equipped] SparcStation S10. They could still have had the A1200 to match the Macintosh LC. Too bad they didn't include an EC020/20 option in addition to the EC020/14.
Running Doom on a stock Amiga 1200 would be a painful experience
I agree. There was just too much overhead doing chunky to planar conversion. Even with the CD32 and its Akiko chip where you could do the conversion in hardware, the results were mediocre at best.
The question is, what was the choke point? The MC68EC020/14, the Akiko or the AGA chipset? Would the stock 020/14 have been enough if AGA included an 8-bit chunky mode, or would an 020/20 or 030/16 been needed?
The point I'm making is that the Amiga, in the early nineties, just wasn't something you bought for the hardware
Yes and no. The Amiga 3000 and Amiga 4000 were the cheapest 68040 workstations at the time. Amiga Unix (System V Release 4) and NetBSD could be loaded onto them, making them more cost effective than anything from Sun.
The problem was that the rest of the system was suffering. The Enhanced Chipset (ECS) was little more than an incremental upgrade of the Original Chipset (OCS). It should have looked more like the Advanced Architecture (AA/AGA) that came out in '92.
Commodore was just never able to smoothly move their architectures forward. They had the same problem back in the 8-bit days. But with the Amiga, it sounds as if they'd start designing a new chipset only to backtrack and then release some quick fix as a stop-gap. I'm curious if they were bad at estimating fabrication and support chip costs or if they were bad at coming up with a target price and sticking with it. I mean, near the end you had AAA then AA/AGA then AA+ and lastly Hombre. Sounds very chaotic.
At the time, the Amiga had a very good blend of processor, graphics and audio performance tied together with a multitasking OS (rare at the time) for a reasonable price. But the OS was admired because it had a very small footprint and was very fast. It was also easy to use.
The only major benefit you'd get out of it today is that it is incredibly lightweight. But that is because it uses a very simple memory management subsystem. There are a lot of benefits of using a more complex memory subsystem, which is why the one used by the Amiga has been abandoned outside of all but the most basic embedded systems.
One feature that would have been nice to bring to a modern OS was the datatype system. It was essentially a universal codec subsystem that could handle not only the different encoding systems (codecs), but the containers as well. And it wasn't limited to video - it could also handle audio, text and images. The closest thing Windows has today is the ffdshow codec package for the DirectShow subsystem.
Define "custom hardware". Not even the game consoles really use specialty custom hardware anymore, and they were the last class of home systems to really do so. Now they just use tweaked versions of commodity hardware. These days, you have to look at big iron and mainframe systems to really find custom in-house designed hardware.
I'm not saying that it couldn't be done, but it really wouldn't be worth the cost. Heck, look at AMD who just licensed an ARM core so that they can get the Trusted Computing subsystem into their x86-64 processors. It was simply cheaper to license something else.
3 seperate people in the first 2 pages decrying AmigaOS on x86 and how PPC hardware makes it 'special'.
An 8-core POWER7 processor is special. Most everything these days from the PowerPC series is not.
Had Commodore actually released a PPC based Amiga themselves, then there might have been a real connection between the PPC and the Amiga. But Commodore folded before they could transition off of the 680x0. So all we have are a few third party PPC processor cards and a couple hobbyist companies tinkering with it after it fell from mainstream status.
To me, I think a lot of people had wishful thinking of what could have been had Commodore followed Apple down the PPC rabbit hole. That is why they're so hung up on it. But for most people, the Amiga died when it was a 680x0 machine running 3.x.
Ten years ago I might have agreed. Today with every major desktop OS running on x86 or x86-64, not so much. Besides, people are more interested in the Amiga experience as opposed to the underlying hardware. This goes double since the majority of PPC systems in the post-Commodore world have been something of an expensive joke.
According to the article, they say that infected machines will respond to NetBIOS name queries for Windows Update servers. That strikes me as odd. Don't you have to enable NetBIOS for DNS resolution in the Windows NT series? And aren't traditional BIND name servers a higher protocol bind order by default?
I thought I had read elsewhere that the problem was actually due to the insecurity of having "Automatically detect [proxy] settings" enabled for IE. When Windows Update fires off, it checks for the default proxy server on the subnet and an infected machine responds. If that's true, then we either need to move to a model where auto-discovery of proxy servers is disabled by default or that clients won't trust proxy servers without it having a trusted cert issued by a local authority.
Right on. It is not just about the content itself, but also about how that content is obtained. For some people, the latter is just as important as the former. With studios often playing games regarding delivery, it is no wonder that a sizable group becomes irritated enough to turn to piracy. It is just a heck of a lot easier.
In the studios' defense, it is their content. They get to set the rules if you want to watch it. Nobody will die if they miss their favorite program. Having said that, we live in a world where rules are often bent and broken. It is a fact of life. The studios need to take that into account when they create their rules.
The second article mentioned staggered release dates on a per-country basis as a source of irritation for impatient customers. Some people just can't wait, while others take offense to being second or third in line. Multiple publications have recommended against the practice, correctly saying that it is a motivator for piracy. Yet the studios continue to do it.
Another practice is to give a single rental firm an exclusive contract, either for a limited time or in perpetuity. If I'm subscribed to streaming service X but the film went exclusively to streaming service Y, I might be motivated to pirate. Same deal if I live near brick and mortar store A but instead the film went to store B which is some distance away. I'm sure that piracy of films distributed by Starz has recently jumped due to their contract issues with Netflix.
Then there is the content itself. For some time, rentals from a local brick and mortar store where failing to play on my Toshiba DVD player because it was incompatible with the ARccOS protection system. I had to rip the discs and then burn them onto DVD±R in order to watch them on my main television. Why are the studios deviating from existing optical disc standards? The good part was that I was able to omit all of the non-skippable trailers and warnings. When I have to sit through 15 minutes of ads because track skipping and fast forwarding are blocked as a NOP, you just gave me 15 minutes of incentive to pirate.
It isn't just enough to provide a legal service. When that service is degraded or difficult to access, people will pirate. Studios are failing to abide by the KISS standard (keep it simple, stupid). The problem is that studios are going to legislators and saying "we're providing legal avenues, but people still pirate". Legislators either never hear about or fail to care if those avenues are substandard. Legal is legal. That is a big problem because it fails to motivate content providers to drop the games and improve the experience of their product.
I'm just the opposite. By obtaining music through alternative channels, my CD collection eventually quadrupled in size (now over 300 discs).
One benefit was that I was exposed to a huge number of artists who receive little to no airplay by traditional terrestrial radio broadcasting. I'm not a fan of the soulless generic music that dominates most of the airwaves, so this was a very significant thing for me. When I discovered a new group I really liked, I'd go hit up an online retailer. Their recommendation system would then steer me towards other similar artists I had barely heard of. I'd then go back to the well to grab some of their music. Rinse and repeat.
Another benefit was identification. There used to be a huge number of songs from the '70s - '90s I really liked, but never knew their name. Thanks to an ID tag on a digital music file, I now knew the name of the artist and song and could go buy the album through a retailer. No more mistaking the music of one artist for another.
As online retailers have moved away from 20 second 32kbps previews to song clips of longer duration and better quality, it is just getting easier to use their sites to preview. But nothing beats the convenience of those alternative channels.
Except that the IBM PS/2 came with a VGA video adapter. It could display 256 colors from a 65K color palette; the Amiga could only display 32 colors from a 4096 color palette. The extra half-bright (EHB) mode still used a 32 entry CLUT... it generated colors 32-63 by halving the luma intensity of colors 0-31; it wasn't a true 6bpp color mode. And the hold-and-modify (HAM) mode used differential values to calculate color; subsequent pixels had a limited color range as you could only jump so far in the color palette from one pixel to the next. Sure, you could use unique CLUTs for each scanline to increase the number of on-screen colors, but it required a great deal of processor power to calculate on the fly. That's why it was mostly limited to static images (just as it was on the Apple IIgs that could do a similar trick).
And while the Denise could thump any PC audio chipset in the 1980s, it was not near CD quality. The highest sample rate was only 28KHz with 8 bits of resolution. CDA has a sample rate of 44.1KHz with 16 bits of resolution. Sure, you could use the 6-bit volume control register to create additional quantization steps, but you sacrificed two audio channels to do it. And 12 bits of resolution was a theoretical maximum; real world resolutions were smaller, especially as samples got louder. And again, it required a great deal of processor power to calculate on the fly
Lastly, you could install Coherent-386 on an IBM PS/2. True multitasking along with memory protection and multi-user support. You also had Concurrent CP/M-286 and -386 editions. They weren't popular, but they were available. And if you really want to split hairs, OS-9 was one of the first preemptive multitasking operating systems for consumer computers (read: not mainframes or minicomputers).
I'd say that it was less about friendship and more about mutual reliance. Apple needed Microsoft's productivity software. Microsoft needed a strong opponent in the marketplace to avoid government scrutiny regarding its monopoly status.
I agree. I think that the huge influx of laypersons onto the Internet has been both a blessing and a curse. On the one hand, having more people of all social, economic and education backgrounds has encouraged a more rounded environment. It has allowed websites to flourish which otherwise may have been little more than a niche sites back when it was mostly university geeks and researchers. But on the other, we have a subset of people who are more open to scams, who place a larger burden on support resources and who are unable to deal with issues such as compromised computers infected with Trojan horses.
But the bigger and darker issue is that the Internet is much more about user feedback than at any time before. It is a place where every voice and opinion can receive an equal audience. What happens when you have millions of uneducated riff-raff joining in the conversation, especially when the topic is political in nature? It often drags the quality of the conversation down. You end up with people parroting their worldviews rather than thinking about the subject at hand. Unless that environment is heavily moderated, it will end up sullied.
As to the groups of people who are underrepresented on the Internet, I'm relieved that is the case. While some of them may begin to change their worldviews from being exposed to more ideas, I think the benefit to society would be greatly outweighed by the damage such people would cause. But the genie is already out of the bottle. Costs will continue to drop and more services will simply require Internet access in order to procure them. Internet penetration will continue to climb. I think that it is inevitable that everyone will have access, and we as a society will just have to adapt to it, for better or worse.
Slashdot Mirror
I don't see a problem with this. Having a diverse immigrant workforce is a good thing. No single country should dominate our immigration system.
I don't know how the Atari 800 compared to the Commodore 64
The Atari 800 beat the C64 hands down when it came to color palette. The Atari had a standard palette of 128 colors while the C64 had only 16 colors. And while both systems had a total of 8 sprites, half of them on the Atari were crippled. All 8 on the C64 were fully versatile.
If you used horizontal screen resolutions of 160px, both were limited to about 4 simultaneous colors. But the Atari included a 80px horizontal screen resolution that could display 16 simultaneous colors. On the Atari, you could change those colors every scanline, while on the Commodore you could set it for each 4×8 pixel block (or 8×8 block in hi-res mode).
This image is what mode 9 looked like on an Atari. You might have been able to do something similar with the Commodore 16 and Plus/4 which had a 121 color palette, but those machines never saw widespread adoption. It wasn't until the Amiga that Commodore had something that could best it.
Agreed. The Atari 2600 was an incredibly memory restricted device. It was perhaps its greatest fault. I've done some programming for the 2600 and it is a very difficult system to develop software for because of it.
I can only imagine what the platform would have been like if they had included 512 bytes of memory (zero page plus stack) instead of the stock 128 bytes included in the MOS Technologies RIOT chip. Having all 13 address lines of the CPU going to the cartridge slot would have also made a huge difference. Bank switching around the ROM when it is larger than 4KB really sucks.
Heck, I wonder what things would have been like if MOS Technologies would have released a 28-pin package 650x variant that multiplexed the address and data bus to expose all 16 address lines. With the latch pin, you'd only need to dump one signal line (or the phase2 clock line) from the 6502. Heck, it could have replaced ever other 28-pin variant in the 650x series.
Annoy enough people with the OS and you're going to get people to install alternative shells
Last I checked, new releases of Directory Opus were still being released. I had no problem replacing Workbench back in the day. I'd have no problem doing it with Explorer tomorrow if Microsoft doesn't fix their UI mess.
Recently we put some higher-end drives in our servers and we love the hell out of them.
There have been a couple of reports that just came out that suggest that SSDs can pay for themselves in many server environments. It isn't just the power savings (remember that non-residential customers often get charged more per kWh), but that many servers are often disk I/O bound. When you replace spinning platter drives with SSDs, you might be able to cut your server count in half. Admins have found that they can completely eliminate caching web servers because the app servers can crank out so much.
They don't change stuff every month, but they change everything on a new version.
False. Not every bump of a Windows kernel version eliminates backwards compatibility with an older video driver. Generally speaking, neighboring versions of the same series can utilize the older OS video driver on the newer OS. I can personally confirm getting Win95 drivers to work on Win98, Windows NT4 drivers to work on Win2K (NT5) and Vista (NT6) drivers to work on Win7 (NT6.1).
Try to use a windows ME display driver on windows 7
WinME was part of the 9x series. Win7 is part of the NT6 series. NT and 9x never shared a common kernel interface for anything. They were two completely different operating systems that shared a common API (Win32/WinAPI).
But they don't complain because that is how windows is
They don't complain because the 9x series was phased out over a decade ago. The only major change to the kernel driver interface since then came with Vista. And when that change was proposed, they worked with partners far in advance.
Can I take a video driver for kernel 2.0.37 and get it to build easily with kernel 3.2.18?
At a minimum, it places an extra burden on other kernel developers, unless those changes are being made in common header files that propagate out with each new build. At most, you're playing a game of chicken with a major partner who could dump all support of your kernel and back a competing free Unix-like OS.
Then you can bathe in your self-righteousness with Nouveau on Linux while I enjoy Nvidia's latest binary blob over on FreeBSD.
Every time the kernel changes, the video driver must be updated.
I see that as a problem with the kernel developers, not the video driver developers.
I've read elsewhere that developers from Nvidia are frustrated over the volatility of the Linux kernel interface to the graphics subsystem. It changes frequently and often with little advanced notification. You don't hear that complaint about Windows, MacOS or FreeBSD.
Perhaps your ire is aimed at the wrong group.
Commodore could perhaps have had a cheap 030 machine ready for early 1994 with a decent port of Doom
Maybe. But Commodore had entered a joint venture with HP to use PA-7100 processors by that point. Entry level machines might have used a PA-7100/33 rather than a MC68030/25.
If you're going to get Doom on the Amiga I think you need to go back as far as 1986
I think you need to go back a few more years than that. Commodore might have done better had their board of directors ousted Tramel and his sons earlier than they did. Tramel's business strategy of selling deeply discounted low-end computers kept it out of the much more lucrative business computer market. It also resulted in a number of home computers that had no market. An earlier ouster might have also prevented him from spinning up Atari after Warner dumped it, lessening the fragmentation of the home market with the Atari ST.
I mean, imagine if Commodore had released the Commodore 900 in 1982 instead of the CBM-II series. Things might have been very, very different.
As far as CPU goes, any 020 is likely too slow ... a 16MHz 030 is better, but is still slower than the 25MHz minimum requirement of PC Doom
True, but I don't see Commodore releasing a 68EC030/25 as their entry level processor in 1992. Even over at Apple where Gassée was busy pushing high-end systems, they still released the Mac LC with only a 68020/16.
I guess a good question to ask is how much more would it cost to have produced an A1200 with a 68EC030/16 versus a 68EC020/16. More expensive chip and socket, an extra eight memory bus lines on the motherboard and so on. Also, would they have run it at its native 16MHz like in the A3000 or a NTSC colorsync multiple of 14.32MHz.
The problem C= had with producing the chipsets, etc, was almost 100% politics.
I see two surprising things. First, that the board of directors would have allowed Sydnes to kill the A3000+ project without anything else in the pipeline. Second, that Commodore was so seriously decentralized. For a company as small as Commodore, you'd think that board of directors would have been more involved in calling the shots.
I'm NOT surprised by the price constraints with the A4000. Commodore was never able to shake Tramiel's mantra of "for the masses, not the classes". It is rather sad that we didn't have an A3000p-derived 68040 AGA system. It would have still been significantly cheaper than the [68040 equipped] Mac Quadra 700, Mac Quadra 900 or the [SuperSparc equipped] SparcStation S10. They could still have had the A1200 to match the Macintosh LC. Too bad they didn't include an EC020/20 option in addition to the EC020/14.
Running Doom on a stock Amiga 1200 would be a painful experience
I agree. There was just too much overhead doing chunky to planar conversion. Even with the CD32 and its Akiko chip where you could do the conversion in hardware, the results were mediocre at best.
The question is, what was the choke point? The MC68EC020/14, the Akiko or the AGA chipset? Would the stock 020/14 have been enough if AGA included an 8-bit chunky mode, or would an 020/20 or 030/16 been needed?
Yes, with the Hombre system that they were co-designing with HP.
The point I'm making is that the Amiga, in the early nineties, just wasn't something you bought for the hardware
Yes and no. The Amiga 3000 and Amiga 4000 were the cheapest 68040 workstations at the time. Amiga Unix (System V Release 4) and NetBSD could be loaded onto them, making them more cost effective than anything from Sun.
The problem was that the rest of the system was suffering. The Enhanced Chipset (ECS) was little more than an incremental upgrade of the Original Chipset (OCS). It should have looked more like the Advanced Architecture (AA/AGA) that came out in '92.
Commodore was just never able to smoothly move their architectures forward. They had the same problem back in the 8-bit days. But with the Amiga, it sounds as if they'd start designing a new chipset only to backtrack and then release some quick fix as a stop-gap. I'm curious if they were bad at estimating fabrication and support chip costs or if they were bad at coming up with a target price and sticking with it. I mean, near the end you had AAA then AA/AGA then AA+ and lastly Hombre. Sounds very chaotic.
At the time, the Amiga had a very good blend of processor, graphics and audio performance tied together with a multitasking OS (rare at the time) for a reasonable price. But the OS was admired because it had a very small footprint and was very fast. It was also easy to use.
The only major benefit you'd get out of it today is that it is incredibly lightweight. But that is because it uses a very simple memory management subsystem. There are a lot of benefits of using a more complex memory subsystem, which is why the one used by the Amiga has been abandoned outside of all but the most basic embedded systems.
One feature that would have been nice to bring to a modern OS was the datatype system. It was essentially a universal codec subsystem that could handle not only the different encoding systems (codecs), but the containers as well. And it wasn't limited to video - it could also handle audio, text and images. The closest thing Windows has today is the ffdshow codec package for the DirectShow subsystem.
Define "custom hardware". Not even the game consoles really use specialty custom hardware anymore, and they were the last class of home systems to really do so. Now they just use tweaked versions of commodity hardware. These days, you have to look at big iron and mainframe systems to really find custom in-house designed hardware.
I'm not saying that it couldn't be done, but it really wouldn't be worth the cost. Heck, look at AMD who just licensed an ARM core so that they can get the Trusted Computing subsystem into their x86-64 processors. It was simply cheaper to license something else.
3 seperate people in the first 2 pages decrying AmigaOS on x86 and how PPC hardware makes it 'special'.
An 8-core POWER7 processor is special. Most everything these days from the PowerPC series is not.
Had Commodore actually released a PPC based Amiga themselves, then there might have been a real connection between the PPC and the Amiga. But Commodore folded before they could transition off of the 680x0. So all we have are a few third party PPC processor cards and a couple hobbyist companies tinkering with it after it fell from mainstream status.
To me, I think a lot of people had wishful thinking of what could have been had Commodore followed Apple down the PPC rabbit hole. That is why they're so hung up on it. But for most people, the Amiga died when it was a 680x0 machine running 3.x.
Ten years ago I might have agreed. Today with every major desktop OS running on x86 or x86-64, not so much. Besides, people are more interested in the Amiga experience as opposed to the underlying hardware. This goes double since the majority of PPC systems in the post-Commodore world have been something of an expensive joke.
According to the article, they say that infected machines will respond to NetBIOS name queries for Windows Update servers. That strikes me as odd. Don't you have to enable NetBIOS for DNS resolution in the Windows NT series? And aren't traditional BIND name servers a higher protocol bind order by default?
I thought I had read elsewhere that the problem was actually due to the insecurity of having "Automatically detect [proxy] settings" enabled for IE. When Windows Update fires off, it checks for the default proxy server on the subnet and an infected machine responds. If that's true, then we either need to move to a model where auto-discovery of proxy servers is disabled by default or that clients won't trust proxy servers without it having a trusted cert issued by a local authority.
Right on. It is not just about the content itself, but also about how that content is obtained. For some people, the latter is just as important as the former. With studios often playing games regarding delivery, it is no wonder that a sizable group becomes irritated enough to turn to piracy. It is just a heck of a lot easier.
In the studios' defense, it is their content. They get to set the rules if you want to watch it. Nobody will die if they miss their favorite program. Having said that, we live in a world where rules are often bent and broken. It is a fact of life. The studios need to take that into account when they create their rules.
The second article mentioned staggered release dates on a per-country basis as a source of irritation for impatient customers. Some people just can't wait, while others take offense to being second or third in line. Multiple publications have recommended against the practice, correctly saying that it is a motivator for piracy. Yet the studios continue to do it.
Another practice is to give a single rental firm an exclusive contract, either for a limited time or in perpetuity. If I'm subscribed to streaming service X but the film went exclusively to streaming service Y, I might be motivated to pirate. Same deal if I live near brick and mortar store A but instead the film went to store B which is some distance away. I'm sure that piracy of films distributed by Starz has recently jumped due to their contract issues with Netflix.
Then there is the content itself. For some time, rentals from a local brick and mortar store where failing to play on my Toshiba DVD player because it was incompatible with the ARccOS protection system. I had to rip the discs and then burn them onto DVD±R in order to watch them on my main television. Why are the studios deviating from existing optical disc standards? The good part was that I was able to omit all of the non-skippable trailers and warnings. When I have to sit through 15 minutes of ads because track skipping and fast forwarding are blocked as a NOP, you just gave me 15 minutes of incentive to pirate.
It isn't just enough to provide a legal service. When that service is degraded or difficult to access, people will pirate. Studios are failing to abide by the KISS standard (keep it simple, stupid). The problem is that studios are going to legislators and saying "we're providing legal avenues, but people still pirate". Legislators either never hear about or fail to care if those avenues are substandard. Legal is legal. That is a big problem because it fails to motivate content providers to drop the games and improve the experience of their product.
I'm just the opposite. By obtaining music through alternative channels, my CD collection eventually quadrupled in size (now over 300 discs).
One benefit was that I was exposed to a huge number of artists who receive little to no airplay by traditional terrestrial radio broadcasting. I'm not a fan of the soulless generic music that dominates most of the airwaves, so this was a very significant thing for me. When I discovered a new group I really liked, I'd go hit up an online retailer. Their recommendation system would then steer me towards other similar artists I had barely heard of. I'd then go back to the well to grab some of their music. Rinse and repeat.
Another benefit was identification. There used to be a huge number of songs from the '70s - '90s I really liked, but never knew their name. Thanks to an ID tag on a digital music file, I now knew the name of the artist and song and could go buy the album through a retailer. No more mistaking the music of one artist for another.
As online retailers have moved away from 20 second 32kbps previews to song clips of longer duration and better quality, it is just getting easier to use their sites to preview. But nothing beats the convenience of those alternative channels.
Except that the IBM PS/2 came with a VGA video adapter. It could display 256 colors from a 65K color palette; the Amiga could only display 32 colors from a 4096 color palette. The extra half-bright (EHB) mode still used a 32 entry CLUT... it generated colors 32-63 by halving the luma intensity of colors 0-31; it wasn't a true 6bpp color mode. And the hold-and-modify (HAM) mode used differential values to calculate color; subsequent pixels had a limited color range as you could only jump so far in the color palette from one pixel to the next. Sure, you could use unique CLUTs for each scanline to increase the number of on-screen colors, but it required a great deal of processor power to calculate on the fly. That's why it was mostly limited to static images (just as it was on the Apple IIgs that could do a similar trick).
And while the Denise could thump any PC audio chipset in the 1980s, it was not near CD quality. The highest sample rate was only 28KHz with 8 bits of resolution. CDA has a sample rate of 44.1KHz with 16 bits of resolution. Sure, you could use the 6-bit volume control register to create additional quantization steps, but you sacrificed two audio channels to do it. And 12 bits of resolution was a theoretical maximum; real world resolutions were smaller, especially as samples got louder. And again, it required a great deal of processor power to calculate on the fly
Lastly, you could install Coherent-386 on an IBM PS/2. True multitasking along with memory protection and multi-user support. You also had Concurrent CP/M-286 and -386 editions. They weren't popular, but they were available. And if you really want to split hairs, OS-9 was one of the first preemptive multitasking operating systems for consumer computers (read: not mainframes or minicomputers).
I'd say that it was less about friendship and more about mutual reliance. Apple needed Microsoft's productivity software. Microsoft needed a strong opponent in the marketplace to avoid government scrutiny regarding its monopoly status.
I agree. I think that the huge influx of laypersons onto the Internet has been both a blessing and a curse. On the one hand, having more people of all social, economic and education backgrounds has encouraged a more rounded environment. It has allowed websites to flourish which otherwise may have been little more than a niche sites back when it was mostly university geeks and researchers. But on the other, we have a subset of people who are more open to scams, who place a larger burden on support resources and who are unable to deal with issues such as compromised computers infected with Trojan horses.
But the bigger and darker issue is that the Internet is much more about user feedback than at any time before. It is a place where every voice and opinion can receive an equal audience. What happens when you have millions of uneducated riff-raff joining in the conversation, especially when the topic is political in nature? It often drags the quality of the conversation down. You end up with people parroting their worldviews rather than thinking about the subject at hand. Unless that environment is heavily moderated, it will end up sullied.
As to the groups of people who are underrepresented on the Internet, I'm relieved that is the case. While some of them may begin to change their worldviews from being exposed to more ideas, I think the benefit to society would be greatly outweighed by the damage such people would cause. But the genie is already out of the bottle. Costs will continue to drop and more services will simply require Internet access in order to procure them. Internet penetration will continue to climb. I think that it is inevitable that everyone will have access, and we as a society will just have to adapt to it, for better or worse.