This IS a real problem. And no one really talks about this.. except maybe Verizon, because they largely don't have it.
Ok.. set the way-back machine to the dawn of cellular phone technology. It was all AMPS, the original analog phone service. And it was 850MHz in the USA, 900MHz in Europe, deal done. Each area could support two cellular providers on that band, period. In the USA, one was usually Verizon (and, to a small extent, the companies Verizon sucked up over the years), the other was probably AT&T (and likewise).
Now, even in this, Verizon was doubly blessed. For one, they started with CDMA, they use CDMA today. Second, the CDMA 3G technology, EvDO, works in the same bandwidth (down to 2.5MHz.. 1.25MHz up, 1.25MHz down) as plain old voice. So every Verizon cell is a 3G cell. Sure, you lose 3G at the fringes, or sometimes when a particular cell is busy, but that's that. And they have the advantage of an 850MHz slot, which means, much more range for the same power. And it works much better in rain, and much, much better through forests and walls. Of course, Verizon also has 1900MHz (1800MHz in Europe) like everyone else.
AT&T Mobility was successful, but not Verizon successful. Neither was Cingular. Together, though, they made themselves the #2 network in the USA. One small problem: AT&T Mobility used DAMPS, the digital TDMA replacement for AMPS. Cingular used GSM (not originally, but by the time of the merger/acquisition). The proper move forward was GSM, but AT&T had to phase that out. That was also where most of their 850MHz slots were being used. They shut down the last DAMPS cell in 2008.. but had to upgrade them.
Two problems here, however, One is that DAMPS had greater range than GSM for regular voice/2G stuff. So some parts of today's cell grid from AT&T is not optimal. That's particularly bad on a standard GSM voice call, because GSM does hard handoff--- one cell drops you before the next one picks you up, as you move. If that fails, you drop the call. CDMA, and GSM/3G (UMTS/HSPA) do soft handoffs... the phone is actually connected to multiple cells at once, and one is dropped only when better ones are connected.
Then there's the GSM 3G technology. You can get that 7.2Mb/s downlink, versus a max of 3.1Mb/s on CDMA, largely because of fatter physical pipes. To see 7.2Mb/s (at least based on AT&Ts set regulation of per-user downlink speeds), you need a full HSPA+ setup, which is two cells bonded together, for a total of 20MHz bandwidth. Even for regular UMTS, you need 10MHz (5MHz up, 5MHz down) for the normal 3G. This meant new spectrum, rather than the CDMA folks being able to re-use their existing spectrum. Kind of.
AT&T actually had more licenses at 1900MHz, thanks to their merger with Cingular, so they could actually do 10MHz at least, 20MHz in some markets, using 850MHz and/or 1900MHz. So they just did. Which is in opposition to what had been planned, but it was legal.
Now, enter T-Mobile. They used to be tiny VoiceStream, at the time the only GSM company in the USA. They were acquired by the German Telecom, which might have been a problem, but they got Catherine Zeta Jones as their spokeswoman, and being really happy to see more of her on a regular basis, I know I didn't mind Germans running the thing. Besides, it's not as if the original VoiceStream did much good.
VoiceStream had a tiny network, and while they built it, they usually only had the single 1900MHz slot. So they didn't the range of AT&T or Verizon. Enter 3G... THEY actually needed the extra spectrum. Which was auctioned off... 1700MHz and 2100MHz. But this took time, of course... they were late to the party. And also, less investment in infrastructure, so even the completed 3G network covers much less.
At this point, though, you have to ask if 3G even matters. AT&T thinks it does... they're still upgrading their network for 7.2Mb/s HSPA+, and claim they'll have over 30 cities wired with the really fast 3G by mid 2010 (if you're an iPod 3GS user, you
The basic "quad-band" designation for GSM phones is for 2G stuff only, not HSPA. So you have 900MHz and 1800MHz in Europe, 850MHz and 1900MHz in the USA. But that's not 3G... usually. And that's because there just wasn't enough bandwidth... a proper G3 HSPA connection requires at least 10MHz of bandwidth, versus the 2.5MHz any carrier has guaranteed for 2G links. For HSPA+ speeds, they want two bonded cells... 20MHz total.
The preferred configuration, then, for US UMTS/HPSA was the AWS band, 1700MHz and 2100MHz (split between uplink and downlink), but AT&T didn't want to wait for this auction. In most of the US, AT&T had enough bandwidth on both 850Mhz and 1900MHz to offer full HPSA, so they just went that way. T-Mobile didn't, so they had to wait for the AWS auction before they could expand with 3G services. This was not a CDMA issues, since EvDO doesn't require additional spectrum (this is also why HSPA+ can be faster, and also why every CDMA cell is already 3G, versus some small fraction of those for GSM systems here in the USA).
Europe also went with 2100MHz, as did the rest of the GSM world. Except in some countries, which had larger than normal 900MHz bands. Or other weird local standards.
In short, the "universality" of GSM is only guaranteed with a quad band phone, and never for 3G services.
Only problem... Mr. Ballmer forgot that Microsoft's software is ALSO Smartphone-only. So they're sharing the same 10% (well, a bit less in 2007 when he said this) of the total phone market as Apple. And from the look of things, Apple's market share had grown every year (Android grew faster in the last year, but essentially from nothing), while Microsoft's has fallen, fast (Nokia and RIM are still numbers 1 and 2 in smartphones, world-wide, but they have been losing market share, too... but in a growning market, that can still mean sales increases).
The other thing Mr. Ballmer didn't consider (maybe they shouldn't let him talk so much in public)... that 10% or so of the phone market brings in slightly more than 50% of the sales (based on 2009 sales), by dollar, and nearly 2/3 of the profits. And that's before you look at additional revenue streams like app sales. So you might actually be happy with 2-3%, if that really translates to 20-30% of all smartphone sales. In other words, you might be happy with RIM's annual sales, rather than, say, oh-I-dunno, Windows Mobile's?
The more interesting thing, though, is just how low the whole smartphone thing can fall in price. I don't think Apple's ever going to deliver something in the "free" (with subsidy) category. There are some WinMo phones at that level, though that could be a firesale factor -- they can't sell them otherwise. Microsoft does the WinMo thing the same way they do other things.. they get the OS fees up front, fixed, and let the vendors hash it out in the hardware world. As margins an entry levels fall, this is going to price WinMo out of the market. RIM has been trying to go after consumer sales, but they remain fairly pricey, for phones that just don't compare to the others very well anymore... RIM is really good for a company's ability to push its phone policy on all employees, but there's little to recommend it to individuals. Not sure about Nokia... they're backing both Symbian and Linux right now, but barely known in the US smart phone market. They could certainly go cheaper with Linux.
And then there's Android... that can also go much cheaper... they're already supporting smaller-then-iPhone displays (320x200). The cost of the OS is zero, or perhaps "less than zero" based on Google kickbacks (which may not last forever). There's also the development cost issues... a company developing Android phones for the current smartphone market might save some money using Android on their cheaper phones, even if they're not intended to be full smart phones. This hasn't happened yet, but given how pervasive ARM is in the phone world, it should be possible to put Android on much lower-spec phones.
I'd love to hear Ballmer say something equally silly about the Android OS this year:-)
One and a half guys working in their spare time for a year doesn't get you that. And really, at this point, a stable, non-crashing clone of iMovie on Linux would be a good first step.
The problem with every one of these projects is that the goal is that of one or a few individuals, toward whatever end they have in mind. That's often where they land, years later... a version that did what they wanted, with no other direction, no adequate testing, feedback, and resolution of bugs, etc.
Simply put, a guy who only owns an $500 HDV camcorder isn't going to worry all that much about editing RedCode. The good thing about open source is that, if he delivers something worthy for use with that HDV camcorder, others can take it further.
The sad fact, pointed out buy the "constant reinventing of iMovie", is that no one yet seems to have invented a good enough iMovie that others have teamed together to move that somewhere higher end. That suggests this work needs to continue until that happens.
Given the scale of such commercial projects, I think the developers did this right, layering it on as many existing Linux technologies as possible.
Back in the days of analog, you had tape. Linear editing... tapes go backward and forward only, you can't jump around.
At the end of those dark days, you could buy video controller software, that would manage camcorders and recording decks from a computer, and perhaps direct other things. For example, back in the early 1990s, I used Scala's MM300 and EE100 packages on an Amiga. This could control camcorders and decks via LANC, RS-485, or infrared, and as well, allow control of smart TBC and Genlock devices, and of course, mix in the Amiga graphics for titling. While you were kind of on your own for audio with this setup, it was a decent way to build up a linear edit.
But once you had non-linear, you'd never want to go back.
Adobe Premiere is a low-end professional application. Like Vegas, Final Cut Pro, and some versions of Avid, it's going to span the range of high-end hobbyist to low-end professional, for a price such folks can afford. With features they might need. But for regular consumers, no... you don't need Red Camera support, for example, in a program for consumers.
You also find that at this level, the NLE is just one program of many the user will need. Even the fancy NLEs are often weak on audio, compositing, animation, titling, disc authoring, etc.
Mainstream (eg, wide appeal to regular consumers) varies between "came with the computer or camcorder" apps, up to the lower-priced commercial software. In the former category, you have Windows Movie Maker (weak, but pretty much every Windows user has it), iMovie (not as bad, and every Mac user has it), and a bunch of cut-down "SE" or whatever versions of apps from the first category.
These are often cut-down versions of the higher-end apps: Adobe Premiere Elements, Sony Vegas Studio, Final Cut Pro Express, etc... and some that just end at "Consumer", like Corel Video Studio, Magix Movie Edit Pro/Video Pro, etc. Many of these are available at several tiers of capabilities... they like to bundle an "SE" version where possible, get users to upgrade from that to the $50-$75 version, and maybe some of them upgrading to the $100+ version.
I'm not sure there's much data on what's most popular or not. Adobe seems to be very good at getting their "SE" versions included in OEM deals... they blazed that trail with Adobe Photoshop Elements. Of course, most Mac users are using some version of iMovie or Final Cut, maybe using Avid at the very high end. Sony Vegas is very popular as an upgrade on Windows, but there are literally dozens of choices.
Yup... I use Sony Vegas Pro 9.0 myself. It's a great NLE, and around $500 new.
But it did start out as Sonic Foundry's Vegas Pro, which didn't even do video, it was just an audio sequencer/NLE. And a damn fine one. That was the late 1990s. It took better than ten years of professional development (eg, fulltime jobs) to deliver the Vegas you can buy today. Give this guy a break!
Vegas won with many users, IMHO, for one big reason: it was very, very reliable. Unlike most of the other NLEs of the day (some still exist, some long gone), it was reliable and modern. You didn't have to format media for use... it worked with pretty much any kind of audio, and once 2.0 was out, video, all on the same timeline. It worked direct.. no need to convert your media to other formats. It didn't crash constantly. Still doesn't.
I have not played around with every Linux NLE, nor all that recently. But my experience is, none are all that powerful, and most were way too buggy to consider using. And they were not evolving anywhere near as fast as Vegas. There may be some "warm fuzzies" some folks get using free software, but if you have an actual video editing job to finish, for pay or for fun, you can only struggle so much with the tools you're using before the job isn't really about video anymore, but working around a flawed tool. Open source doesn't help if you lack the skills and or years necessary to fix the bugs in that tool... one of the stated advantages of FOSS, but not always a realistic one (if it were, the same reliability advantages you really do see in Linux these days would translate to applications, but it often doesn't).
This seems like a good start.. if Thomas can concentrate on making this work reliably and simply (two of his stated goals), that's an accomplishment for Linux NLEs. Give it some time to get powerful. Linux and FOSS will benefit more from delivering solutions that really work as well as commercial solutions, of any kind, than of delivering unfinished science projects. No matter how cool the science.
If you buy a Microsoft branded retail product, you get a few bits of free support... the amount varied depending on whether its via phone or the internet. But if it's an OEM product (eg, Windows 7 came on that new HP laptop), then it's HP who's required to provide the tech support. At least according to Microsoft... but they will happily let you pay them for it.
There is some customer service from Microsoft. But they have largely been in the same boat as Google... customer support is supposed to come directly from the OEM, unless you're buying from Google or Microsoft directly. That is the business case, not reflective of reality, of course... I really wouldn't expect Verizon to be able to answer any Android question I couldn't answer myself, and I'd only have slightly higher hopes of this from HP in regard to Windows.
Wow... I did just upgrade a few machines to Windows 7... guess I actually can ask Microsoft. Though, like many companies these, they charge for the full service after a short time. And all in all, you're probably better off on independent support boards, or search though Google.
That's kind of a lame excuse. There's nothing all that magical about the Nexus One. Yeah, it's a nice Android phone. So is the Mot DROID, and many others. There's nothing particularly new or different in the Nexus One, other than the "front of device" Google branding, versus the "back of the device" Google branding you get on any Google Experience phone. In both cases, the OEMs have no way to limit the content of the device, or change the UI.
As for tablets... CES is absolutely swimming with tablets this year. There are over a dozen at the nVidia booth alone. And most of them are running Android. Sure, it's CES, and some of these are definitely technology demonstrations and trial balloons, but some will absolutely hit the market.
I have a sneeking suspicion that some of these companies are waiting to see what Apple actually releases... that alone may be what's holding things back. But 5" Android tablets aren't even new... Archos put one out last year. Nokia's been selling Linux tablets for years. The idea that it takes Google to launch a tablet is just silly.
And the thing is, those are not state-of-the-art (as it were) desktop PPC processors. They're older embedded chips, the kind of thing you find in some routers and other network devices (PPC got a big boost in that market, Cisco, at least at one time, had standardized on the PPC for use in network switches and routers). They're not as fast as PPC Macs from quite a few years ago.
Of course, running what's just a basic PPC Amiga port, they SEEM fast. They're fast enough to play some kinds of compressed video, but don't throw HD in AVC at them, or they'll just crawl into a corner and curl up.
We were getting 5-6MB/s sustained throughput with the WD33C93A (the on-board SCSI controller) and the custom DMAC. This was back in the days when PCs and Macs were struggling to deliver better than 1MB/s, and both were using PIO. Even the Mac IIfx, which was the only Mac in the day with a DMA controller, ran PIO when running MacOS (they did DMA for UNIX).
The WD controller was bit CPU intensive compared to the NCR53C710 chip (on the 4091 and the A4000T), sure, but the NCR had a whole SCSI protocol processor on it. It could make intelligent decisions without the need to interrupt the CPU all the time. The WD chip pretty much needed to check with the CPU after every load. It wasn't as slow as the NCR5380 used on many of the Macs of the day.. basically a glorified parallel port, but who cares when you're single tasking. Other than speed... one big advantage of the DMAC was simply that we did 8-bit to 32-bit funneling through a FIFO, so transfers fully used the A3000 bus.
The NCR53C710 chip was so frickin fast, it could actually lock out the CPU for awhile... of course, drives had become a bit faster in those three years, too. This actually screwed up a couple of clever hacks... folks had hooked into the WD chip's interrupt handler to get a ping after every load... some of the first full animation and video (simple compression) from HDD worked this way.
Well, I dunno for sure... I was only working on the higher end machines at the time. You'd do better with a 14Mhz '020 or even EC020 than 20MHz 68000 on most code, thanks to the I-cache, barrel shifter, full 32-bit ALUs, etc. That's the way they went for the A1200.
But also keep in mind, Commodore had been big in the 8-bit world, unit wise, but it was $200-$400 VICs and C64s, in the early 80s, against Apple's $1200-$1600+ Apple ][s, depending on configuration. And the C64 was slightly faster, but not taking seriously. So C= was not quite 1/5th the size of Apple in those days, and they spend less money on R&D as a percentage (and considerably more on the considerably less capable management). So Commodore could not just spin a new system every year, even with clever system-level engineering (eg, no new full custom chips, maybe a gate array or two) on top of the chip stuff.
The custom chips were originally Commodore's key to success, but they did absolutely become a boat anchor. For one, it was several years too late that management finally started letting us go outside for chips... they didn't have to be made at CSG (the old MOS Technology). They had some nice features, like gate arrays turned around in a month, but other issues, like 84 pin limits, one thing that caused so many problems with the A3000 expansion bus. And added cost. One of the AA chips, and all of the AAA chips, were made at HP, in a better CMOS process than C= had at the time.
The "real" 68030 was used because, well, we wanted to use a 68030, the "Embedded Controller" version hadn't been made yet (these used "real" 68030 chips with MMUs that failed the test, at least initially), and, well, you don't put an EC chip in your high-end machine. Also, the A3000 ran UNIX.. the A3000/UX wasn't terribly successful (largely due to Commodore management somewhere pulling their typical stupid moves), but it was the first available System V release 4 outside of AT&T and Sun.
There was no technical problem booting from an '040 card, though yeah, the MMU code from the EPROM version of Kickstart would not run on the '040, they changed the MMU model. So you needed real ROMs, or modified EPROMs. Most users with a reasonable amount of RAM put KickStart in RAM anyway, because it was just faster (still is today).
We actually had a prototype of the first '040 card, the big fat one with external L2 cache designed for UNIX, at the A3000 launch. We were going back and forth with Motorola over whether we could show it, since no one outside Motorola had yet shown off an '040 working in public. They ultimately couriered over a "golden" chip, said "yes", and... then some fool manager decided we weren't going to show it anyway, at the launch.
There was no official A3000/040 from Commodore, largely because, when the '040 came out, it was unexpectedly hot, and the case designers felt it wasn't viable. Or at least, that was their excuse. I used them for years without issues, and there were many 3rd party '040 cards as well.
While the A3000 had what looks essentially like an '030 bus, it did allow some '040 functions. For example, a well designed '040 card could do burst writes to A3000 DRAM (so could the DMA controller)... the '030 didn't do burst writes. I designed the CPU card interfaces in the A2000 and A3000 -- they were essentially the same as having the CPU on the motherboard, not a compromise. The A4000 didn't even initially bother with a motherboard CPU (they later put one in, to enable a cheaper A4000 with EC030 in it... I was on to other things by then).
The rendering improved, not because of the limitation of the Toaster (full NTSC is full NTSC, you can't get better than that in NTSC), but because they had more CPU cycles. And yeah, while Foundation Imaging used some Pentium Pros (the first P6 systems) starting in 1995, the rendering stack also had Alphas, and all of the animators were using Lightwave on NT-Alpha systems. Which were quite a bit faster than either Pentiums or Amigas in those days.
The original setup at Foundation Imaging had 24 Amiga 2000s with 68040 accelerators and 32MB of DRAM, sixteen of which were dedicated to the rendering stack (developer workstations were brought into the rendering stacks when unused). They used more complex models for the first year of the series than they did for the pilot, each frame took about 45 minutes to render. Each frame was rendered on a single machine, the rendering manager was a homebrew program. The Amigas all shared a Novell network, which included a 12GB (ooh... ahh...) file server.
The OS really had nothing to do with it... Babylon 5 was possible because of NewTek's Lightwave program. Lightwave did great spaceships because Allen Hastings wanted really great spaceships when he wrote the program. It was also entirely made possible because you could get a Toaster, Lightwave, and an Amiga 2000 for much, much less than alternative solutions... particularly when it came out. Things did improve by the time B5 was shot, though it was only the porting of Lightwave to the Alpha (which made perfect sense, given that Commodore was over with by the time Foundation got their Alphas and P6s) that got them to move over.
Near the end of the series, they were also using Macs for video editing, mattes, and compositing, and SGIs for compositing and titling. They also had SoftImage on some of the Alphas, in addtion to Lightwave everywhere. It's nice to have a TV-class production budget, eh?
Abuse of monopoly powers are. You have to have both the monopoly and the abuse of power in order to be acting illegally. Nothing Apple can do in any market constitutes abuse of monopoly powers, simply because they don't have any recognizable monopoly.
AT&T sure did, and flirted with troubles several times. The first anti-trust suit was filed against AT&T in 1912, based on violations of the Sherman Act. They had been been buying up most of the independent phone companies, and also bought a controlling interest in Western Union (the telegraph people), effectively securing a monopoly in wired communications.
But due to the technical problems... that of independents being able to offer long distance independently, and a few other issues, AT&T and the government entered into the "Kingsbury Commitment" in 1913 (named after a AT&T VP). Under these terms, AT&T divested from Western Union, agreed not to take over other independent companies, other than under special rules (eventually this was eliminated by the government, failing independents were not able to be bailed out by AT&T), AT&T agreed to network with independents (sort of.. the indies could call Bell customers, Bell customers could not call the indies), and they agreed to the universal service deal.
They got sued again, in 1949, but didn't make it to court until 1956. In this one, AT&T was prevented from entering markets other than telecommunications, as part of its obligation as a government approved and regulated monopoly. This was actually a move to prevent the split of Western Electric from AT&T, which is what the suit originally called for.
The final suit was started in 1973, with MCI starting a skirmish with AT&T. At the time, AT&T was the world's largest company. This eventually led, in 1982, to a settlement in which the bulk of AT&T would be broken up into AT&T and 7 separate RBOCs.. Regional Bell Operating Companies. I was working at Bell Labs, Holmdel NJ, in the summer of 1982, just before they started sticking little "Death Star" logos over the ID cards of those employees sticking with AT&T, rather than moving (eventually, most went to the Lincroft offices). But this was something AT&T actually helped engineer... once the breakup took place, they were no longer limited to telecommunications.
Of course, those separate companies were sliced and diced and merged and purged, leaving just Verizon and "the new AT&T" standing today. That old Bell Labs building in Holmdel, which housed around 10,000 employees, is probably getting turned into a mall, er, quaint collection of shops and offices (you can't say "Mall" in Holmdel)... I was there just this past fall. Kind of sad, no one's used it for the last two years.
AT&T, "Ma Bell", etc. had a real, legally valid, and legally supported monopoly. They were allowed to have a legal monopoly, and no, it doesn't have to be absolute, but AT&T certainly had a monopoly. The government didn't break them up, and in return, they were required to hook in anyone who wanted phone service, regardless of the cost of wiring them in. And their pricing for basic service was regulated... all things that would not have happened without that bargain (you see this with high speed internet and pay TV... the carriers cherry pick areas they service to maximize profits, and ignore other areas).
The AT&T breakup was the end of that government granted monopoly. Technology had risen to the point that there were no technical issues in merging networks. Local service did rise a bit, but was somewhat help in check via competition. Long distance, which used to be very high as it subsidized local service, fell dramatically. It was all good, but it wouldn't have been in the early days.
When I first learned to write code, it was 1973 and I was 12 years old. Not commenting things worked ok for a few years, when I wrote trivial programs, rarely went back to them, and had a nearly perfect and fairly uncluttered memory.
It wasn't a whole lot different in college. I did learn to write decent comments -- you were sometimes graded on this ability. But again, one project per week in some classes, all your own code, never to be revisited. Comments went one-way... and I'll bet there are coders here who are still at that level.
I got the first hint in my CAD class, which I guess was a Junior or Senior level project engineering course at CMU. In this class, the whole class was engaged in developing the core of a single CAD program. You got everyone else's modules and had to integrate them into the shell of your final project. That was one example of where comments became pretty important.
Here's another one... I started a program sometime in 1986. I wound up working on it, off an on, for the next 12-something years. It became critical to keep things well documented. This was "DiskSalv" for the Amiga computer.
There are other cases.. sometimes, it's that clever hack that took you a long time to figure out. Another Amiga thing was a trick you might find rare these days... you wanted to reset the system without losing your program's control. The problem was simple.. when you hit reset, you normally got a usual 68000 reset vector, but not the one you wanted, necessarily... since upon reset, a ROM magically appeared at the reset vector, and RAM vanished. So I came up with a hack that organized things just so, so I could count on the prefetch buffer allowing me to turn the ROM off and then jump where I wanted. So it was a few lines of code, and all kinds of commenting to explain why this was (far as I know, ever) the only way to do this on any Amiga computer.
Later on, as mentioned in another comment, I worked in places that made comments part of the forrmal documentation... using simple (and not so simple) tools to extract comments from the code, create hypertext links, etc. (on Amiga and later at Scala, Inc.) The ideal place for the documentation on the code is, absolutely, in the code.
Just like programming, the proper use of comments is an art form. Yes, there are plenty of really stupid comments in code... you don't need line-by-line comments describing the obvious behavior of the code. Well, unless you're writing in APL or some other "write-only" language.. no no-trivial line of APL code is obvious. But proper comments should describe functions, large blocks, and classes... not just what they do or how they work, but what you're thinking and why you did things that might be non-obvious, even when the code looks clear and well written.
There can also be commenting formalisms. I have worked at several companies that used some form of "auto-docs"... basically, when you commented a function, you wrote the documentation for folks calling that function from other modules. I put this feature into the interface description language I wrote as part of an object model for an object-based OS. There were both "formal" and "informal" comments. Informal would be used for very specific little details, formal became part of the hypertext (OS/2 or HTML) generated during every build.
And yeah, in any autodoc-type situation, comment maintenance is part of the job, no less important in the long run than the code itself. In fact, potentially much more important... a bug in your code breaks the system at one point. A bug in your autodoc comments can break the code at any number of points.
This same project also had a mess of pretty cool things. Some weren't useful outside of our object model... the compiler generated a database of pre-compiled object tokens. The release system formally enforced the use of the official release version of the compiler from the server, for a formal release (you could use any compiler you wanted to for testing). This release system also sent release packages out to various other sites in our company, automatically installed, compiled, and merged databases during the "catch" process, etc. You could always build identical code on any PC (OS/2 or Windows NT), with no worries about missing libraries, etc. Not much of it was applicable to code development outside of our specific custom OS, but in the end, it was a very cool system.
When you're running an application in AmigaOS, let's say it's so busy, it's not reading window messages (Windows would report this app as "not responding"). For most applications, you could still move the window around, shrink it, grow it back, etc. At worst, the contents of just that window don't refresh. You don't have the window "stuck" not responding, you don't have parts of other windows getting into each other, as you often see in other OSs. You can even resize the window (again, you MAY not see it refresh properly, or you may, depending on the nature of the window itself).
Datatypes
System level objects used everywhere. You don't care about the kind of graphic file or video you're opening, you just open an IMAGE or a VIDEO or a DOCUMENT or whatever in your program, and you can open any of these known to the system. BeOS implemented a similar idea, but I haven't seen it anywhere else. Sure, there are programs that do this for you, and different systems within the same OS to deal with SOME media types. But nothing as complete, not at least that I've seen.
AREXX
Every program of consequence had an AREXX port. Basically, any command the program could understand was available in AREXX (standard scripting language, originally invented at IBM). So you could build very interesting interactions between running programs. Linux users get a taste of this, between a million command lines and pipes, but this was so much more powerful. And very well supported, pretty much in every commercial application.
ASYNCHRONOUS I/O
Every I/O operation to every device driver could be done synchronously or asynchronously. So what becomes a pain in the butt in an OS like Linux was a couple of extra lines of code in AmigaOS. Of course, in those days, there was no point of asynchronous I/O for Windows or MacOS, since they didn't multitask and pretty much had to dedicate the CPU to loading or unloading your I/O, anyway. But it was a beautiful thing in AmigaOS, in the day.
Probably some other stuff, but I gotta go. It's not that I plan on firing up my A3000 when I get home, rather than that home-integrated Q9550 PC with nVidia 8800GT graphics, 8GB RAM, twin 1920x1200 monitors in 24-bit, and 11TB of total attached storage. My old Amiga was weak at electronics CAD, and I'd still be waiting for that first AVC render for Blu-Ray creation to finish... not to mention the lack of support for huge drives and all. But it's a shame when you have to leave behind better ideas just to move forward a bit.
And don't even get me started on word processing... all the power I had with Scribe at CMU in the 80s, to be stuck with things like Word or OpenOffice, it's crime. I do like the WYSIWYG editing, just wish they didn't have to remove 100 IQ points from the formatting engine to get that....
Actually, that's not how the file system worked... it was better than that. It was fully distributed... there was no master index or master directory. Each directory itself was a hash table, and file headers ran independently of directories. So you could destroy every directory on a volume, and still get everything back but the directory details themselves... no lost files. Not that you would.
Going forward, they had planned to add extents... each file header contained a list of blocks, and could chain to the next and so on. This did wind up being pretty large for large files, and was somewhat solved going to larger blocks (it supported both logical and physical blocks of different sizes). There were also some speed issues with smaller files, and at some point, you'd really want to add journaling, but it was pretty resiliant.
Not Diskdoctor, though... that one always had problems. I wrote the freeware DiskSalv, which did much better.
I'm told they let DiskDoctor decide its own fate. They put the sources on a floppy, then ran DiskDoctor on it. The floppy was trashed, so was DiskDoctor.
The lack of abstractions often seems like a good idea at the start, but it doesn't last. Graphics was about the only thing the Amiga didn't always properly abstract, and it definitely held back progress.
Well, yeah... my mobile phone also has a 550MHz CPU, a 400MHz DSP, a GPU running OpenGL and a couple of media processors. Things change over the course of a decade and a half or two.
Actually, some many VGA devices didn't allow changes in-between frames, as some kind of cheap hack to prevent updates of things between frames. Also, you'll find that most graphics cards will jump, and miss a few frames, if you actually change resolution in any complex way. That's because there's a phase-locked-loop-based clock synthesizer in there, generating your video timing. When you change that timing, the PLL has to re-sync, which can take on the order of many milliseconds.
The whole point of Amiga's changing resolution on the fly is kind of gone, anyway... you were trading one kind of graphics mode for another. Any graphics card still worth using these days can give you a full 24-bit color display (or better) on a couple of HDTV+ resolution monitors at once. No need to flip video modes.
Also, the only reason the Amigas didn't have the same PLL problem is that all graphics modes used the same pixel clock, or multiples thereof. That's why you couldn't independently dial in resolution and refresh rate, as you can with modern graphics cards. The never-released AAA chipset actually supported something like five different PLL inputs (the PLLs themselves were not on-chip, which made my life much harder, being the only person who ever built an AAA-chip-based system), along with other hardware to allow mixed modes,
He probably means OS-9/68000, which was kind of the "default" 68K OS to run, if you didn't need a GUI or anything else in those days, but wanted a more or less UNIXy environment. The Philips CD-i project also used OS-9 as its basis.
There is/was a version, called OS-9000, which ran on x86 and a few other CPUs. And back at least when I was attending ATSC conferences, there was another spin of this called "DAVID", intended for smart TV and STBs. That's the last I heard of it, back in the mid 1990s.
Yeah, absolutely. GEM was DRI's graphical environment, which they wrote to live over MS-DOS. When Atari wanted this on the 68K, they could have run it over CP/M-68K, which was actually a better "DOS" than MS-DOS. Unfortunately, there was so much MS-DOS specific crap in GEM, it was easier just to hack together a compatible MS-DOS replacement. That was GEMDOS, which Atari called "TOS".
Anyone confusing GEM/TOS with AmigaOS needs some serious counseling. That's kind of like preferring Windows 3.1 to Ubuntu... maybe someone does, but if so, they're probably very, very misguided individuals.
Slashdot Mirror
This IS a real problem. And no one really talks about this.. except maybe Verizon, because they largely don't have it.
Ok.. set the way-back machine to the dawn of cellular phone technology. It was all AMPS, the original analog phone service. And it was 850MHz in the USA, 900MHz in Europe, deal done. Each area could support two cellular providers on that band, period. In the USA, one was usually Verizon (and, to a small extent, the companies Verizon sucked up over the years), the other was probably AT&T (and likewise).
Now, even in this, Verizon was doubly blessed. For one, they started with CDMA, they use CDMA today. Second, the CDMA 3G technology, EvDO, works in the same bandwidth (down to 2.5MHz.. 1.25MHz up, 1.25MHz down) as plain old voice. So every Verizon cell is a 3G cell. Sure, you lose 3G at the fringes, or sometimes when a particular cell is busy, but that's that. And they have the advantage of an 850MHz slot, which means, much more range for the same power. And it works much better in rain, and much, much better through forests and walls. Of course, Verizon also has 1900MHz (1800MHz in Europe) like everyone else.
AT&T Mobility was successful, but not Verizon successful. Neither was Cingular. Together, though, they made themselves the #2 network in the USA. One small problem: AT&T Mobility used DAMPS, the digital TDMA replacement for AMPS. Cingular used GSM (not originally, but by the time of the merger/acquisition). The proper move forward was GSM, but AT&T had to phase that out. That was also where most of their 850MHz slots were being used. They shut down the last DAMPS cell in 2008.. but had to upgrade them.
Two problems here, however, One is that DAMPS had greater range than GSM for regular voice/2G stuff. So some parts of today's cell grid from AT&T is not optimal. That's particularly bad on a standard GSM voice call, because GSM does hard handoff--- one cell drops you before the next one picks you up, as you move. If that fails, you drop the call. CDMA, and GSM/3G (UMTS/HSPA) do soft handoffs... the phone is actually connected to multiple cells at once, and one is dropped only when better ones are connected.
Then there's the GSM 3G technology. You can get that 7.2Mb/s downlink, versus a max of 3.1Mb/s on CDMA, largely because of fatter physical pipes. To see 7.2Mb/s (at least based on AT&Ts set regulation of per-user downlink speeds), you need a full HSPA+ setup, which is two cells bonded together, for a total of 20MHz bandwidth. Even for regular UMTS, you need 10MHz (5MHz up, 5MHz down) for the normal 3G. This meant new spectrum, rather than the CDMA folks being able to re-use their existing spectrum. Kind of.
AT&T actually had more licenses at 1900MHz, thanks to their merger with Cingular, so they could actually do 10MHz at least, 20MHz in some markets, using 850MHz and/or 1900MHz. So they just did. Which is in opposition to what had been planned, but it was legal.
Now, enter T-Mobile. They used to be tiny VoiceStream, at the time the only GSM company in the USA. They were acquired by the German Telecom, which might have been a problem, but they got Catherine Zeta Jones as their spokeswoman, and being really happy to see more of her on a regular basis, I know I didn't mind Germans running the thing. Besides, it's not as if the original VoiceStream did much good.
VoiceStream had a tiny network, and while they built it, they usually only had the single 1900MHz slot. So they didn't the range of AT&T or Verizon. Enter 3G... THEY actually needed the extra spectrum. Which was auctioned off... 1700MHz and 2100MHz. But this took time, of course... they were late to the party. And also, less investment in infrastructure, so even the completed 3G network covers much less.
At this point, though, you have to ask if 3G even matters. AT&T thinks it does... they're still upgrading their network for 7.2Mb/s HSPA+, and claim they'll have over 30 cities wired with the really fast 3G by mid 2010 (if you're an iPod 3GS user, you
The basic "quad-band" designation for GSM phones is for 2G stuff only, not HSPA. So you have 900MHz and 1800MHz in Europe, 850MHz and 1900MHz in the USA. But that's not 3G... usually. And that's because there just wasn't enough bandwidth... a proper G3 HSPA connection requires at least 10MHz of bandwidth, versus the 2.5MHz any carrier has guaranteed for 2G links. For HSPA+ speeds, they want two bonded cells... 20MHz total.
The preferred configuration, then, for US UMTS/HPSA was the AWS band, 1700MHz and 2100MHz (split between uplink and downlink), but AT&T didn't want to wait for this auction. In most of the US, AT&T had enough bandwidth on both 850Mhz and 1900MHz to offer full HPSA, so they just went that way. T-Mobile didn't, so they had to wait for the AWS auction before they could expand with 3G services. This was not a CDMA issues, since EvDO doesn't require additional spectrum (this is also why HSPA+ can be faster, and also why every CDMA cell is already 3G, versus some small fraction of those for GSM systems here in the USA).
Europe also went with 2100MHz, as did the rest of the GSM world. Except in some countries, which had larger than normal 900MHz bands. Or other weird local standards.
In short, the "universality" of GSM is only guaranteed with a quad band phone, and never for 3G services.
Bet you can't say that without a lisp....
Only problem... Mr. Ballmer forgot that Microsoft's software is ALSO Smartphone-only. So they're sharing the same 10% (well, a bit less in 2007 when he said this) of the total phone market as Apple. And from the look of things, Apple's market share had grown every year (Android grew faster in the last year, but essentially from nothing), while Microsoft's has fallen, fast (Nokia and RIM are still numbers 1 and 2 in smartphones, world-wide, but they have been losing market share, too... but in a growning market, that can still mean sales increases).
The other thing Mr. Ballmer didn't consider (maybe they shouldn't let him talk so much in public)... that 10% or so of the phone market brings in slightly more than 50% of the sales (based on 2009 sales), by dollar, and nearly 2/3 of the profits. And that's before you look at additional revenue streams like app sales. So you might actually be happy with 2-3%, if that really translates to 20-30% of all smartphone sales. In other words, you might be happy with RIM's annual sales, rather than, say, oh-I-dunno, Windows Mobile's?
The more interesting thing, though, is just how low the whole smartphone thing can fall in price. I don't think Apple's ever going to deliver something in the "free" (with subsidy) category. There are some WinMo phones at that level, though that could be a firesale factor -- they can't sell them otherwise. Microsoft does the WinMo thing the same way they do other things.. they get the OS fees up front, fixed, and let the vendors hash it out in the hardware world. As margins an entry levels fall, this is going to price WinMo out of the market. RIM has been trying to go after consumer sales, but they remain fairly pricey, for phones that just don't compare to the others very well anymore... RIM is really good for a company's ability to push its phone policy on all employees, but there's little to recommend it to individuals. Not sure about Nokia... they're backing both Symbian and Linux right now, but barely known in the US smart phone market. They could certainly go cheaper with Linux.
And then there's Android... that can also go much cheaper... they're already supporting smaller-then-iPhone displays (320x200). The cost of the OS is zero, or perhaps "less than zero" based on Google kickbacks (which may not last forever). There's also the development cost issues... a company developing Android phones for the current smartphone market might save some money using Android on their cheaper phones, even if they're not intended to be full smart phones. This hasn't happened yet, but given how pervasive ARM is in the phone world, it should be possible to put Android on much lower-spec phones.
I'd love to hear Ballmer say something equally silly about the Android OS this year :-)
One and a half guys working in their spare time for a year doesn't get you that. And really, at this point, a stable, non-crashing clone of iMovie on Linux would be a good first step. The problem with every one of these projects is that the goal is that of one or a few individuals, toward whatever end they have in mind. That's often where they land, years later... a version that did what they wanted, with no other direction, no adequate testing, feedback, and resolution of bugs, etc. Simply put, a guy who only owns an $500 HDV camcorder isn't going to worry all that much about editing RedCode. The good thing about open source is that, if he delivers something worthy for use with that HDV camcorder, others can take it further. The sad fact, pointed out buy the "constant reinventing of iMovie", is that no one yet seems to have invented a good enough iMovie that others have teamed together to move that somewhere higher end. That suggests this work needs to continue until that happens. Given the scale of such commercial projects, I think the developers did this right, layering it on as many existing Linux technologies as possible.
Back in the days of analog, you had tape. Linear editing... tapes go backward and forward only, you can't jump around. At the end of those dark days, you could buy video controller software, that would manage camcorders and recording decks from a computer, and perhaps direct other things. For example, back in the early 1990s, I used Scala's MM300 and EE100 packages on an Amiga. This could control camcorders and decks via LANC, RS-485, or infrared, and as well, allow control of smart TBC and Genlock devices, and of course, mix in the Amiga graphics for titling. While you were kind of on your own for audio with this setup, it was a decent way to build up a linear edit. But once you had non-linear, you'd never want to go back.
Adobe Premiere is a low-end professional application. Like Vegas, Final Cut Pro, and some versions of Avid, it's going to span the range of high-end hobbyist to low-end professional, for a price such folks can afford. With features they might need. But for regular consumers, no... you don't need Red Camera support, for example, in a program for consumers. You also find that at this level, the NLE is just one program of many the user will need. Even the fancy NLEs are often weak on audio, compositing, animation, titling, disc authoring, etc. Mainstream (eg, wide appeal to regular consumers) varies between "came with the computer or camcorder" apps, up to the lower-priced commercial software. In the former category, you have Windows Movie Maker (weak, but pretty much every Windows user has it), iMovie (not as bad, and every Mac user has it), and a bunch of cut-down "SE" or whatever versions of apps from the first category. These are often cut-down versions of the higher-end apps: Adobe Premiere Elements, Sony Vegas Studio, Final Cut Pro Express, etc... and some that just end at "Consumer", like Corel Video Studio, Magix Movie Edit Pro/Video Pro, etc. Many of these are available at several tiers of capabilities... they like to bundle an "SE" version where possible, get users to upgrade from that to the $50-$75 version, and maybe some of them upgrading to the $100+ version. I'm not sure there's much data on what's most popular or not. Adobe seems to be very good at getting their "SE" versions included in OEM deals... they blazed that trail with Adobe Photoshop Elements. Of course, most Mac users are using some version of iMovie or Final Cut, maybe using Avid at the very high end. Sony Vegas is very popular as an upgrade on Windows, but there are literally dozens of choices.
Yup... I use Sony Vegas Pro 9.0 myself. It's a great NLE, and around $500 new. But it did start out as Sonic Foundry's Vegas Pro, which didn't even do video, it was just an audio sequencer/NLE. And a damn fine one. That was the late 1990s. It took better than ten years of professional development (eg, fulltime jobs) to deliver the Vegas you can buy today. Give this guy a break! Vegas won with many users, IMHO, for one big reason: it was very, very reliable. Unlike most of the other NLEs of the day (some still exist, some long gone), it was reliable and modern. You didn't have to format media for use... it worked with pretty much any kind of audio, and once 2.0 was out, video, all on the same timeline. It worked direct.. no need to convert your media to other formats. It didn't crash constantly. Still doesn't. I have not played around with every Linux NLE, nor all that recently. But my experience is, none are all that powerful, and most were way too buggy to consider using. And they were not evolving anywhere near as fast as Vegas. There may be some "warm fuzzies" some folks get using free software, but if you have an actual video editing job to finish, for pay or for fun, you can only struggle so much with the tools you're using before the job isn't really about video anymore, but working around a flawed tool. Open source doesn't help if you lack the skills and or years necessary to fix the bugs in that tool... one of the stated advantages of FOSS, but not always a realistic one (if it were, the same reliability advantages you really do see in Linux these days would translate to applications, but it often doesn't). This seems like a good start.. if Thomas can concentrate on making this work reliably and simply (two of his stated goals), that's an accomplishment for Linux NLEs. Give it some time to get powerful. Linux and FOSS will benefit more from delivering solutions that really work as well as commercial solutions, of any kind, than of delivering unfinished science projects. No matter how cool the science.
If you buy a Microsoft branded retail product, you get a few bits of free support... the amount varied depending on whether its via phone or the internet. But if it's an OEM product (eg, Windows 7 came on that new HP laptop), then it's HP who's required to provide the tech support. At least according to Microsoft... but they will happily let you pay them for it.
There is some customer service from Microsoft. But they have largely been in the same boat as Google... customer support is supposed to come directly from the OEM, unless you're buying from Google or Microsoft directly. That is the business case, not reflective of reality, of course... I really wouldn't expect Verizon to be able to answer any Android question I couldn't answer myself, and I'd only have slightly higher hopes of this from HP in regard to Windows. Wow... I did just upgrade a few machines to Windows 7... guess I actually can ask Microsoft. Though, like many companies these, they charge for the full service after a short time. And all in all, you're probably better off on independent support boards, or search though Google.
That's kind of a lame excuse. There's nothing all that magical about the Nexus One. Yeah, it's a nice Android phone. So is the Mot DROID, and many others. There's nothing particularly new or different in the Nexus One, other than the "front of device" Google branding, versus the "back of the device" Google branding you get on any Google Experience phone. In both cases, the OEMs have no way to limit the content of the device, or change the UI. As for tablets... CES is absolutely swimming with tablets this year. There are over a dozen at the nVidia booth alone. And most of them are running Android. Sure, it's CES, and some of these are definitely technology demonstrations and trial balloons, but some will absolutely hit the market. I have a sneeking suspicion that some of these companies are waiting to see what Apple actually releases... that alone may be what's holding things back. But 5" Android tablets aren't even new... Archos put one out last year. Nokia's been selling Linux tablets for years. The idea that it takes Google to launch a tablet is just silly.
And the thing is, those are not state-of-the-art (as it were) desktop PPC processors. They're older embedded chips, the kind of thing you find in some routers and other network devices (PPC got a big boost in that market, Cisco, at least at one time, had standardized on the PPC for use in network switches and routers). They're not as fast as PPC Macs from quite a few years ago.
Of course, running what's just a basic PPC Amiga port, they SEEM fast. They're fast enough to play some kinds of compressed video, but don't throw HD in AVC at them, or they'll just crawl into a corner and curl up.
We were getting 5-6MB/s sustained throughput with the WD33C93A (the on-board SCSI controller) and the custom DMAC. This was back in the days when PCs and Macs were struggling to deliver better than 1MB/s, and both were using PIO. Even the Mac IIfx, which was the only Mac in the day with a DMA controller, ran PIO when running MacOS (they did DMA for UNIX).
The WD controller was bit CPU intensive compared to the NCR53C710 chip (on the 4091 and the A4000T), sure, but the NCR had a whole SCSI protocol processor on it. It could make intelligent decisions without the need to interrupt the CPU all the time. The WD chip pretty much needed to check with the CPU after every load. It wasn't as slow as the NCR5380 used on many of the Macs of the day.. basically a glorified parallel port, but who cares when you're single tasking. Other than speed... one big advantage of the DMAC was simply that we did 8-bit to 32-bit funneling through a FIFO, so transfers fully used the A3000 bus.
The NCR53C710 chip was so frickin fast, it could actually lock out the CPU for awhile... of course, drives had become a bit faster in those three years, too. This actually screwed up a couple of clever hacks... folks had hooked into the WD chip's interrupt handler to get a ping after every load... some of the first full animation and video (simple compression) from HDD worked this way.
Well, I dunno for sure... I was only working on the higher end machines at the time. You'd do better with a 14Mhz '020 or even EC020 than 20MHz 68000 on most code, thanks to the I-cache, barrel shifter, full 32-bit ALUs, etc. That's the way they went for the A1200.
But also keep in mind, Commodore had been big in the 8-bit world, unit wise, but it was $200-$400 VICs and C64s, in the early 80s, against Apple's $1200-$1600+ Apple ][s, depending on configuration. And the C64 was slightly faster, but not taking seriously. So C= was not quite 1/5th the size of Apple in those days, and they spend less money on R&D as a percentage (and considerably more on the considerably less capable management). So Commodore could not just spin a new system every year, even with clever system-level engineering (eg, no new full custom chips, maybe a gate array or two) on top of the chip stuff.
The custom chips were originally Commodore's key to success, but they did absolutely become a boat anchor. For one, it was several years too late that management finally started letting us go outside for chips... they didn't have to be made at CSG (the old MOS Technology). They had some nice features, like gate arrays turned around in a month, but other issues, like 84 pin limits, one thing that caused so many problems with the A3000 expansion bus. And added cost. One of the AA chips, and all of the AAA chips, were made at HP, in a better CMOS process than C= had at the time.
The "real" 68030 was used because, well, we wanted to use a 68030, the "Embedded Controller" version hadn't been made yet (these used "real" 68030 chips with MMUs that failed the test, at least initially), and, well, you don't put an EC chip in your high-end machine. Also, the A3000 ran UNIX.. the A3000/UX wasn't terribly successful (largely due to Commodore management somewhere pulling their typical stupid moves), but it was the first available System V release 4 outside of AT&T and Sun.
There was no technical problem booting from an '040 card, though yeah, the MMU code from the EPROM version of Kickstart would not run on the '040, they changed the MMU model. So you needed real ROMs, or modified EPROMs. Most users with a reasonable amount of RAM put KickStart in RAM anyway, because it was just faster (still is today).
We actually had a prototype of the first '040 card, the big fat one with external L2 cache designed for UNIX, at the A3000 launch. We were going back and forth with Motorola over whether we could show it, since no one outside Motorola had yet shown off an '040 working in public. They ultimately couriered over a "golden" chip, said "yes", and ... then some fool manager decided we weren't going to show it anyway, at the launch.
There was no official A3000/040 from Commodore, largely because, when the '040 came out, it was unexpectedly hot, and the case designers felt it wasn't viable. Or at least, that was their excuse. I used them for years without issues, and there were many 3rd party '040 cards as well.
While the A3000 had what looks essentially like an '030 bus, it did allow some '040 functions. For example, a well designed '040 card could do burst writes to A3000 DRAM (so could the DMA controller)... the '030 didn't do burst writes. I designed the CPU card interfaces in the A2000 and A3000 -- they were essentially the same as having the CPU on the motherboard, not a compromise. The A4000 didn't even initially bother with a motherboard CPU (they later put one in, to enable a cheaper A4000 with EC030 in it... I was on to other things by then).
The rendering improved, not because of the limitation of the Toaster (full NTSC is full NTSC, you can't get better than that in NTSC), but because they had more CPU cycles. And yeah, while Foundation Imaging used some Pentium Pros (the first P6 systems) starting in 1995, the rendering stack also had Alphas, and all of the animators were using Lightwave on NT-Alpha systems. Which were quite a bit faster than either Pentiums or Amigas in those days.
The original setup at Foundation Imaging had 24 Amiga 2000s with 68040 accelerators and 32MB of DRAM, sixteen of which were dedicated to the rendering stack (developer workstations were brought into the rendering stacks when unused). They used more complex models for the first year of the series than they did for the pilot, each frame took about 45 minutes to render. Each frame was rendered on a single machine, the rendering manager was a homebrew program. The Amigas all shared a Novell network, which included a 12GB (ooh... ahh...) file server.
The OS really had nothing to do with it... Babylon 5 was possible because of NewTek's Lightwave program. Lightwave did great spaceships because Allen Hastings wanted really great spaceships when he wrote the program. It was also entirely made possible because you could get a Toaster, Lightwave, and an Amiga 2000 for much, much less than alternative solutions... particularly when it came out. Things did improve by the time B5 was shot, though it was only the porting of Lightwave to the Alpha (which made perfect sense, given that Commodore was over with by the time Foundation got their Alphas and P6s) that got them to move over.
Near the end of the series, they were also using Macs for video editing, mattes, and compositing, and SGIs for compositing and titling. They also had SoftImage on some of the Alphas, in addtion to Lightwave everywhere. It's nice to have a TV-class production budget, eh?
And sure, monopolies are not inherently illegal.
Abuse of monopoly powers are. You have to have both the monopoly and the abuse of power in order to be acting illegally. Nothing Apple can do in any market constitutes abuse of monopoly powers, simply because they don't have any recognizable monopoly.
AT&T sure did, and flirted with troubles several times. The first anti-trust suit was filed against AT&T in 1912, based on violations of the Sherman Act. They had been been buying up most of the independent phone companies, and also bought a controlling interest in Western Union (the telegraph people), effectively securing a monopoly in wired communications.
But due to the technical problems... that of independents being able to offer long distance independently, and a few other issues, AT&T and the government entered into the "Kingsbury Commitment" in 1913 (named after a AT&T VP). Under these terms, AT&T divested from Western Union, agreed not to take over other independent companies, other than under special rules (eventually this was eliminated by the government, failing independents were not able to be bailed out by AT&T), AT&T agreed to network with independents (sort of.. the indies could call Bell customers, Bell customers could not call the indies), and they agreed to the universal service deal.
They got sued again, in 1949, but didn't make it to court until 1956. In this one, AT&T was prevented from entering markets other than telecommunications, as part of its obligation as a government approved and regulated monopoly. This was actually a move to prevent the split of Western Electric from AT&T, which is what the suit originally called for.
The final suit was started in 1973, with MCI starting a skirmish with AT&T. At the time, AT&T was the world's largest company. This eventually led, in 1982, to a settlement in which the bulk of AT&T would be broken up into AT&T and 7 separate RBOCs.. Regional Bell Operating Companies. I was working at Bell Labs, Holmdel NJ, in the summer of 1982, just before they started sticking little "Death Star" logos over the ID cards of those employees sticking with AT&T, rather than moving (eventually, most went to the Lincroft offices). But this was something AT&T actually helped engineer... once the breakup took place, they were no longer limited to telecommunications.
Of course, those separate companies were sliced and diced and merged and purged, leaving just Verizon and "the new AT&T" standing today. That old Bell Labs building in Holmdel, which housed around 10,000 employees, is probably getting turned into a mall, er, quaint collection of shops and offices (you can't say "Mall" in Holmdel)... I was there just this past fall. Kind of sad, no one's used it for the last two years.
AT&T, "Ma Bell", etc. had a real, legally valid, and legally supported monopoly. They were allowed to have a legal monopoly, and no, it doesn't have to be absolute, but AT&T certainly had a monopoly. The government didn't break them up, and in return, they were required to hook in anyone who wanted phone service, regardless of the cost of wiring them in. And their pricing for basic service was regulated... all things that would not have happened without that bargain (you see this with high speed internet and pay TV... the carriers cherry pick areas they service to maximize profits, and ignore other areas).
The AT&T breakup was the end of that government granted monopoly. Technology had risen to the point that there were no technical issues in merging networks. Local service did rise a bit, but was somewhat help in check via competition. Long distance, which used to be very high as it subsidized local service, fell dramatically. It was all good, but it wouldn't have been in the early days.
Agreed.
When I first learned to write code, it was 1973 and I was 12 years old. Not commenting things worked ok for a few years, when I wrote trivial programs, rarely went back to them, and had a nearly perfect and fairly uncluttered memory.
It wasn't a whole lot different in college. I did learn to write decent comments -- you were sometimes graded on this ability. But again, one project per week in some classes, all your own code, never to be revisited. Comments went one-way... and I'll bet there are coders here who are still at that level.
I got the first hint in my CAD class, which I guess was a Junior or Senior level project engineering course at CMU. In this class, the whole class was engaged in developing the core of a single CAD program. You got everyone else's modules and had to integrate them into the shell of your final project. That was one example of where comments became pretty important.
Here's another one... I started a program sometime in 1986. I wound up working on it, off an on, for the next 12-something years. It became critical to keep things well documented. This was "DiskSalv" for the Amiga computer.
There are other cases.. sometimes, it's that clever hack that took you a long time to figure out. Another Amiga thing was a trick you might find rare these days... you wanted to reset the system without losing your program's control. The problem was simple.. when you hit reset, you normally got a usual 68000 reset vector, but not the one you wanted, necessarily... since upon reset, a ROM magically appeared at the reset vector, and RAM vanished. So I came up with a hack that organized things just so, so I could count on the prefetch buffer allowing me to turn the ROM off and then jump where I wanted. So it was a few lines of code, and all kinds of commenting to explain why this was (far as I know, ever) the only way to do this on any Amiga computer.
Later on, as mentioned in another comment, I worked in places that made comments part of the forrmal documentation... using simple (and not so simple) tools to extract comments from the code, create hypertext links, etc. (on Amiga and later at Scala, Inc.) The ideal place for the documentation on the code is, absolutely, in the code.
Just like programming, the proper use of comments is an art form. Yes, there are plenty of really stupid comments in code... you don't need line-by-line comments describing the obvious behavior of the code. Well, unless you're writing in APL or some other "write-only" language.. no no-trivial line of APL code is obvious. But proper comments should describe functions, large blocks, and classes... not just what they do or how they work, but what you're thinking and why you did things that might be non-obvious, even when the code looks clear and well written.
There can also be commenting formalisms. I have worked at several companies that used some form of "auto-docs"... basically, when you commented a function, you wrote the documentation for folks calling that function from other modules. I put this feature into the interface description language I wrote as part of an object model for an object-based OS. There were both "formal" and "informal" comments. Informal would be used for very specific little details, formal became part of the hypertext (OS/2 or HTML) generated during every build.
And yeah, in any autodoc-type situation, comment maintenance is part of the job, no less important in the long run than the code itself. In fact, potentially much more important... a bug in your code breaks the system at one point. A bug in your autodoc comments can break the code at any number of points.
This same project also had a mess of pretty cool things. Some weren't useful outside of our object model... the compiler generated a database of pre-compiled object tokens. The release system formally enforced the use of the official release version of the compiler from the server, for a formal release (you could use any compiler you wanted to for testing). This release system also sent release packages out to various other sites in our company, automatically installed, compiled, and merged databases during the "catch" process, etc. You could always build identical code on any PC (OS/2 or Windows NT), with no worries about missing libraries, etc. Not much of it was applicable to code development outside of our specific custom OS, but in the end, it was a very cool system.
Intelligent Window Manager.
When you're running an application in AmigaOS, let's say it's so busy, it's not reading window messages (Windows would report this app as "not responding"). For most applications, you could still move the window around, shrink it, grow it back, etc. At worst, the contents of just that window don't refresh. You don't have the window "stuck" not responding, you don't have parts of other windows getting into each other, as you often see in other OSs. You can even resize the window (again, you MAY not see it refresh properly, or you may, depending on the nature of the window itself).
Datatypes
System level objects used everywhere. You don't care about the kind of graphic file or video you're opening, you just open an IMAGE or a VIDEO or a DOCUMENT or whatever in your program, and you can open any of these known to the system. BeOS implemented a similar idea, but I haven't seen it anywhere else. Sure, there are programs that do this for you, and different systems within the same OS to deal with SOME media types. But nothing as complete, not at least that I've seen.
AREXX
Every program of consequence had an AREXX port. Basically, any command the program could understand was available in AREXX (standard scripting language, originally invented at IBM). So you could build very interesting interactions between running programs. Linux users get a taste of this, between a million command lines and pipes, but this was so much more powerful. And very well supported, pretty much in every commercial application.
ASYNCHRONOUS I/O
Every I/O operation to every device driver could be done synchronously or asynchronously. So what becomes a pain in the butt in an OS like Linux was a couple of extra lines of code in AmigaOS. Of course, in those days, there was no point of asynchronous I/O for Windows or MacOS, since they didn't multitask and pretty much had to dedicate the CPU to loading or unloading your I/O, anyway. But it was a beautiful thing in AmigaOS, in the day.
Probably some other stuff, but I gotta go. It's not that I plan on firing up my A3000 when I get home, rather than that home-integrated Q9550 PC with nVidia 8800GT graphics, 8GB RAM, twin 1920x1200 monitors in 24-bit, and 11TB of total attached storage. My old Amiga was weak at electronics CAD, and I'd still be waiting for that first AVC render for Blu-Ray creation to finish... not to mention the lack of support for huge drives and all. But it's a shame when you have to leave behind better ideas just to move forward a bit.
And don't even get me started on word processing... all the power I had with Scribe at CMU in the 80s, to be stuck with things like Word or OpenOffice, it's crime. I do like the WYSIWYG editing, just wish they didn't have to remove 100 IQ points from the formatting engine to get that....
Actually, that's not how the file system worked... it was better than that. It was fully distributed... there was no master index or master directory. Each directory itself was a hash table, and file headers ran independently of directories. So you could destroy every directory on a volume, and still get everything back but the directory details themselves... no lost files. Not that you would.
Going forward, they had planned to add extents... each file header contained a list of blocks, and could chain to the next and so on. This did wind up being pretty large for large files, and was somewhat solved going to larger blocks (it supported both logical and physical blocks of different sizes). There were also some speed issues with smaller files, and at some point, you'd really want to add journaling, but it was pretty resiliant.
Not Diskdoctor, though... that one always had problems. I wrote the freeware DiskSalv, which did much better.
I'm told they let DiskDoctor decide its own fate. They put the sources on a floppy, then ran DiskDoctor on it. The floppy was trashed, so was DiskDoctor.
The lack of abstractions often seems like a good idea at the start, but it doesn't last. Graphics was about the only thing the Amiga didn't always properly abstract, and it definitely held back progress.
Well, yeah... my mobile phone also has a 550MHz CPU, a 400MHz DSP, a GPU running OpenGL and a couple of media processors. Things change over the course of a decade and a half or two.
Actually, some many VGA devices didn't allow changes in-between frames, as some kind of cheap hack to prevent updates of things between frames. Also, you'll find that most graphics cards will jump, and miss a few frames, if you actually change resolution in any complex way. That's because there's a phase-locked-loop-based clock synthesizer in there, generating your video timing. When you change that timing, the PLL has to re-sync, which can take on the order of many milliseconds.
The whole point of Amiga's changing resolution on the fly is kind of gone, anyway... you were trading one kind of graphics mode for another. Any graphics card still worth using these days can give you a full 24-bit color display (or better) on a couple of HDTV+ resolution monitors at once. No need to flip video modes.
Also, the only reason the Amigas didn't have the same PLL problem is that all graphics modes used the same pixel clock, or multiples thereof. That's why you couldn't independently dial in resolution and refresh rate, as you can with modern graphics cards. The never-released AAA chipset actually supported something like five different PLL inputs (the PLLs themselves were not on-chip, which made my life much harder, being the only person who ever built an AAA-chip-based system), along with other hardware to allow mixed modes,
He probably means OS-9/68000, which was kind of the "default" 68K OS to run, if you didn't need a GUI or anything else in those days, but wanted a more or less UNIXy environment. The Philips CD-i project also used OS-9 as its basis.
There is/was a version, called OS-9000, which ran on x86 and a few other CPUs. And back at least when I was attending ATSC conferences, there was another spin of this called "DAVID", intended for smart TV and STBs. That's the last I heard of it, back in the mid 1990s.
Yeah, absolutely. GEM was DRI's graphical environment, which they wrote to live over MS-DOS. When Atari wanted this on the 68K, they could have run it over CP/M-68K, which was actually a better "DOS" than MS-DOS. Unfortunately, there was so much MS-DOS specific crap in GEM, it was easier just to hack together a compatible MS-DOS replacement. That was GEMDOS, which Atari called "TOS".
Anyone confusing GEM/TOS with AmigaOS needs some serious counseling. That's kind of like preferring Windows 3.1 to Ubuntu... maybe someone does, but if so, they're probably very, very misguided individuals.