I am sure if the GPL was worded in a couple ways OS X would be Linux Based not Unix Based. "UNIX" is, these days, essentially a spec (specifically, the Single UNIX Specification) and a branding. This may sound like a quibble, but OS X is "officially UNIX" because Apple complies with the spec and pays for the branding. Neither Linux or FreeBSD are "UNIX" from a legal standpoint; they're both UNIX-compatible.
At any rate, I think you're assuming a political/copyright choice on Apple's part that's very more likely a historical engineering choice: OS X is a direct descendant of NextStep -- Apple bought Next for their operating system technology, remember? Even though much of the userland support is ported from FreeBSD, under the hood it's very much still NextStep, as anyone who's beat his head against the NetInfo Manager for a while will tell you (possibly in very colorful language). The choice of BSD userland stuff over Linux userland stuff may have been partially license-driven, but -- like FreeBSD, of course -- Apple uses GNU software when necessary or preferred (bash, zsh, groff, etc.).
At any rate, I think corporate hostility to the GPL is overstated; people tend to assume the BSD license is more "business friendly," but they're looking at it from the point of view of a business wanting to use somebody else's open source software in their proprietary product. If you're the copyright holder and want to release your work as open source, you may well prefer to use the GPL or another license that prevents someone from taking your work and stuffing it into a proprietary product.
But Star Trek is just bad. YMMV and all that, but I think it's more fair to say that Star Trek is just uneven. I'd argue that the best episodes of the original series are, at least in terms of writing and ideas, as good as anything since. It's just that the worst episodes are, well, as bad as anything since. I can't think of any TV series offhand, including all of the subsequent Trek series, that were as wildly inconsistent from show to show.
And while I know we shouldn't be judging the special effects of 40 years ago (!) by today's standards, it's pretty hard for folks -- particularly if they've grown up in what might be dubbed the "post-ILM era" -- not to do just that. It's tough these days not to look at an episode like "Arena" and come away remembering nothing but a guy in a lizard suit throwing around foam rocks.
Honestly I could never understand why it gained such traction, maybe since it was first of its kind. Don't underestimate how important that is, actually. There's a lot of stuff in Trek that seems cliche now, but it seems cliche because you've seen variants of it done, with varying degrees of success, on show after show since. It's a nerd version of watching the movie "Casablanca" for the first time: virtually every line in the movie will sound corny and unoriginal, but that's because you've been hearing riffs on them without knowing the original source all your life.
Your observation is fairly, well, obvious, but important to state -- the iPhone's OS is called "OS X 1.0" (it sends back crash reports through iTunes that someone's already dissected, of course), and it clearly has the same heritage as Mac OS X, just like Windows Mobile has the same heritage as other Windows. Windows Mobile has a lot of the same API as "real" Windows, but, well, it's hardly identical, and the crash reports show intriguing differences from iPhone OS X to Mac OS X (and intriguing similarities).
This is important to note, if nothing else, for those who go around saying things like, "If it's OS X, I should be able to load Mac applications on it." Yeah, we'll get back to you on that after you load World of Warcraft on your Treo, Einstein.
Technically, EDGE meets the ITU's definition of what a "3G" standard is, if it's using all 8 timeslots -- that gives EDGE a theoretical maximum of 473.6kbps, and the 3G requirement is 384kbps or above. AT&T's network doesn't meet the ITU 3G qualification currently, although I'm not sure there's any (theoretical) reason it couldn't if they were willing to sink sufficient money into it.
I suppose whether the more likely reached speeds of 150-200kbps for the iPhone are a "deal breaker" really depend on what you're coming from. My current phone, a Sidekick II, uses GPRS, with 40-60kbps speeds more common. While I could bemoan that switching to a first-gen iPhone will give me only a four-fold speed increase instead of sixteen-fold, personally, I can make do with that for a while.
Re:products did not end with a whimper
on
All Things iPhone
·
· Score: 1
The assumption that everyone that responds to pro-Apple propaganda is anti-Apple is preposterous. The assumption that everyone who says positive things about Apple never admits that Apple makes mistakes is also preposterous. Look, dude, either we're both guilty of gross generalization here, or neither of us are.
If I'm sounding a bit acerbic, it's because over the years I've increasingly noticed that you don't actually have to make silly claims like "the Newton is better than modern PDAs" to have people come out and bash you for being an "Apple zealot." All you have to do is admit that you own a Mac and like it. That is invariably enough reason for people to lecture you about Everything Wrong, So Wrong, About Everything Apple, because apparently the act of owning a Macintosh is seen as a rebuke to those who do not. Maybe you think this says something about the zealotry of Apple owners; I think it says a lot more about the insecurity of people who respond that way to Apple owners.
No, the Newton isn't better than a modern PDA. It's a product of its time, and it was a flawed product in many ways. It was also an advanced product in many ways; someone saying "It was ahead of its time" was essentially met in this thread by "no, it sucked ass." The first statement doesn't require the Newton to have been flawless (or even successful); the second statement refuses to acknowledge any positives. Do you see the difference?
Re:products did not end with a whimper
on
All Things iPhone
·
· Score: 1
Mocking a PDA that shipped 14 years ago for having a lot of obsolete technology in it strikes me as, to be kind, dubious. The Newton had its share of problems, but people tend to forget that it predates the Palm Pilot by three years. You don't hear much about the Newton's same-era competition these days.
Incidentally, you can use some PCMCIA wi-fi and ethernet cards in a Newton. Done that lately with a 1996 Palm Pilot?
Apple people will say anything rather than admit that Apple fucks up on occasion. Well, anti-Apple people will say anything rather than admit that Apple deserves praise on occasion, so maybe it all evens out in the end.
Does Japan use some completely different calendar I'm not aware of? Because either my admittedly non-Japanese iCal supports multiple different calendars with multiple different recurring appointments, or my computer is possessed: I have both a 'work' and a 'personal' calendar, and each one has recurring appointments in it.
if Apple insists on keeping the iPhone's API closed...
There's no guarantee that they will. As I responded to someone else earlier, the iPhone's applications are very likely close relatives of OS X's "Dashboard widgets," which means that the "just write Web 2.0 apps" line at WWDC wasn't quite as half-assed as it sounded. (It was still mostly as half-assed as it sounded, don't get me wrong.) Apple may not really have to release what we think of as a conventional SDK at all; they may just need to release a version of the forthcoming Dashcode product that supports iPhones as a target platform.
MS will trundle right over them and relegate the iPhone to the world of the Newton.
It would, but it's quite possible that the 'real' iPhone SDK is awaiting Leopard. The "just write Web 2.0 apps!" line at WWDC was mostly as boneheaded as people take it to be -- but the part that isn't boneheaded is that, from all appearances, the iPhone's UI is essentially the OS X "Dashboard" and the applications on it are widgets. I wouldn't be at all surprised if most of what we're seeing on the iPhone from Apple isn't already web apps; what Apple needs to release isn't as much an SDK as a way to encapsulate web apps as iPhone widgets, much the same way Dashcode will enable people to work on OS X Dashboard widgets. Dashcode won't ship -- at least in final version -- until Leopard. (All together now: "Hmmm.")
While I don't want to speak for Mr. Perens, the problem with relying on "generic description" in this case is that there's room between specific definition in particular and random meaning. If I create a license for my software that's 'more or less' open source -- say, with an advertising clause like the original BSD license -- it'd be very easy to say I violated trademark were there an "open source" trademark that had specific criteria.
Proving that I'm committing fraud by calling it "open source" is an awfully tall order, however. I've told you what my license is; just because you don't think it's open enough doesn't mean I've defrauded you. How about if I give you the source but the license precludes anyone but my company from distributing binaries? How about if I make a closed-source text editor but allow "open source" extensions by defining an API, or just letting you call shell scripts: can I advertise that as "supports open source extensions?" I'm hardly breaking contract law in any of those circumstances.
If "open source" is a generic term, then it's going to be used generically: I give you the source, so hey, I'm being open. I can't define open source as "not giving you the source," but I may well be able to use it in contexts that have restrictions that don't meet any OSI-approved standard.
But the iPhone does "real" internet WORSE than existing phones. The iPhone doesn't support the modern standard for mobile internet, 3G...
Well, let's say "HSDPA" instead of "3G", since 3G is more a marketing term than a technical spec. My (admittedly unconfirmed) suspicion is that Apple developed the iPhone with EDGE because they didn't know which carrier they'd actually sign up with in the States, let alone Europe. They wanted as wide a playing field as possible initially, because they knew it'd be a hard sell to get a carrier to meet all their demands as it was. Would I prefer HSDPA? Yes, even acknowledging the caveats that it's not available in nearly as many markets here, and also acknowledging that the markets HSDPA is already deployed in are big metro areas where you're more likely to find spots you can switch over to wifi.
Having said that: speed isn't everything. Maybe you think the iPhone will be "worse internet" than existing phones, but that depends on what phone you're comparing it to. I have a T-Mobile Sidekick and generally like it, and it's an EDGE-speed device. The iPhone will kick its butt in terms of user experience, because the interface matters a lot. If the Sidekick was HSDPA, would the EDGE-only iPhone still kick its butt? For many web sites: yes. If your mobile browser can't handle Google Maps, it doesn't matter much that it's failing to browse that site at five or six times the speed of the iPhone that's displaying it successfully.
I think (some) people keep failing to recognize what Apple's gambit with the iPhone is: they're betting that its "killer app" is the UI. There's nothing that the iPhone does that other mobile devices don't already do, but there's nothing that does those things the way the iPhone does. It could well end up being a high-profile collapse. But I think it's a fascinating gamble, and it's a variant of one that Apple has pulled off successfully more than once.
That's because nobody actually knows what this killer app is. It's really hard to know, after all, given that PDAs and, well, let's call them "full-API" smartphones have been bouncing around for a decade and clearly don't have this killer app. It apparently has to be something that nobody has any inkling of. Either that, or it's, you know, kind of a strawman argument.
I don't think the lack of the full iPhone API to third-party developers is going to be harmful in the short term. In the long term, what's probably going to happen is that the "native iPhone app" will pretty much be an OS X Dashboard widget: all that Web 2.0 Javascript CSS DHTML stuff, plus access to Cocoa objects. Until then, you're going to have access to iPhone-specific protocol handlers your apps can call, like "call://408-555-1212" or the like, just like many things hook protocol handlers into WebKit on the Mac now. (N.B.: this is what I've heard from people at WWDC, and I presume no NDA is broken by revealing this not-so-dramatic insight.)
Apple's current spin of "you can write web sites and pretend they're iPhone apps! woo!" is blatantly ridiculous, but there's a lot of odd glee about their failure to hand out "Dashcode for iPhone" at WWDC yesterday.
It's very clear, at least to me, that Apple actually thinks they already have the "killer app" for the iPhone, and yes, it is the user interface. Time will tell whether this is insight or mere hubris, but HCI tends to be something Apple is very good at,* and I sure wouldn't write them off just yet.
*This being Slashdot: yes, I know, you, you in the back there: you think it's all eye candy and anyone who sees value in iPods or Macs is a moron and goddamit if vi was good enough for Dennis Ritchie it should be good enough for everyone. You are not anyone's target market, kthxbye.
First they tormented us with Quicktime - a slow player by all standards, which had the audacity to attach itself to every media file on the system, even files it could not play. As if that wasn't bad enough, it crashed more than Windows Media Player.
But look on the bright side: QuickTime for Windows is remarkably ugly.
"The Personal Computer" was an Apple slogan; they didn't call the Apple II+ an "Apple PC," they called it an Apple II+. IBM called the IBM PC the IBM PC. It wasn't a caption on the packaging. It was the computer's name. You may think that's just a matter of semantics, but you really can't underestimate how different those two approaches are in creating the association of "IBM = PC" and, well, "Apple = Apple."
Back when I started being a computer nerd in the late '70s, Apples and TRS-80s and Commodore PETs and (long list of more obscure brands...) were all sometimes called "personal computers," but more often called "microcomputers" by enthusiasts. The term "Personal Computer" came into play because that's what IBM named their first microcomputer: the IBM Personal Computer. That was in 1981. By 1983, programs like PC-Draw and PC-Write and PC-Terminal were shipping from third parties, there was "PC: The Disk Magazine," and companies were advertising games with "Available for Apple II, ColecoVision, and IBM PC."
The Mac, conversely, didn't come out until 1984. By the late '80s, programs were being advertised for IBM PC and/or Mac, and people were referring to "PC clones." The letters "PC" became associated with IBM PCs and compatibles not because of "Mac fanboys," but because IBM called the damn thing the IBM PC. Don't blame "less savvy" Apple users for the confusion between x86 architecture and the term PC -- less savvy IBM users are just as to blame, if not more so.
As for the confusion beween x86 and Windows, well, it didn't get the nickname "Wintel" in the '90s for nothing. The 80x86 line and Windows had a decidedly symbiotic relationship, I'd say. For practical purposes, "PC" did mean computers running Windows; whether or not it offends purists, PC = IBM PC compatible and the number of PC-compatible machines running non-Windows operating systems was extremely neglible for the longest time. One has to actually be pretty familiar with computers to make the distinction between (lower case) "personal computer," "workstation" and "server." (After all, just about anything can be pressed into use as a server, whether or not it's "server-class" hardware.)
Apple went that method (filename case-insensivity) to make things easier for Mac users, actually. HFS+ predates OS X, and it's a direct descendant of HFS from 1985. Remember, OS X may have been, in effect, NextStep 5, but it also had to be MacOS 10 -- a lot of Mac programs depended on HFS's "resource fork" functionality (basically, metadata).
Personally, I'm not sure I see a terribly compelling advantage to either approach. I'm not bothered by case-sensitive file systems at all, having worked with BSD and Linux for years. But you know, I'm not sure I've ever been in a position where it was vitally important to have files named "FOOBAR", "foobar", "Foobar" and "FoObAr" in the same directory.
Acknowledging that we're diving really far down a rat hole here, the historical problem with cut and paste between various X applications occurs when those applications don't know about one another's "clipboards." It wouldn't be very hard to have had a terminal program which did the traditional X mouse-only cut and paste between different terminal windows just fine, and a browser which did ^C/^X/^V pasting within itself just fine... but try cutting and pasting between the terminal program and the browser, and it just didn't happen. I don't know how true that still is. (I was going to use rxvt and Firefox as my example of that not working, as I recall that being a specific issue I had back in 2002, but I just tried it under Xubuntu 7.04 and it worked just fine!)
This is really part of a larger historical issue under X, which is simply that you have several major "toolkits" that developed largely independently of one another, which means that things you can rely on happening at an OS level under Windows and OS X -- like clipboards, printer support, and font management -- happen at a higher level under X. When you end up running applications with different toolkit heritages, the result can be pretty inconsistent. It's better now than it was a decade ago, definitely (the evolution of de facto standards like CUPS, for instance), but font handling can still be a pain in the butt for anyone used to a Mac.
(To be more on topic, I'd have to say that as much as I have a soft spot for the Mac Plus, given a choice I'd rather have the AMD Dual Core running Linux.)
Okay, since you kept saying "look into it," I did.
There are three major sources of lynching statistics. None cover the complete history of lynching in America. Prior to 1882, no reliable statistics of lynchings were recorded. In that year, the Chicago Tribune first began to take systematic account of lynchings. Shortly thereafter, in 1892, Tuskegee Institute began to make a systematic collection and tabulation of lynching statistics. Beginning in 1912, the National Association for the Advancement of Colored People kept an independent record of lynchings.
According to the Tuskegee Institute figures, between the years 1882 and 1951, 4,730 people were lynched in the United States: 3,437 Negro and 1,293 white. The largest number of lynchings occurred in 1892. Of the 230 persons lynched that year, 161 were Negroes and sixty-nine whites.
Between the 1830s and the 1850s the majority of those lynched in the United States were whites. Although a substantial number of white people were victims of this crime, the vast majority of those lynched, by the 1890s and after the turn of the century, were Black people. Actually, the pattern of almost exclusive lynching of Negroes was set during the Reconstruction period. According to the Tuskegee Institute statistics for the period covered in this study, the total number of Black lynching victims was more than two and one-half times as many as the number of whites put to death by lynching.
I think you (and many others) are somewhat missing the point of the article, although the somewhat histrionic headline encourages a "miss the forest for the trees" reading.
I don't think anyone is expecting C or even COBOL to vanish with the speed of PowerBuilder or NetWare; the issue is whether those are actually "growth markets" any more. The article is asserting they're not, and particularly in COBOL's case I'm pretty sure that's correct. COBOL will probably live on for quite some time, but you don't hear much about people deploying new COBOL projects -- you hear about them supporting existing ones that haven't been replaced.
As for "but the OSes are written in C!" as a battle cry: well, yes, they are. But 25 years ago, they sure weren't: C was just too damn big and slow to write an operating system in. What's happened since then? Computers have gotten orders of magnitude faster, RAM and disk space have gotten orders of magnitude bigger, and of course compiler technology has also just gotten better. Couple that with the fact that operating systems and the computers they run on are just a lot more complicated -- having a higher-level language to deal with that, even at the system level, is a real advantage. There's nothing that prevents you from writing an operating system in assembly language now, but under most circumstances you probably wouldn't want to.
The thing is, unless you want to assert that computers twenty years from now will not be much faster and have much more storage and be much more complicated, you can't assert that moving to a higher-level language than C will never be either practical or beneficial even at a system level. I don't expect C to go away or even be relegated to "has-been" status, but I suspect in the long term it isn't a growth skill. It's going to move more deeply into embedded systems and other arenas where small is not merely beautiful but necessary.
The comparison with COBOL may be overstated, but it may not be completely inapt: the fact that there are still COBOL jobs out there and they may actually be fairly high-paying ones doesn't mean that going to school, in 2007, in preparation for a career as a COBOL developer is a bright idea. The same isn't as true for C, but I'm not convinced that's going to stay true for that much longer, let alone indefinitely.
"They" don't want to tax internet connections, speaking generally. "They" is pretty general; there are probably specific proposals out there to tax everything, if you look hard enough, but the germane issue is whether anyone in power is actually listening to the talk.
What's being discussed here, contra the "email tax" headline, really isn't an email tax or any other kind of tax on the net: it's about collecting sales tax on out-of-state sales. As other people have mentioned, this is a "use tax" and all states actually have had it for many years. (The prohibition on states collecting import/export duties on intrastate commerce doesn't apply, as you're not paying for importing/exporting, you're paying for "use." This is pretty arbitrary, although I suppose it's worth noting that trade tariffs and duties--i.e., fees specifically on exporting and importing--were the primary taxes paid by the colonies to the British government, and so were a Very Big Deal at the time the Constitution was written.)
As for why this keeps coming up, well, many states generate a lot of their revenue through sales tax. Even though you were supposed to be paying "use tax" on mail order, the percentage of lost sales tax was fairly small. With the advent of internet commerce, though, a lot of barriers have fallen. It's very easy to order online and very easy to set up businesses online, some of the biggest online-only retailers are edging out big-name "brick and mortar" retailers in terms of sales volume (think Amazon and the iTunes Store, for starters), and this trend is only likely to continue.
And this makes states that depend on sales tax for a big chunk of their revenue really, really nervous. Consumers are never going to consistently pay a "use tax"; this means that the pushback to keep state tax revenues from falling is going to hit the sellers. Traditionally it's been assumed that it's too difficult for sellers to keep track of all those different state tax regulations, as other people have noted--but I have a fairly strong suspicion that we're going to that assumption questioned on the grounds that, well, if it's on the internet, the order's being processed by computer, and the computer can be programmed to know all those rates. (This has the added "advantage" that it'll create a new market for software that knows this, and you can bet there will be lobbyists for accounting software companies supporting these moves rather than fighting them.)
Despite the attempts to make it look like it's just those old tax-and-spend liberal Democrats behind it, this ain't a partisan issue, either. As much pork as there may be in every state budget, an awful lot of programs that I may think are pointless may be ones you think are worthwhile, and vice versa. Government budgets are a lot like Microsoft Office, I suspect: it's easy to get people to agree that only 25% of what's in there is really necessary, but impossible to get them to agree on which 25% that is.
Yeah, that's the point about this suit I find a bit on the bogus side. Given that notebook displays have been showing us "only" 262K colors for years now, one has to wonder whether this is actually something these people would have noticed if it hadn't been pointed out to them. I'm pretty sure I wouldn't have. And, no, I'm not a professional photographer -- but if I were, I'm pretty sure I'd have a big external (and well-calibrated) monitor that didn't have this issue around for my real work.
Is it misleading of Apple to claim "support for millions of colors" on MacBook displays? Yeah, probably. Does the fact that just about everyone else misleads you in the same way excuse that? Probably not. But is there an air of "this sounds like a good way to get money out of everyone's favorite tech target" about this whole thing? Yeah, pretty much.
The problem with that sort of argument isn't that it's not true, it's that it seems to underestimate the waste and bureaucracy that frequently happen in for-profit organizations. Those who believe government agencies are uniquely equipped to produce high overhead have probably never worked at a 25,000+ person corporation. (Or to put it in Slashdot-esque terms, Office Space wasn't about a government agency, after all.)
Somewhat more seriously, it seems to me that the questions around municipal wi-fi are essentially the questions around anything that could be considered a "common infrastructure" issue--with one glaring exception. There are services that states provide and artifacts they construct not because they're somehow intrinsically better at providing them than for-profit companies would be, but because such services are highly beneficial to society or commerce when they're widely available, yet are difficult to make profitable. Utilities, transportation, education, and defense fall into that category (as does medicine, if you're in any industrialized country but the US); they are socialized to varying levels because they're damn difficult to make profitable across most of a society. You either decide they're not a public good and accept that the farther down the economic ladder you go, the harder it will be to purchase such services, or you suck it up and allow those services to be subsidized. (And yes, I'll readily admit I'm on the "go ahead and subsidize" side of that equation; those who treat even things like the Rural Electrification Project as a communist plot bemuse me.)
The glaring exception is, of course, the question of whether public wifi falls into that category. Is it really on the same level of importance as roads and water and electricity? Despite claims I've seen arguing that, it strikes me as a stretch. The argument that data service is becoming the new equivalent to phone service I'd buy, although I'm not even sure what that implies in this context. (Subsidies to rural phone companies and cable companies to offer broadband, perhaps--although I'm not under the impression the cable companies need such motivation.) But data service isn't wi-fi, and given the speed at which this technology is developing, any such network would likely be obsolete within a decade anyway--an issue that electric and telephone lines didn't have to deal with.
Hmm. While I often find myself agreeing with you in Slashdot posts, I have to throw in a whole lot of "well, sometimes" flavored salt in with this one.
Yes, frameworks are always inefficient compared to something tailor-made for a specific case (or even just the set of cases that you customarily deal with across multiple projects). But execution efficiency has never been what (honest) frameworks promise you; what they're after is development efficiency, which is quite a different matter.
Just focusing on Prototype (not Scriptaculous), by using it I can screw around with Ajax in a clearly-defined, well-tested fashion that frees me from worrying about all the mysterious browser incompatibilities that it knows about and already accounts for. I get a lot of very useful extensions that aren't directly related to Ajax (enumerations, getElementsByClassName, just the $, $A, $F, etc. shorthands!). In development time, this can be a pretty big win: a homegrown library can certainly get to Just Where You Want It, but it's not going to start out that way. You're going to spend a much bigger chunk of your development time doing the debugging and tweaking and noodling of your library than the guy using Prototype will, and you're probably going to do more hammering on it to adapt to each new project, unless/until it gets to a point where it's effectively been generalized into, well, a framework.
Yeah, prototype.js is about a 65K hit, and effects.js from Scriptaculous would be another 33K if you loaded it, too; for our friends stuck with modems, that could be another 20 seconds, although for everyone else we're talking about, well, one or two seconds. And only the first time it gets hit during that session (before it's cached).
No, you don't want an unnecessarily porky client-side library piggybacking your HTML, but I'm not convinced the "bloat" they add is always unwelcome. I think the charge of forcing you to structure a project around them is also a little overstated -- Prototype has a few oddities, like the problem with the CSS 'display' attribute you mentioned, but it's hardly the equivalent of CakePHP or Rails in terms of "do it our way or we'll make life hell for you." (Which isn't really a knock against either of those frameworks, but you'd better know you're going to be doing it Their Way going in.)
Why would anyone even think [that a PC can't output good-sounding audio]?
A lot of PCs have historically used really, really cheap components in their audio systems, that introduce noticeable distortion and have crappy signal-to-noise ratios. In some applications, that crappy S/N ratio may just not be good enough. This is not rocket science, and it's certainly not spending $1200 on a power cable. It's just common sense.
And I preemptively apologize for the snappish tone of this, but whenever anyone mentions anything that suggests one might want to buy an audio component higher quality than what you can get at RadioShack, they're immediately hit with "Have you seen the expensive cables audiophiles buy LOL audiophiles are stupid ha ha." Yeah, ha ha, funny funny. There's been "snake oil" in high-end audio for decades. There are also great price-to-performance values, and systems that--as shocking as it may be--really do have measurably better sound.
This is something that I think got missed in a lot of the hullabaloo about net neutrality: people weren't translating from Corporate Executive Speak to Engineer Speak. Instead of thinking about "tiers of service," think about "packet priority" -- giving some packets on the network higher priority and reliability than others. What does this sound like? That's right. We're talking about packet shaping, and the ability to do it has been out there for a long time.
And arguably, some packets on the same network could use higher priority and reliability than others. IP was never designed with the notion that consistent timing (not to mention packet ordering) was important, but as we increasingly start shoving real time data -- voice, streaming audio and video -- down the Great Tubes of the Internet, suddenly that timing does become important. And it makes sense to give those packets higher priority. Remember, lower priority doesn't mean the packets aren't delivered; it means they may be delivered with higher latency, but under all but the crappiest circumstances we're talking about extra milliseconds.
Whether or not it's fair to charge for making packets higher priority is another issue, and certainly worth debating. But this is not quite as nefarious as it's sometimes painted to be. (And remember, you're probably already using a tiered internet service based on how much you pay!)
Slashdot Mirror
At any rate, I think you're assuming a political/copyright choice on Apple's part that's very more likely a historical engineering choice: OS X is a direct descendant of NextStep -- Apple bought Next for their operating system technology, remember? Even though much of the userland support is ported from FreeBSD, under the hood it's very much still NextStep, as anyone who's beat his head against the NetInfo Manager for a while will tell you (possibly in very colorful language). The choice of BSD userland stuff over Linux userland stuff may have been partially license-driven, but -- like FreeBSD, of course -- Apple uses GNU software when necessary or preferred (bash, zsh, groff, etc.).
At any rate, I think corporate hostility to the GPL is overstated; people tend to assume the BSD license is more "business friendly," but they're looking at it from the point of view of a business wanting to use somebody else's open source software in their proprietary product. If you're the copyright holder and want to release your work as open source, you may well prefer to use the GPL or another license that prevents someone from taking your work and stuffing it into a proprietary product.
And while I know we shouldn't be judging the special effects of 40 years ago (!) by today's standards, it's pretty hard for folks -- particularly if they've grown up in what might be dubbed the "post-ILM era" -- not to do just that. It's tough these days not to look at an episode like "Arena" and come away remembering nothing but a guy in a lizard suit throwing around foam rocks. Honestly I could never understand why it gained such traction, maybe since it was first of its kind. Don't underestimate how important that is, actually. There's a lot of stuff in Trek that seems cliche now, but it seems cliche because you've seen variants of it done, with varying degrees of success, on show after show since. It's a nerd version of watching the movie "Casablanca" for the first time: virtually every line in the movie will sound corny and unoriginal, but that's because you've been hearing riffs on them without knowing the original source all your life.
Your observation is fairly, well, obvious, but important to state -- the iPhone's OS is called "OS X 1.0" (it sends back crash reports through iTunes that someone's already dissected, of course), and it clearly has the same heritage as Mac OS X, just like Windows Mobile has the same heritage as other Windows. Windows Mobile has a lot of the same API as "real" Windows, but, well, it's hardly identical, and the crash reports show intriguing differences from iPhone OS X to Mac OS X (and intriguing similarities).
This is important to note, if nothing else, for those who go around saying things like, "If it's OS X, I should be able to load Mac applications on it." Yeah, we'll get back to you on that after you load World of Warcraft on your Treo, Einstein.
Technically, EDGE meets the ITU's definition of what a "3G" standard is, if it's using all 8 timeslots -- that gives EDGE a theoretical maximum of 473.6kbps, and the 3G requirement is 384kbps or above. AT&T's network doesn't meet the ITU 3G qualification currently, although I'm not sure there's any (theoretical) reason it couldn't if they were willing to sink sufficient money into it. I suppose whether the more likely reached speeds of 150-200kbps for the iPhone are a "deal breaker" really depend on what you're coming from. My current phone, a Sidekick II, uses GPRS, with 40-60kbps speeds more common. While I could bemoan that switching to a first-gen iPhone will give me only a four-fold speed increase instead of sixteen-fold, personally, I can make do with that for a while.
If I'm sounding a bit acerbic, it's because over the years I've increasingly noticed that you don't actually have to make silly claims like "the Newton is better than modern PDAs" to have people come out and bash you for being an "Apple zealot." All you have to do is admit that you own a Mac and like it. That is invariably enough reason for people to lecture you about Everything Wrong, So Wrong, About Everything Apple, because apparently the act of owning a Macintosh is seen as a rebuke to those who do not. Maybe you think this says something about the zealotry of Apple owners; I think it says a lot more about the insecurity of people who respond that way to Apple owners.
No, the Newton isn't better than a modern PDA. It's a product of its time, and it was a flawed product in many ways. It was also an advanced product in many ways; someone saying "It was ahead of its time" was essentially met in this thread by "no, it sucked ass." The first statement doesn't require the Newton to have been flawless (or even successful); the second statement refuses to acknowledge any positives. Do you see the difference?
Incidentally, you can use some PCMCIA wi-fi and ethernet cards in a Newton. Done that lately with a 1996 Palm Pilot? Apple people will say anything rather than admit that Apple fucks up on occasion. Well, anti-Apple people will say anything rather than admit that Apple deserves praise on occasion, so maybe it all evens out in the end.
Does Japan use some completely different calendar I'm not aware of? Because either my admittedly non-Japanese iCal supports multiple different calendars with multiple different recurring appointments, or my computer is possessed: I have both a 'work' and a 'personal' calendar, and each one has recurring appointments in it.
if Apple insists on keeping the iPhone's API closed...
There's no guarantee that they will. As I responded to someone else earlier, the iPhone's applications are very likely close relatives of OS X's "Dashboard widgets," which means that the "just write Web 2.0 apps" line at WWDC wasn't quite as half-assed as it sounded. (It was still mostly as half-assed as it sounded, don't get me wrong.) Apple may not really have to release what we think of as a conventional SDK at all; they may just need to release a version of the forthcoming Dashcode product that supports iPhones as a target platform.
MS will trundle right over them and relegate the iPhone to the world of the Newton.
May I interest you in a Zune?
It would, but it's quite possible that the 'real' iPhone SDK is awaiting Leopard. The "just write Web 2.0 apps!" line at WWDC was mostly as boneheaded as people take it to be -- but the part that isn't boneheaded is that, from all appearances, the iPhone's UI is essentially the OS X "Dashboard" and the applications on it are widgets. I wouldn't be at all surprised if most of what we're seeing on the iPhone from Apple isn't already web apps; what Apple needs to release isn't as much an SDK as a way to encapsulate web apps as iPhone widgets, much the same way Dashcode will enable people to work on OS X Dashboard widgets. Dashcode won't ship -- at least in final version -- until Leopard. (All together now: "Hmmm.")
While I don't want to speak for Mr. Perens, the problem with relying on "generic description" in this case is that there's room between specific definition in particular and random meaning. If I create a license for my software that's 'more or less' open source -- say, with an advertising clause like the original BSD license -- it'd be very easy to say I violated trademark were there an "open source" trademark that had specific criteria.
Proving that I'm committing fraud by calling it "open source" is an awfully tall order, however. I've told you what my license is; just because you don't think it's open enough doesn't mean I've defrauded you. How about if I give you the source but the license precludes anyone but my company from distributing binaries? How about if I make a closed-source text editor but allow "open source" extensions by defining an API, or just letting you call shell scripts: can I advertise that as "supports open source extensions?" I'm hardly breaking contract law in any of those circumstances.
If "open source" is a generic term, then it's going to be used generically: I give you the source, so hey, I'm being open. I can't define open source as "not giving you the source," but I may well be able to use it in contexts that have restrictions that don't meet any OSI-approved standard.
But the iPhone does "real" internet WORSE than existing phones. The iPhone doesn't support the modern standard for mobile internet, 3G...
Well, let's say "HSDPA" instead of "3G", since 3G is more a marketing term than a technical spec. My (admittedly unconfirmed) suspicion is that Apple developed the iPhone with EDGE because they didn't know which carrier they'd actually sign up with in the States, let alone Europe. They wanted as wide a playing field as possible initially, because they knew it'd be a hard sell to get a carrier to meet all their demands as it was. Would I prefer HSDPA? Yes, even acknowledging the caveats that it's not available in nearly as many markets here, and also acknowledging that the markets HSDPA is already deployed in are big metro areas where you're more likely to find spots you can switch over to wifi.
Having said that: speed isn't everything. Maybe you think the iPhone will be "worse internet" than existing phones, but that depends on what phone you're comparing it to. I have a T-Mobile Sidekick and generally like it, and it's an EDGE-speed device. The iPhone will kick its butt in terms of user experience, because the interface matters a lot. If the Sidekick was HSDPA, would the EDGE-only iPhone still kick its butt? For many web sites: yes. If your mobile browser can't handle Google Maps, it doesn't matter much that it's failing to browse that site at five or six times the speed of the iPhone that's displaying it successfully.
I think (some) people keep failing to recognize what Apple's gambit with the iPhone is: they're betting that its "killer app" is the UI. There's nothing that the iPhone does that other mobile devices don't already do, but there's nothing that does those things the way the iPhone does. It could well end up being a high-profile collapse. But I think it's a fascinating gamble, and it's a variant of one that Apple has pulled off successfully more than once.
That's because nobody actually knows what this killer app is. It's really hard to know, after all, given that PDAs and, well, let's call them "full-API" smartphones have been bouncing around for a decade and clearly don't have this killer app. It apparently has to be something that nobody has any inkling of. Either that, or it's, you know, kind of a strawman argument.
I don't think the lack of the full iPhone API to third-party developers is going to be harmful in the short term. In the long term, what's probably going to happen is that the "native iPhone app" will pretty much be an OS X Dashboard widget: all that Web 2.0 Javascript CSS DHTML stuff, plus access to Cocoa objects. Until then, you're going to have access to iPhone-specific protocol handlers your apps can call, like "call://408-555-1212" or the like, just like many things hook protocol handlers into WebKit on the Mac now. (N.B.: this is what I've heard from people at WWDC, and I presume no NDA is broken by revealing this not-so-dramatic insight.)
Apple's current spin of "you can write web sites and pretend they're iPhone apps! woo!" is blatantly ridiculous, but there's a lot of odd glee about their failure to hand out "Dashcode for iPhone" at WWDC yesterday.
It's very clear, at least to me, that Apple actually thinks they already have the "killer app" for the iPhone, and yes, it is the user interface. Time will tell whether this is insight or mere hubris, but HCI tends to be something Apple is very good at,* and I sure wouldn't write them off just yet.
*This being Slashdot: yes, I know, you, you in the back there: you think it's all eye candy and anyone who sees value in iPods or Macs is a moron and goddamit if vi was good enough for Dennis Ritchie it should be good enough for everyone. You are not anyone's target market, kthxbye.
First they tormented us with Quicktime - a slow player by all standards, which had the audacity to attach itself to every media file on the system, even files it could not play. As if that wasn't bad enough, it crashed more than Windows Media Player.
But look on the bright side: QuickTime for Windows is remarkably ugly.
"The Personal Computer" was an Apple slogan; they didn't call the Apple II+ an "Apple PC," they called it an Apple II+. IBM called the IBM PC the IBM PC. It wasn't a caption on the packaging. It was the computer's name. You may think that's just a matter of semantics, but you really can't underestimate how different those two approaches are in creating the association of "IBM = PC" and, well, "Apple = Apple."
I think I'd disagree with this timeline.
Back when I started being a computer nerd in the late '70s, Apples and TRS-80s and Commodore PETs and (long list of more obscure brands...) were all sometimes called "personal computers," but more often called "microcomputers" by enthusiasts. The term "Personal Computer" came into play because that's what IBM named their first microcomputer: the IBM Personal Computer. That was in 1981. By 1983, programs like PC-Draw and PC-Write and PC-Terminal were shipping from third parties, there was "PC: The Disk Magazine," and companies were advertising games with "Available for Apple II, ColecoVision, and IBM PC."
The Mac, conversely, didn't come out until 1984. By the late '80s, programs were being advertised for IBM PC and/or Mac, and people were referring to "PC clones." The letters "PC" became associated with IBM PCs and compatibles not because of "Mac fanboys," but because IBM called the damn thing the IBM PC. Don't blame "less savvy" Apple users for the confusion between x86 architecture and the term PC -- less savvy IBM users are just as to blame, if not more so.
As for the confusion beween x86 and Windows, well, it didn't get the nickname "Wintel" in the '90s for nothing. The 80x86 line and Windows had a decidedly symbiotic relationship, I'd say. For practical purposes, "PC" did mean computers running Windows; whether or not it offends purists, PC = IBM PC compatible and the number of PC-compatible machines running non-Windows operating systems was extremely neglible for the longest time. One has to actually be pretty familiar with computers to make the distinction between (lower case) "personal computer," "workstation" and "server." (After all, just about anything can be pressed into use as a server, whether or not it's "server-class" hardware.)
Apple went that method (filename case-insensivity) to make things easier for Mac users, actually. HFS+ predates OS X, and it's a direct descendant of HFS from 1985. Remember, OS X may have been, in effect, NextStep 5, but it also had to be MacOS 10 -- a lot of Mac programs depended on HFS's "resource fork" functionality (basically, metadata).
Personally, I'm not sure I see a terribly compelling advantage to either approach. I'm not bothered by case-sensitive file systems at all, having worked with BSD and Linux for years. But you know, I'm not sure I've ever been in a position where it was vitally important to have files named "FOOBAR", "foobar", "Foobar" and "FoObAr" in the same directory.
Acknowledging that we're diving really far down a rat hole here, the historical problem with cut and paste between various X applications occurs when those applications don't know about one another's "clipboards." It wouldn't be very hard to have had a terminal program which did the traditional X mouse-only cut and paste between different terminal windows just fine, and a browser which did ^C/^X/^V pasting within itself just fine... but try cutting and pasting between the terminal program and the browser, and it just didn't happen. I don't know how true that still is. (I was going to use rxvt and Firefox as my example of that not working, as I recall that being a specific issue I had back in 2002, but I just tried it under Xubuntu 7.04 and it worked just fine!)
This is really part of a larger historical issue under X, which is simply that you have several major "toolkits" that developed largely independently of one another, which means that things you can rely on happening at an OS level under Windows and OS X -- like clipboards, printer support, and font management -- happen at a higher level under X. When you end up running applications with different toolkit heritages, the result can be pretty inconsistent. It's better now than it was a decade ago, definitely (the evolution of de facto standards like CUPS, for instance), but font handling can still be a pain in the butt for anyone used to a Mac.
(To be more on topic, I'd have to say that as much as I have a soft spot for the Mac Plus, given a choice I'd rather have the AMD Dual Core running Linux.)
Okay, since you kept saying "look into it," I did.
(Source: "Lynching and Race Riots in the United States, 1880-1950")
As long as you concentrate on a specific pre-Civil War period, you're right. If you look over a whole century of data, however, not so much.
I think you (and many others) are somewhat missing the point of the article, although the somewhat histrionic headline encourages a "miss the forest for the trees" reading.
I don't think anyone is expecting C or even COBOL to vanish with the speed of PowerBuilder or NetWare; the issue is whether those are actually "growth markets" any more. The article is asserting they're not, and particularly in COBOL's case I'm pretty sure that's correct. COBOL will probably live on for quite some time, but you don't hear much about people deploying new COBOL projects -- you hear about them supporting existing ones that haven't been replaced.
As for "but the OSes are written in C!" as a battle cry: well, yes, they are. But 25 years ago, they sure weren't: C was just too damn big and slow to write an operating system in. What's happened since then? Computers have gotten orders of magnitude faster, RAM and disk space have gotten orders of magnitude bigger, and of course compiler technology has also just gotten better. Couple that with the fact that operating systems and the computers they run on are just a lot more complicated -- having a higher-level language to deal with that, even at the system level, is a real advantage. There's nothing that prevents you from writing an operating system in assembly language now, but under most circumstances you probably wouldn't want to.
The thing is, unless you want to assert that computers twenty years from now will not be much faster and have much more storage and be much more complicated, you can't assert that moving to a higher-level language than C will never be either practical or beneficial even at a system level. I don't expect C to go away or even be relegated to "has-been" status, but I suspect in the long term it isn't a growth skill. It's going to move more deeply into embedded systems and other arenas where small is not merely beautiful but necessary.
The comparison with COBOL may be overstated, but it may not be completely inapt: the fact that there are still COBOL jobs out there and they may actually be fairly high-paying ones doesn't mean that going to school, in 2007, in preparation for a career as a COBOL developer is a bright idea. The same isn't as true for C, but I'm not convinced that's going to stay true for that much longer, let alone indefinitely.
"They" don't want to tax internet connections, speaking generally. "They" is pretty general; there are probably specific proposals out there to tax everything, if you look hard enough, but the germane issue is whether anyone in power is actually listening to the talk.
What's being discussed here, contra the "email tax" headline, really isn't an email tax or any other kind of tax on the net: it's about collecting sales tax on out-of-state sales. As other people have mentioned, this is a "use tax" and all states actually have had it for many years. (The prohibition on states collecting import/export duties on intrastate commerce doesn't apply, as you're not paying for importing/exporting, you're paying for "use." This is pretty arbitrary, although I suppose it's worth noting that trade tariffs and duties--i.e., fees specifically on exporting and importing--were the primary taxes paid by the colonies to the British government, and so were a Very Big Deal at the time the Constitution was written.)
As for why this keeps coming up, well, many states generate a lot of their revenue through sales tax. Even though you were supposed to be paying "use tax" on mail order, the percentage of lost sales tax was fairly small. With the advent of internet commerce, though, a lot of barriers have fallen. It's very easy to order online and very easy to set up businesses online, some of the biggest online-only retailers are edging out big-name "brick and mortar" retailers in terms of sales volume (think Amazon and the iTunes Store, for starters), and this trend is only likely to continue.
And this makes states that depend on sales tax for a big chunk of their revenue really, really nervous. Consumers are never going to consistently pay a "use tax"; this means that the pushback to keep state tax revenues from falling is going to hit the sellers. Traditionally it's been assumed that it's too difficult for sellers to keep track of all those different state tax regulations, as other people have noted--but I have a fairly strong suspicion that we're going to that assumption questioned on the grounds that, well, if it's on the internet, the order's being processed by computer, and the computer can be programmed to know all those rates. (This has the added "advantage" that it'll create a new market for software that knows this, and you can bet there will be lobbyists for accounting software companies supporting these moves rather than fighting them.)
Despite the attempts to make it look like it's just those old tax-and-spend liberal Democrats behind it, this ain't a partisan issue, either. As much pork as there may be in every state budget, an awful lot of programs that I may think are pointless may be ones you think are worthwhile, and vice versa. Government budgets are a lot like Microsoft Office, I suspect: it's easy to get people to agree that only 25% of what's in there is really necessary, but impossible to get them to agree on which 25% that is.
Yeah, that's the point about this suit I find a bit on the bogus side. Given that notebook displays have been showing us "only" 262K colors for years now, one has to wonder whether this is actually something these people would have noticed if it hadn't been pointed out to them. I'm pretty sure I wouldn't have. And, no, I'm not a professional photographer -- but if I were, I'm pretty sure I'd have a big external (and well-calibrated) monitor that didn't have this issue around for my real work.
Is it misleading of Apple to claim "support for millions of colors" on MacBook displays? Yeah, probably. Does the fact that just about everyone else misleads you in the same way excuse that? Probably not. But is there an air of "this sounds like a good way to get money out of everyone's favorite tech target" about this whole thing? Yeah, pretty much.
The problem with that sort of argument isn't that it's not true, it's that it seems to underestimate the waste and bureaucracy that frequently happen in for-profit organizations. Those who believe government agencies are uniquely equipped to produce high overhead have probably never worked at a 25,000+ person corporation. (Or to put it in Slashdot-esque terms, Office Space wasn't about a government agency, after all.)
Somewhat more seriously, it seems to me that the questions around municipal wi-fi are essentially the questions around anything that could be considered a "common infrastructure" issue--with one glaring exception. There are services that states provide and artifacts they construct not because they're somehow intrinsically better at providing them than for-profit companies would be, but because such services are highly beneficial to society or commerce when they're widely available, yet are difficult to make profitable. Utilities, transportation, education, and defense fall into that category (as does medicine, if you're in any industrialized country but the US); they are socialized to varying levels because they're damn difficult to make profitable across most of a society. You either decide they're not a public good and accept that the farther down the economic ladder you go, the harder it will be to purchase such services, or you suck it up and allow those services to be subsidized. (And yes, I'll readily admit I'm on the "go ahead and subsidize" side of that equation; those who treat even things like the Rural Electrification Project as a communist plot bemuse me.)
The glaring exception is, of course, the question of whether public wifi falls into that category. Is it really on the same level of importance as roads and water and electricity? Despite claims I've seen arguing that, it strikes me as a stretch. The argument that data service is becoming the new equivalent to phone service I'd buy, although I'm not even sure what that implies in this context. (Subsidies to rural phone companies and cable companies to offer broadband, perhaps--although I'm not under the impression the cable companies need such motivation.) But data service isn't wi-fi, and given the speed at which this technology is developing, any such network would likely be obsolete within a decade anyway--an issue that electric and telephone lines didn't have to deal with.
Hmm. While I often find myself agreeing with you in Slashdot posts, I have to throw in a whole lot of "well, sometimes" flavored salt in with this one.
Yes, frameworks are always inefficient compared to something tailor-made for a specific case (or even just the set of cases that you customarily deal with across multiple projects). But execution efficiency has never been what (honest) frameworks promise you; what they're after is development efficiency, which is quite a different matter.
Just focusing on Prototype (not Scriptaculous), by using it I can screw around with Ajax in a clearly-defined, well-tested fashion that frees me from worrying about all the mysterious browser incompatibilities that it knows about and already accounts for. I get a lot of very useful extensions that aren't directly related to Ajax (enumerations, getElementsByClassName, just the $, $A, $F, etc. shorthands!). In development time, this can be a pretty big win: a homegrown library can certainly get to Just Where You Want It, but it's not going to start out that way. You're going to spend a much bigger chunk of your development time doing the debugging and tweaking and noodling of your library than the guy using Prototype will, and you're probably going to do more hammering on it to adapt to each new project, unless/until it gets to a point where it's effectively been generalized into, well, a framework.
Yeah, prototype.js is about a 65K hit, and effects.js from Scriptaculous would be another 33K if you loaded it, too; for our friends stuck with modems, that could be another 20 seconds, although for everyone else we're talking about, well, one or two seconds. And only the first time it gets hit during that session (before it's cached).
No, you don't want an unnecessarily porky client-side library piggybacking your HTML, but I'm not convinced the "bloat" they add is always unwelcome. I think the charge of forcing you to structure a project around them is also a little overstated -- Prototype has a few oddities, like the problem with the CSS 'display' attribute you mentioned, but it's hardly the equivalent of CakePHP or Rails in terms of "do it our way or we'll make life hell for you." (Which isn't really a knock against either of those frameworks, but you'd better know you're going to be doing it Their Way going in.)
Why would anyone even think [that a PC can't output good-sounding audio]?
A lot of PCs have historically used really, really cheap components in their audio systems, that introduce noticeable distortion and have crappy signal-to-noise ratios. In some applications, that crappy S/N ratio may just not be good enough. This is not rocket science, and it's certainly not spending $1200 on a power cable. It's just common sense.
And I preemptively apologize for the snappish tone of this, but whenever anyone mentions anything that suggests one might want to buy an audio component higher quality than what you can get at RadioShack, they're immediately hit with "Have you seen the expensive cables audiophiles buy LOL audiophiles are stupid ha ha." Yeah, ha ha, funny funny. There's been "snake oil" in high-end audio for decades. There are also great price-to-performance values, and systems that--as shocking as it may be--really do have measurably better sound.
...although this isn't why.
This is something that I think got missed in a lot of the hullabaloo about net neutrality: people weren't translating from Corporate Executive Speak to Engineer Speak. Instead of thinking about "tiers of service," think about "packet priority" -- giving some packets on the network higher priority and reliability than others. What does this sound like? That's right. We're talking about packet shaping, and the ability to do it has been out there for a long time.
And arguably, some packets on the same network could use higher priority and reliability than others. IP was never designed with the notion that consistent timing (not to mention packet ordering) was important, but as we increasingly start shoving real time data -- voice, streaming audio and video -- down the Great Tubes of the Internet, suddenly that timing does become important. And it makes sense to give those packets higher priority. Remember, lower priority doesn't mean the packets aren't delivered; it means they may be delivered with higher latency, but under all but the crappiest circumstances we're talking about extra milliseconds.
Whether or not it's fair to charge for making packets higher priority is another issue, and certainly worth debating. But this is not quite as nefarious as it's sometimes painted to be. (And remember, you're probably already using a tiered internet service based on how much you pay!)