My understanding is that both ClassAct and MUI were subclasses of BOOPSI and inherited their properties, including Intuition-specific threads. This was by design, as BOOPSI was designed to be extendable.
It has been a zillion years, so somebody correct me if I am wrong.
1. To shutdown the Amiga, you turned it off. There was no delay, no Start->Shutdown...wait possibly forever...
Which prevented the use of native filesystem write caching due to the chance of data corruption. That's why all writes under AmigaOS were immediate. Heck, if you turned your computer off during a write, even without caching, you could still fubar your filesystem.
2. Sliding screens. Why not give each application its own full screen and allow the user to pull down the top menu to slide between these screens.
Windows, X11 and the like all support full-screen modes for programs. As for window shades, I always considered it a gimmick and never used it much. ALT-TAB is better.
3. Simple speech device. What could be easier than "LIST > speak:" to say a directory listing?
ls | myspeechprog
4. Bidirectional linked list filesystem. If you lose a sector or sector link, most of the file could be rebuilt by following links from both ends towards the bad sector. (Disk doctor)
Too much overhead. That's why Commodore removed inline datablock pointers in FFS. Besides, use a journaling filesystem and chances of corruption go way down. My HAMMER filesystem on my DragonFlyBSD system hasn't corrupted once.
5. The keyboard garage. The 1985 Amiga 1000 keyboard tucked neatly under the computer where it didn't take up desk space, was hidden from children's fingers and was spill-proof.
At work, I have a $10 hunk of Chinese plastic called a monitor stand that includes a keyboard caddy. Works just as well.
6. Tight integration of hardware with O.S. O.k. this works against everything we've been taught about abstracting everything but since the PC world has boiled down to little more than an O.S. monopoly, a hardware monopoly and a graphics card monopoly, why not eliminate some of the levels of abstraction that will never be used and make my 2Ghz PC perform every day tasks at least as well as my 7Mhz Amiga did?
I think you have nostalgia clouding your memory.
I have an Amiga 3000/040-25 with a Cybervision 64 (S3-Trio64) in my closet of misfit hardware that I occasionally boot up to test portability of some of my C programming. It boots to Workbench fairly fast, but most programs really slow down when you run your desktop higher than 800×600.
Regardless, hardware abstraction is what made the move from PCI to AGP to PCIe so simple. It would have made the migration from Zorro to PCI a heck of a lot easier. It is also what makes writing drivers much easier due to their modular design. Lastly, it doesn't add as much overhead as you think it does.
There are a number of reasons why the Amiga could run so well using a 50MHz processor or slower.
1) The OS used a flat memory model. The entire address space of the 680x0 looked the same to all processes. So there was no slowdown doing page table translations on a per process basis.
2) Every process could read and write to every other process's memory. One process could pass a memory pointer to a second process, which would then have direct read-write access to every data structure the first one had. No having to pass huge amounts of data using semaphores or pipes.
3) The GUI was very primitive. The BOOPSI widget subsystem was about as bare to the metal as you could get. Even extensions such as ClassAct/ReAction were very minimalistic. That made it very fast.
Of course, that all comes with a price.
1) The flat open memory model meant that any sort of malicious software could eavesdrop on any other memory location without bother. Stealing passwords or silently copying data from your word processor? No problem!
2) That same memory model meant that any program could go outside of its bounds and trash any other program in memory, including the kernel. That's why Amigas tended to crash more often than even Windows 95 boxes.
3) Memory fragmentation was horrible because the OS had no form of garbage collection. You couldn't move allocation blocks around in memory because there was no form of abstraction, either using Win32 style handles or virtual memory pages.
4) No memory tracking / garbage collection. If a process closed without freeing memory, it was gone forever. After a while, you'd run out of memory and would have to reboot.
5) Every modern widget toolkit around today, including Qt, GTK+ and Cocoa, generally make BOOPSI look absolutely prehistoric. Try doing any sort of raster or Unicode based apps under AmigaOS. You'd probably have to write your own BOOPSI extensions to get what you want.
6) You would have hit the 4GB limit of the 68020/030/040 much faster had the platform remained around unaltered. That's because every process would share that space. With OSes like OS X, BSD and Windows, each process gets its own 4GB (~3GB after kernel reservations) to play around in.
Yeah. Even your mobile phone has an OS with better memory management and UI functionality than your Amiga 4000.
Briefly reading over the patent in question, I'm curious how this patient was granted given that it resembles IBM's Generalized Markup Language (GML) from the 1960s and the Standard Generalized Markup Language (SGML) standardized by the ISO in 1986.
Recall that we're dealing with DVB-T here, which is MPEG-2 Medium Profile. There are fewer optional features than in H.264 to enable beyond default, so there are fewer ways that the BBC could of done this.
I'd like to know more about what they did. Did they increase the the pixel motion estimation search? They they start to use 'B' frames in addition to 'I' and 'P' frames? Can you use High Profile as opposed to Medium Profile, and if so, does it help rather than hinder at lower bitrates?
I've been using FreeBSD as a secondary desktop environment for about two years now, having used some flavor of BSD since I ran NetBSD 1.0 on my Amiga 3000.
For the most part, the experience is not dissimilar to using Linux as a desktop. I use WINE to supplement a few programs that have poor equivalents in the POSIX/GTK/Qt world, just as I would under Linux. Otherwise, most of the programs I use would be the same ones I'd used under either Windows or Linux.
FreeBSD as a desktop environment shines over Linux in that the sound management is easier. I also find the package installation, at least under the i386 branch, to be easier as well. Whatever doesn't have a package, ports seems to do a superior job than under Linux.
However, in my opinion, FreeBSD will never beat Linux as a desktop replacement until Adobe Flash, hardware video and 3D acceleration and library management are better handled. Linux has FreeBSD beat in most of those respects. Most of the core FreeBSD team is aware of this, but the work required to fix it just seems to be above what people are willing to donate. So, FreeBSD goes without.
43,903,230 people thought enough of Ronald Regan the entertainer to vote him as president. He did such a good job that 11 million more people voted for him the second time around. 54% of California voters chose Schwarzenegger as governor. A majority of voters also elected Sonny Bono to the US House.
Just to show that it isn't just limited to California Republicans drinking the tainted Kool Aid, might I point out Representative Al Franken...
Point being made is that just because you're an entertainer, it doesn't mean you're a bumbling idiot that is completely untrustworthy. Anyone can read the same reports that doctors do in the newspaper about the rates of infection of swine flu versus more traditional influenza strains. After all, even after medical school, doctors have to get their updates from somewhere. Luckily, that somewhere isn't just limited to doctors.
There are a number of ways to access memory pointers larger than the size of your integer arithmetic registers. Memory segments/pages are one way to do that. However, the 8086/8088 used an unusual shift value that wasn't aligned with uniform memory sizes (64KB/16-bit, 16MB/24-bit, 4GB/32-bit). This resulted in the ability to access a single memory location using thousands of different combinations, which made debugging a nightmare. Hopefully, designers would use full 64-bit offset registers with x86-64.
Then there are processors that use separate registers for memory pointers, like the Motorola 680x0 series. Nothing could prevent you from keeping registers R0-R7 one size while you double the size of A0-A7. If you wanted to reduce costs and complexity even further, you could eliminate the orthogonal nature of your instructions and limit pointer arithmetic to basic adds, subs and shifts.
This is one of the main reasons why I prefer FreeBSD as well. When I tried GNU/Linux a few years ago, I kept running into issues with apps using sound under KDE. There were like six or so sound subsystems that I had to fuss with. Each program seemed to want to use a different system. In the end, I got it to work, but it did seem to be an annoying PITA.
Under FreeBSD, it just works. I've used a number of audio cards, from Creative SB-16 and AWE64 cards to Intel HDA compatible embedded chipsets. Never had a problem with an app, and the only problem with the kernel driver is that the snd_hda driver doesn't support SPDIF output as of 7.2-RELEASE.
Another thing that I like about FreeBSD is that its entire memory footprint at a login shell, including audio subsystem, isn't much more than what is consumed just by the RealTek audio driver and processes alone under Windows XP. 26MB just for the RTHDCPL.EXE process? I don't care how cheap memory is these days. That's simply a disgusting amount of memory to use for a friggin sound UI app.
Oh, the final reason why I like FreeBSD more. Centralized bug reporting. I had an issue with an AMI MegaRAID controller when I first tried a Linux distro over a decade ago. I went to the distro, and they said to talk to the kernel guys. Talked to the kernel guys, they told me to talk to the vendor who wrote the driver. Talked to the vendor, and they told me that it was essentially as-is. Dropped the same card into FreeBSD, and it worked fine. It even caught the weird IO firmware issue with the Quantum SCSI drive I was using.
If the credit union was a member of the CUService co-op, your friend should have been able to go to a closer branch. For the most part, any member credit union is practically as good as his own.
It comes down to the power of the corn lobby. Specifically, companies such as Archer Daniels Midland (ADM) that have huge corn processing subsidiaries. Large corn growing states, such as Iowa and Kansas, also have powerful government forces behind the effort.
That all said, one major benefit of ethanol alcohol is with engine design. While each liter of ethanol may have fewer joules of energy than a liter of gasoline, ethanol does have a much higher autoignition point (246C/475F for gasoline versus 365C/689F for ethanol). You see this reflected in the effective "octane rating", in which regular gasoline in the US has an RON of 91, premium gasoline an RON of 97 and E85 ethanol an ROL of 105. That allows you to operate your engine with higher compression ratios and higher temperatures (up to a point, before nitrogen oxide emissions become a problem). This should allow for smaller engines that produce equivalent horsepower and torque. Smaller engines weigh less, which therefore consume less fuel, etc...
The biggest issue that I've seen is that most E85 engines don't really do much more than readjust the air:fuel ratio to handle the lower BTU of ethanol. Heck, Henry Ford's model T could do the same thing with the turn of a dial. The result is something of a waste of the potential of what ethanol can do since the engine must remain compatible with standard grade gasoline.
In theory, you should be able to tweak a high performance engine to take advantage of the higher detonation point of E85. One idea is to have a turbocharger modify its level of compression based on the fuel type used. You could also have different piston heads or valve heads, especially tuned for E85, and then have the engine retard the valve timing if you're using lower grade "premium" fuel. Since the octane rating of premium fuel is closer to that of ethanol, your engines doesn't need to cripple itself to maintain such a wide range of fuel compatibility.
But, we've already sharpened the pitchforks and lit the torches.
What are we supposed to do now?
Re:FTPS (breaks load-balancers and firewalls)
on
R.I.P. FTP
·
· Score: 2, Insightful
One major issue with FTP over SSL/TLS is that network address translation (NAT) devices, such as firewalls and load-balancers, that eavesdrop on the FTP control channel in order to open dynamic data ports fail hard with FTPS.
If you use "explicit mode" FTPS, the client negotiates up to FTPS via a standard port 21 connection. After secure authentication, they can issue a 'CCC' (clear control channel) command which backs the control channel back to a NAT compatible mode. Problem is, this is a client side option. It cannot be pushed by the server. So, it is yet another thing that users must be educated over.
If you use "implicit mode" FTPS, which runs up on port 990, negotiation is not an option. You're immediately forced into crypto mode, and you cannot back out either the control or data channel. "Implicit mode" FTPS is incompatible with NAT devices unless you do some seriously nasty hacks.
In my opinion, SFTP (the file transfer subsystem of SSH) is a much better protocol. It does not utilize dynamic ports, and it doesn't involve callbacks (like active FTP) that make firewall rule management a PITA.
Actually, there is a software package for Commodore 8-bit systems called GeckOS that includes a TCP/IP stack with serial SLIP support. You could hook a Commodore 8010 acoustic couple modem to your PET and surf at 300 baud.
True. However, thunking between banks to keep data in a common area can be a fairly resource intensive job. What could be done with a single long call has to be replaced with a number of moves to select and then bring data from a high bank in the REU into bank 0.
Running the processor at a faster speed essentially negates the cost savings of leaving 8 extra address lines off the bus. All of your support chips now need to run at the faster speed, and that adds expense. And as shown with the VIC-II in the C128, that is not always possible.
Lastly, high-level languages in 1980 kind of sucked. To be honest, they still suck today. I think you'd end up with a lot more bank sloshing than with hand tuned assembly. And the overall code would be of lower quality, given the poor level of optimization that compilers and interpreters did back then. Heck, even cc65, a modern ISO C compiler for the 65xx series, doesn't do any code optimization. And it is a program that I would have killed for twenty years ago.
According a quote from Chuck Peddle in "Rise and Fall of Commodore", he didn't see much of a demand or need for 16-bit processors.
I could see where a 16-bit data bus, such as found on the 68000 and 8086, might have been seen as overkill in 1980. You could even argue that a 16-bit index register was overkill in 1980. However, a flat memory model that could access more than 64KB of data was something that was starting to be important by that point. Commodore's own SuperPET, released in 1981, came with 96KB of RAM and 48KB worth of ROMs. You could also get RAM expansion and ROM expansion kits for the earlier PET 4000 line that pushed memory sizes well above 64KB. By 1982, you had the C64 that couldn't even access all of its RAM without bank switching. It was even worse with the CBM-II series and later C128.
The handwriting was not only on the wall, it was on the ceiling and the floor. The 64KB limit had to go, and bank switching was an evil way to do it. Yet Commodore hung onto bank switching for an obscene amount of time. Even as late as 1989, the unreleased Commodore 65 used a modified 65CE02 core as opposed to a 65816 core. Imagine working on a 1280×200 16 color screen using bank switching.
Next to that stupid zero page boundary bug, nothing annoyed me more as a 650x programmer than bank switching. Several people that I've talked to have agreed with me. It really blew chunks, especially when you were working with large data sets.
For as groundbreaking that the ARM processor series, it was beat to the punch by DARPA. Not only did they help give us the Internet, they also helped with the evolution of chips that power your PDAs and smart phones that use the Internet.
Now for a trip back in time... supposedly during the late 1970s, processor design was starting to hit the limits of manual design. These were still the days of designing a microprocessor on paper. The military, a huge consumer of microchips at the time, decided to sponsor research into the creation of standardized processes for microprocessor design. The result was DARPA's VLSI Project. Standford, UNC/Chapel Hill, Berkeley and others were involved.
Numerous products and organizations came out of the VLSI Project. The BSD fork of AT&T's System-V saw major use and evolution. Networked CAD systems matured, specifically using the Stanford University Network (SUN) workstation, which was commercialized by Sun Microsystems.
Most relevant to the article, though, was the advancement of the "RISC" design. During the 1970s, researchers noted that highly orthogonal processors (where every type of operation, such as ADD, SUB, SHIFT, XOR, etc..., can be used with any kind of memory operator, such as direct, indirect, indexed, etc...) were somewhat wasteful. The vast majority of operations were rarely used. If you restricted those operations to register-only ops, you could really simplify the processor.
RISC architectures are less memory efficient than CISC architectures, something that was important in the 1970s, a time when dinosaurs roamed and 4KB Altairs roamed the world. They are also more tedious to program using assembly languages, also an issue during the 1970s when higher-level language compilers were rather unoptimized. However, by the time that the VLSI Project came around, these limitations were going away.
Since RISC processors are so much easier to design than CISC processors, researchers used their groovy new tools to design one. So in 1982, the DARPA RISC-1 was born, which had less than half the number of transistors as the Motorola 68000. It also ran circles around the 68000. A year later, the RISC-II was released. It was three times as fast as its predecessor.
The RISC design was also a huge advancement for researchers over at Standford. John Hennessy over there was trying to design a new processor that exploited the concept of pipelining. The problem, however, is that CISC instructions have variable (and often long) execution time. This can cause the pipeline to stall since the processor runs dry on data to execute. RISC design solves that problem because most of the operations, with exception of memory load/store ops, are short and quick. Hennessy borrowed these "new" concepts and came up with the MIPS architecture, one of the first popular RISC designs.
Not much later, Acorn Computer, looking to replace the MOS 6502 processor but dissatisfied with the Motorola 68000, National Semiconductor 32016 and others, went looking for a new chip in 1983. They traveled to the States and visited Western Design Center. Seeing how "simple" it was to design a processor, they brainstormed up the concept of the ARM1.
The ARM probably would never have been designed without the advances that came out of the VLSI Project. The ARM2, the first production unit, only contained some 30K transistors. The DARPA RISC-I was 44K while the RISC-II was reduced to 40K. The 68000 was a whopping 70K transistors.
Interestingly enough, when Bill Mensch and company designed the 6501 (and later lawsuit modified 6502), they purposely made it very easy to expand it for future use. Although the chip was original designed for use in embedded solutions, several reports suggest that Bill Mensch, as well as fellow designer Chuck Peddle, saw the possibilities of the personal computer. This was around the time that the Altair 8800 was just released.
Bill Mensch attempted to push Commodore for features that might be useful for a personal computer. However, Commodore management rebuffed him. Supposedly frustrated that Commodore management was as short sighted as the Motorola management that he had fled from just a few years earlier, Bill Mensch went on to start his own company designing successors to the 6502.
Over at Western Design Center, Mensch and his sister designed the WDC 65C02, a bugfixed and enhanced version of the MOS 6502, that found its way into the Apple IIc and "enhanced" IIe. They also designed the WDC 65816, an extremely feature enhanced version of the 65C02 that included 16-bit index registers, 24-bit addressing, movable stack and zero page locations, and a host of new ops that allowed for jump tables and position independent code (useful with multitasking OSes and shared libraries).
Just imagine if Commodore had the 65816 in 1980 and released a 16-bit successor to the PET that could handle up to 16MB without the weirdness of bank swapping or segmentation. It would have been very popular with programmers. Smoking the "what if" crack pipe even more, imagine if they ported TRIPOS to the 65816.:)
Too bad they probably would have ruined it by bundling it with a chicklet keyboard.
To add to it, DragonflyBSD 2.2.1 was released just last week. Also, FreeBSD 7.2 is currently in release candidate (RC1) state. It should be out soon as well.
Many technological inventions have had their adoption assisted when the porn industry started making use of it. Perhaps GE will quietly partner with an adult entertainment company, who in turn, will release these discs preloaded with hours and hours of 1080p video.
Mmmm... holographic boobies.
For every website I've ever created, I include a link in the top left corner that points to a text-only version of the same page. When you bring the main page up, the text-only link is the first one available.
According to my web stats, the most common user of the text-only pages are people from third world countries, as well as a significant number of mobile users. I have also seen a large number of legacy browsers, such as Lynx, Netscape 4 and IE 4.
The text-only page is the ultimate fail-back option. Every single web browser can handle it. Text to speech devices can handle it. People with vision problems can read it more easily.
I'm actually surprised that they've not been made mandatory in the US due to ADA (Americans with Disabilities Act) requirements. As somebody who suffers from vocal Tourette syndrome when my page is overloaded with crappy Flash content, I think such a requirement would be a great idea.
My first ATI product was a Rage Pro PCI card. The drivers under NT4 were horrible, with multiple blue screens, flaky TV out and a host of other issues.
My next three cards were Nvidia. Not a single problem with them. Drivers were great, even TV capture under Win2K. Heck, even DOS VESA support was rock solid.
I eventually purchased a Radeon 8500LE since I wanted component 1080i output, something Nvidia didn't offer at the time. Again, drivers were horrible. Control of overscan was non-existent, programs were given non-HD resolutions to default to, no scaling, and programs were crashing the Catalyst drivers left and right. In the game Painkiller, the Catalyst drivers crashed and restarted over sixty times when attempting to cross the ice bridge.
Next three cards were again Nvidia. Flawless driver support under XP x86, XP x64 and FreeBSD 6.x. Component 1080i output under XP was flawless. However, both of my 6600GTs died prematurely (10mo and 16mo old), and I dumped my 8600GT when I learned of the manufacturing defects, although I had no problems with that specific card.
I picked up an ATI Radeon HD 3200 based mainboard on the cheap as a HTPC system, as well as a stopgap until the Geforce 9 cards came out. This was right around the time I was dumping Windows XP x64 edition as my primary OS in favor of FreeBSD + KDE.
Multiple lockups using Svgalib and Radeon driver in X11 (I'm stuck using Vesa driver), XvMC driver acceleration is absent, Xv doesn't appear to work, and OpenGL with the Radeon driver causes the screen to go black.
So yeah, Nvidia cards may die young these days. But, at least the suckers work for a while. That said, if ATI cards last 10x as long, perhaps that will finally give them enough time to fix their drivers.
I would think I would have learned by now. Maybe I should dig up my old S3 Trio64 PCI card and drop it in...
Is an IBM 286/AT with a 386 turbo board still an AT? Is an Amiga 1200/EC020 with a PowerPC accelerator still an Amiga? Both of those upgrades extend the address bus from 16MB to 4GB, as well as incorporating new machine code instructions.
I would say that a Commodore 64 or 128 with a WDC 65816 accelerator board is still the original system at heart. When the 65816 is set to 6502 emulation mode and fed a 1MHz clock, it'll run 99.99% of all original software (including programs that [ab]use illegal op-codes and utilize processor clock dependent timing) without issue. As for the extra memory above 64KB, I believe that some of it is available to stock C64 programs through the use of [emulated] 6510 bank switching. So, it is more of an evolutionary enhancement than a revolutionary replacement.
As for a C64 powered by a MC 68000, I think you do have a point. But what about people who only the use MC 6809 in their SuperPET, or only use the Zilog Z80 in their Commodore 128? The reason they get a free pass is because the auxiliary processor was sold with the system.
But those processors are 100% incompatible with the "main" processor. Yet the rest of the system is still very much that of a PET or a C128. So where do they fit?
Slashdot Mirror
My understanding is that both ClassAct and MUI were subclasses of BOOPSI and inherited their properties, including Intuition-specific threads. This was by design, as BOOPSI was designed to be extendable.
It has been a zillion years, so somebody correct me if I am wrong.
1. To shutdown the Amiga, you turned it off. There was no delay, no Start->Shutdown...wait possibly forever...
Which prevented the use of native filesystem write caching due to the chance of data corruption. That's why all writes under AmigaOS were immediate. Heck, if you turned your computer off during a write, even without caching, you could still fubar your filesystem.
2. Sliding screens. Why not give each application its own full screen and allow the user to pull down the top menu to slide between these screens.
Windows, X11 and the like all support full-screen modes for programs. As for window shades, I always considered it a gimmick and never used it much. ALT-TAB is better.
3. Simple speech device. What could be easier than "LIST > speak:" to say a directory listing?
ls | myspeechprog
4. Bidirectional linked list filesystem. If you lose a sector or sector link, most of the file could be rebuilt by following links from both ends towards the bad sector. (Disk doctor)
Too much overhead. That's why Commodore removed inline datablock pointers in FFS. Besides, use a journaling filesystem and chances of corruption go way down. My HAMMER filesystem on my DragonFlyBSD system hasn't corrupted once.
5. The keyboard garage. The 1985 Amiga 1000 keyboard tucked neatly under the computer where it didn't take up desk space, was hidden from children's fingers and was spill-proof.
At work, I have a $10 hunk of Chinese plastic called a monitor stand that includes a keyboard caddy. Works just as well.
6. Tight integration of hardware with O.S. O.k. this works against everything we've been taught about abstracting everything but since the PC world has boiled down to little more than an O.S. monopoly, a hardware monopoly and a graphics card monopoly, why not eliminate some of the levels of abstraction that will never be used and make my 2Ghz PC perform every day tasks at least as well as my 7Mhz Amiga did?
I think you have nostalgia clouding your memory.
I have an Amiga 3000/040-25 with a Cybervision 64 (S3-Trio64) in my closet of misfit hardware that I occasionally boot up to test portability of some of my C programming. It boots to Workbench fairly fast, but most programs really slow down when you run your desktop higher than 800×600.
Regardless, hardware abstraction is what made the move from PCI to AGP to PCIe so simple. It would have made the migration from Zorro to PCI a heck of a lot easier. It is also what makes writing drivers much easier due to their modular design. Lastly, it doesn't add as much overhead as you think it does.
There are a number of reasons why the Amiga could run so well using a 50MHz processor or slower.
1) The OS used a flat memory model. The entire address space of the 680x0 looked the same to all processes. So there was no slowdown doing page table translations on a per process basis.
2) Every process could read and write to every other process's memory. One process could pass a memory pointer to a second process, which would then have direct read-write access to every data structure the first one had. No having to pass huge amounts of data using semaphores or pipes.
3) The GUI was very primitive. The BOOPSI widget subsystem was about as bare to the metal as you could get. Even extensions such as ClassAct/ReAction were very minimalistic. That made it very fast.
Of course, that all comes with a price.
1) The flat open memory model meant that any sort of malicious software could eavesdrop on any other memory location without bother. Stealing passwords or silently copying data from your word processor? No problem!
2) That same memory model meant that any program could go outside of its bounds and trash any other program in memory, including the kernel. That's why Amigas tended to crash more often than even Windows 95 boxes.
3) Memory fragmentation was horrible because the OS had no form of garbage collection. You couldn't move allocation blocks around in memory because there was no form of abstraction, either using Win32 style handles or virtual memory pages.
4) No memory tracking / garbage collection. If a process closed without freeing memory, it was gone forever. After a while, you'd run out of memory and would have to reboot.
5) Every modern widget toolkit around today, including Qt, GTK+ and Cocoa, generally make BOOPSI look absolutely prehistoric. Try doing any sort of raster or Unicode based apps under AmigaOS. You'd probably have to write your own BOOPSI extensions to get what you want.
6) You would have hit the 4GB limit of the 68020/030/040 much faster had the platform remained around unaltered. That's because every process would share that space. With OSes like OS X, BSD and Windows, each process gets its own 4GB (~3GB after kernel reservations) to play around in.
Yeah. Even your mobile phone has an OS with better memory management and UI functionality than your Amiga 4000.
Briefly reading over the patent in question, I'm curious how this patient was granted given that it resembles IBM's Generalized Markup Language (GML) from the 1960s and the Standard Generalized Markup Language (SGML) standardized by the ISO in 1986.
Recall that we're dealing with DVB-T here, which is MPEG-2 Medium Profile. There are fewer optional features than in H.264 to enable beyond default, so there are fewer ways that the BBC could of done this.
I'd like to know more about what they did. Did they increase the the pixel motion estimation search? They they start to use 'B' frames in addition to 'I' and 'P' frames? Can you use High Profile as opposed to Medium Profile, and if so, does it help rather than hinder at lower bitrates?
I've been using FreeBSD as a secondary desktop environment for about two years now, having used some flavor of BSD since I ran NetBSD 1.0 on my Amiga 3000.
For the most part, the experience is not dissimilar to using Linux as a desktop. I use WINE to supplement a few programs that have poor equivalents in the POSIX/GTK/Qt world, just as I would under Linux. Otherwise, most of the programs I use would be the same ones I'd used under either Windows or Linux.
FreeBSD as a desktop environment shines over Linux in that the sound management is easier. I also find the package installation, at least under the i386 branch, to be easier as well. Whatever doesn't have a package, ports seems to do a superior job than under Linux.
However, in my opinion, FreeBSD will never beat Linux as a desktop replacement until Adobe Flash, hardware video and 3D acceleration and library management are better handled. Linux has FreeBSD beat in most of those respects. Most of the core FreeBSD team is aware of this, but the work required to fix it just seems to be above what people are willing to donate. So, FreeBSD goes without.
43,903,230 people thought enough of Ronald Regan the entertainer to vote him as president. He did such a good job that 11 million more people voted for him the second time around. 54% of California voters chose Schwarzenegger as governor. A majority of voters also elected Sonny Bono to the US House.
Just to show that it isn't just limited to California Republicans drinking the tainted Kool Aid, might I point out Representative Al Franken...
Point being made is that just because you're an entertainer, it doesn't mean you're a bumbling idiot that is completely untrustworthy. Anyone can read the same reports that doctors do in the newspaper about the rates of infection of swine flu versus more traditional influenza strains. After all, even after medical school, doctors have to get their updates from somewhere. Luckily, that somewhere isn't just limited to doctors.
There are a number of ways to access memory pointers larger than the size of your integer arithmetic registers. Memory segments/pages are one way to do that. However, the 8086/8088 used an unusual shift value that wasn't aligned with uniform memory sizes (64KB/16-bit, 16MB/24-bit, 4GB/32-bit). This resulted in the ability to access a single memory location using thousands of different combinations, which made debugging a nightmare. Hopefully, designers would use full 64-bit offset registers with x86-64.
Then there are processors that use separate registers for memory pointers, like the Motorola 680x0 series. Nothing could prevent you from keeping registers R0-R7 one size while you double the size of A0-A7. If you wanted to reduce costs and complexity even further, you could eliminate the orthogonal nature of your instructions and limit pointer arithmetic to basic adds, subs and shifts.
This is one of the main reasons why I prefer FreeBSD as well. When I tried GNU/Linux a few years ago, I kept running into issues with apps using sound under KDE. There were like six or so sound subsystems that I had to fuss with. Each program seemed to want to use a different system. In the end, I got it to work, but it did seem to be an annoying PITA.
Under FreeBSD, it just works. I've used a number of audio cards, from Creative SB-16 and AWE64 cards to Intel HDA compatible embedded chipsets. Never had a problem with an app, and the only problem with the kernel driver is that the snd_hda driver doesn't support SPDIF output as of 7.2-RELEASE.
Another thing that I like about FreeBSD is that its entire memory footprint at a login shell, including audio subsystem, isn't much more than what is consumed just by the RealTek audio driver and processes alone under Windows XP. 26MB just for the RTHDCPL.EXE process? I don't care how cheap memory is these days. That's simply a disgusting amount of memory to use for a friggin sound UI app.
Oh, the final reason why I like FreeBSD more. Centralized bug reporting. I had an issue with an AMI MegaRAID controller when I first tried a Linux distro over a decade ago. I went to the distro, and they said to talk to the kernel guys. Talked to the kernel guys, they told me to talk to the vendor who wrote the driver. Talked to the vendor, and they told me that it was essentially as-is. Dropped the same card into FreeBSD, and it worked fine. It even caught the weird IO firmware issue with the Quantum SCSI drive I was using.
If the credit union was a member of the CUService co-op, your friend should have been able to go to a closer branch. For the most part, any member credit union is practically as good as his own.
The HX DOS Extender for MS-DOS was written 100% using assembly. It is a Win32 compatible API layer for DOS. Source code is available.
Granted, it just thumps to 16-bit BIOS calls, but it does make for interesting study.
It comes down to the power of the corn lobby. Specifically, companies such as Archer Daniels Midland (ADM) that have huge corn processing subsidiaries. Large corn growing states, such as Iowa and Kansas, also have powerful government forces behind the effort.
That all said, one major benefit of ethanol alcohol is with engine design. While each liter of ethanol may have fewer joules of energy than a liter of gasoline, ethanol does have a much higher autoignition point (246C/475F for gasoline versus 365C/689F for ethanol). You see this reflected in the effective "octane rating", in which regular gasoline in the US has an RON of 91, premium gasoline an RON of 97 and E85 ethanol an ROL of 105. That allows you to operate your engine with higher compression ratios and higher temperatures (up to a point, before nitrogen oxide emissions become a problem). This should allow for smaller engines that produce equivalent horsepower and torque. Smaller engines weigh less, which therefore consume less fuel, etc...
The biggest issue that I've seen is that most E85 engines don't really do much more than readjust the air:fuel ratio to handle the lower BTU of ethanol. Heck, Henry Ford's model T could do the same thing with the turn of a dial. The result is something of a waste of the potential of what ethanol can do since the engine must remain compatible with standard grade gasoline.
In theory, you should be able to tweak a high performance engine to take advantage of the higher detonation point of E85. One idea is to have a turbocharger modify its level of compression based on the fuel type used. You could also have different piston heads or valve heads, especially tuned for E85, and then have the engine retard the valve timing if you're using lower grade "premium" fuel. Since the octane rating of premium fuel is closer to that of ethanol, your engines doesn't need to cripple itself to maintain such a wide range of fuel compatibility.
But, we've already sharpened the pitchforks and lit the torches.
What are we supposed to do now?
One major issue with FTP over SSL/TLS is that network address translation (NAT) devices, such as firewalls and load-balancers, that eavesdrop on the FTP control channel in order to open dynamic data ports fail hard with FTPS.
If you use "explicit mode" FTPS, the client negotiates up to FTPS via a standard port 21 connection. After secure authentication, they can issue a 'CCC' (clear control channel) command which backs the control channel back to a NAT compatible mode. Problem is, this is a client side option. It cannot be pushed by the server. So, it is yet another thing that users must be educated over.
If you use "implicit mode" FTPS, which runs up on port 990, negotiation is not an option. You're immediately forced into crypto mode, and you cannot back out either the control or data channel. "Implicit mode" FTPS is incompatible with NAT devices unless you do some seriously nasty hacks.
In my opinion, SFTP (the file transfer subsystem of SSH) is a much better protocol. It does not utilize dynamic ports, and it doesn't involve callbacks (like active FTP) that make firewall rule management a PITA.
Actually, there is a software package for Commodore 8-bit systems called GeckOS that includes a TCP/IP stack with serial SLIP support. You could hook a Commodore 8010 acoustic couple modem to your PET and surf at 300 baud.
Not that you'd want to. But you could.
True. However, thunking between banks to keep data in a common area can be a fairly resource intensive job. What could be done with a single long call has to be replaced with a number of moves to select and then bring data from a high bank in the REU into bank 0.
Running the processor at a faster speed essentially negates the cost savings of leaving 8 extra address lines off the bus. All of your support chips now need to run at the faster speed, and that adds expense. And as shown with the VIC-II in the C128, that is not always possible.
Lastly, high-level languages in 1980 kind of sucked. To be honest, they still suck today. I think you'd end up with a lot more bank sloshing than with hand tuned assembly. And the overall code would be of lower quality, given the poor level of optimization that compilers and interpreters did back then. Heck, even cc65, a modern ISO C compiler for the 65xx series, doesn't do any code optimization. And it is a program that I would have killed for twenty years ago.
According a quote from Chuck Peddle in "Rise and Fall of Commodore", he didn't see much of a demand or need for 16-bit processors.
I could see where a 16-bit data bus, such as found on the 68000 and 8086, might have been seen as overkill in 1980. You could even argue that a 16-bit index register was overkill in 1980. However, a flat memory model that could access more than 64KB of data was something that was starting to be important by that point. Commodore's own SuperPET, released in 1981, came with 96KB of RAM and 48KB worth of ROMs. You could also get RAM expansion and ROM expansion kits for the earlier PET 4000 line that pushed memory sizes well above 64KB. By 1982, you had the C64 that couldn't even access all of its RAM without bank switching. It was even worse with the CBM-II series and later C128.
The handwriting was not only on the wall, it was on the ceiling and the floor. The 64KB limit had to go, and bank switching was an evil way to do it. Yet Commodore hung onto bank switching for an obscene amount of time. Even as late as 1989, the unreleased Commodore 65 used a modified 65CE02 core as opposed to a 65816 core. Imagine working on a 1280×200 16 color screen using bank switching.
Next to that stupid zero page boundary bug, nothing annoyed me more as a 650x programmer than bank switching. Several people that I've talked to have agreed with me. It really blew chunks, especially when you were working with large data sets.
For as groundbreaking that the ARM processor series, it was beat to the punch by DARPA. Not only did they help give us the Internet, they also helped with the evolution of chips that power your PDAs and smart phones that use the Internet.
Now for a trip back in time... supposedly during the late 1970s, processor design was starting to hit the limits of manual design. These were still the days of designing a microprocessor on paper. The military, a huge consumer of microchips at the time, decided to sponsor research into the creation of standardized processes for microprocessor design. The result was DARPA's VLSI Project. Standford, UNC/Chapel Hill, Berkeley and others were involved.
Numerous products and organizations came out of the VLSI Project. The BSD fork of AT&T's System-V saw major use and evolution. Networked CAD systems matured, specifically using the Stanford University Network (SUN) workstation, which was commercialized by Sun Microsystems.
Most relevant to the article, though, was the advancement of the "RISC" design. During the 1970s, researchers noted that highly orthogonal processors (where every type of operation, such as ADD, SUB, SHIFT, XOR, etc..., can be used with any kind of memory operator, such as direct, indirect, indexed, etc...) were somewhat wasteful. The vast majority of operations were rarely used. If you restricted those operations to register-only ops, you could really simplify the processor.
RISC architectures are less memory efficient than CISC architectures, something that was important in the 1970s, a time when dinosaurs roamed and 4KB Altairs roamed the world. They are also more tedious to program using assembly languages, also an issue during the 1970s when higher-level language compilers were rather unoptimized. However, by the time that the VLSI Project came around, these limitations were going away.
Since RISC processors are so much easier to design than CISC processors, researchers used their groovy new tools to design one. So in 1982, the DARPA RISC-1 was born, which had less than half the number of transistors as the Motorola 68000. It also ran circles around the 68000. A year later, the RISC-II was released. It was three times as fast as its predecessor.
The RISC design was also a huge advancement for researchers over at Standford. John Hennessy over there was trying to design a new processor that exploited the concept of pipelining. The problem, however, is that CISC instructions have variable (and often long) execution time. This can cause the pipeline to stall since the processor runs dry on data to execute. RISC design solves that problem because most of the operations, with exception of memory load/store ops, are short and quick. Hennessy borrowed these "new" concepts and came up with the MIPS architecture, one of the first popular RISC designs.
Not much later, Acorn Computer, looking to replace the MOS 6502 processor but dissatisfied with the Motorola 68000, National Semiconductor 32016 and others, went looking for a new chip in 1983. They traveled to the States and visited Western Design Center. Seeing how "simple" it was to design a processor, they brainstormed up the concept of the ARM1.
The ARM probably would never have been designed without the advances that came out of the VLSI Project. The ARM2, the first production unit, only contained some 30K transistors. The DARPA RISC-I was 44K while the RISC-II was reduced to 40K. The 68000 was a whopping 70K transistors.
Interestingly enough, when Bill Mensch and company designed the 6501 (and later lawsuit modified 6502), they purposely made it very easy to expand it for future use. Although the chip was original designed for use in embedded solutions, several reports suggest that Bill Mensch, as well as fellow designer Chuck Peddle, saw the possibilities of the personal computer. This was around the time that the Altair 8800 was just released.
Bill Mensch attempted to push Commodore for features that might be useful for a personal computer. However, Commodore management rebuffed him. Supposedly frustrated that Commodore management was as short sighted as the Motorola management that he had fled from just a few years earlier, Bill Mensch went on to start his own company designing successors to the 6502.
Over at Western Design Center, Mensch and his sister designed the WDC 65C02, a bugfixed and enhanced version of the MOS 6502, that found its way into the Apple IIc and "enhanced" IIe. They also designed the WDC 65816, an extremely feature enhanced version of the 65C02 that included 16-bit index registers, 24-bit addressing, movable stack and zero page locations, and a host of new ops that allowed for jump tables and position independent code (useful with multitasking OSes and shared libraries).
Just imagine if Commodore had the 65816 in 1980 and released a 16-bit successor to the PET that could handle up to 16MB without the weirdness of bank swapping or segmentation. It would have been very popular with programmers. Smoking the "what if" crack pipe even more, imagine if they ported TRIPOS to the 65816. :)
Too bad they probably would have ruined it by bundling it with a chicklet keyboard.
To add to it, DragonflyBSD 2.2.1 was released just last week. Also, FreeBSD 7.2 is currently in release candidate (RC1) state. It should be out soon as well.
Many technological inventions have had their adoption assisted when the porn industry started making use of it. Perhaps GE will quietly partner with an adult entertainment company, who in turn, will release these discs preloaded with hours and hours of 1080p video. Mmmm... holographic boobies.
For every website I've ever created, I include a link in the top left corner that points to a text-only version of the same page. When you bring the main page up, the text-only link is the first one available.
According to my web stats, the most common user of the text-only pages are people from third world countries, as well as a significant number of mobile users. I have also seen a large number of legacy browsers, such as Lynx, Netscape 4 and IE 4.
The text-only page is the ultimate fail-back option. Every single web browser can handle it. Text to speech devices can handle it. People with vision problems can read it more easily.
I'm actually surprised that they've not been made mandatory in the US due to ADA (Americans with Disabilities Act) requirements. As somebody who suffers from vocal Tourette syndrome when my page is overloaded with crappy Flash content, I think such a requirement would be a great idea.
Not even Slashdot is compliant. This article alone scores 49 errors.
W3 validation of this article
How can people complain about compliance when little of the web is in itself compliant?
Same issue here.
My first ATI product was a Rage Pro PCI card. The drivers under NT4 were horrible, with multiple blue screens, flaky TV out and a host of other issues.
My next three cards were Nvidia. Not a single problem with them. Drivers were great, even TV capture under Win2K. Heck, even DOS VESA support was rock solid.
I eventually purchased a Radeon 8500LE since I wanted component 1080i output, something Nvidia didn't offer at the time. Again, drivers were horrible. Control of overscan was non-existent, programs were given non-HD resolutions to default to, no scaling, and programs were crashing the Catalyst drivers left and right. In the game Painkiller, the Catalyst drivers crashed and restarted over sixty times when attempting to cross the ice bridge.
Next three cards were again Nvidia. Flawless driver support under XP x86, XP x64 and FreeBSD 6.x. Component 1080i output under XP was flawless. However, both of my 6600GTs died prematurely (10mo and 16mo old), and I dumped my 8600GT when I learned of the manufacturing defects, although I had no problems with that specific card.
I picked up an ATI Radeon HD 3200 based mainboard on the cheap as a HTPC system, as well as a stopgap until the Geforce 9 cards came out. This was right around the time I was dumping Windows XP x64 edition as my primary OS in favor of FreeBSD + KDE.
Multiple lockups using Svgalib and Radeon driver in X11 (I'm stuck using Vesa driver), XvMC driver acceleration is absent, Xv doesn't appear to work, and OpenGL with the Radeon driver causes the screen to go black.
So yeah, Nvidia cards may die young these days. But, at least the suckers work for a while. That said, if ATI cards last 10x as long, perhaps that will finally give them enough time to fix their drivers.
I would think I would have learned by now. Maybe I should dig up my old S3 Trio64 PCI card and drop it in...
It is debatable.
Is an IBM 286/AT with a 386 turbo board still an AT? Is an Amiga 1200/EC020 with a PowerPC accelerator still an Amiga? Both of those upgrades extend the address bus from 16MB to 4GB, as well as incorporating new machine code instructions.
I would say that a Commodore 64 or 128 with a WDC 65816 accelerator board is still the original system at heart. When the 65816 is set to 6502 emulation mode and fed a 1MHz clock, it'll run 99.99% of all original software (including programs that [ab]use illegal op-codes and utilize processor clock dependent timing) without issue. As for the extra memory above 64KB, I believe that some of it is available to stock C64 programs through the use of [emulated] 6510 bank switching. So, it is more of an evolutionary enhancement than a revolutionary replacement.
As for a C64 powered by a MC 68000, I think you do have a point. But what about people who only the use MC 6809 in their SuperPET, or only use the Zilog Z80 in their Commodore 128? The reason they get a free pass is because the auxiliary processor was sold with the system.
But those processors are 100% incompatible with the "main" processor. Yet the rest of the system is still very much that of a PET or a C128. So where do they fit?