I'd rather have an open source implementation of a microsoft invention then some proprietary binary (like linux flash).
If those were the only options you might have something. But for the problem that Silverlight is supposed to solve you also have the choice of: a (finally) open source implementation of a Sun invention, and an open source implementation of an open standard, as well as a number of less well known browser plugins (some of which actually provide a real sandbox).
Between Flash, Java, and AJAX we don't need Microsoft barging in with another spin on ActiveX/.NET to "level the field".
You're half-right. Most users don't care about licenses. Most users who even think about licenses don't care about the differences between the BSDL, GPL2, GPL3, or even some random shareware license that lets them use a program for 30 days before they start getting nag dialogs... there's basically two licenses, ones they have to pay money for, and those they don't.
Hell, a lot of *developers* don't care about licenses, and release their code using whatever license they run across first.
On the other hand, "Probably about 80% of your average FreeBSD desktop is GPL'd or some other non-BSD license." is misleading. You could build a Debian GNU/BSD and it would still have a BSD kernel, even if virtually all the userland was GPL. What FreeBSD gets you isn't a GPL-free system... heck, even Microsoft's shipped GPLed software on occasion... what it gets you is a system that doesn't need to be GPLed as a whole. The GPL components are roped off in/usr/src/gnu and/usr/src/contrib, and there's no GPL code in the kernel.
On the gripping hand, no, this won't drive "the vast majority of Linux users" from Linux to BSD. But the article wasn't about end-users, it was about companies that use Linux in their embedded systems, in set-top boxes and routers and mysterious gray boxes on street corners. These are the "users" Justin was writing about. And this is something that the FSF should be concerned about: the GPL has been used to extract the source code to a number of embedded systems, and the GPL3 is an attempt to bring more systems into the fold. But if companies making embedded systems switch from Linux to BSD it could end up having the opposite effect.
That's the thing that boggles my mind. I'm not. I have written documents in raw markup code using "ed" to edit them, and I've written similar documents in Word, and it really was less frustrating to use "ed" to edit things like SGML than to use Word to edit Word documents.
For one obvious example, Word doesn't even get simple stuff like nested lists right.
Move a block of text into a list in HTML, and the block retains all its markup intact while still inheriting markup like fonts and styles, and the list remains intact. Changing a paragraph in the block into a list entry does the right thing.
Do the same thing in Word and depending on how you do it, it either changes the paragraph markup to match the list, or splits the list into two lists. Markup is all or nothing... you have to manually change the font to match the list. Change a block into a list entry then and you end up with duplicate item numbers. And on top of that you may need to manually re-indent parts of the resulting list to the right nesting level.
If there's a table in that block of text things get even hairier. And moving a table into a table and Word will happily merge the cells in the inner table with the outer one. There's ways around this, but you have to plan your edits carefully to keep Word from doing the wrong thing.
Why? Because Word doesn't have any document structure other than paragraphs and table cells. Nesting is simulated by dynamically changing the type of paragraphs in a completely ad-hoc manner. It's nuts.
ODF has to support the Word list style for interoperability (under "numbered paragraphs" where it notes that this can be used as an alternative list style), but the standard way of managing lists is as a nested container that inherits styles from its parent and that child containers... including other lists and paragraphs... inherit styles from in turn.
I can quite easily see myself saving a Word document as ODF, and going in with a plain text editor and fixing up all the list styles directly, rather than trying to figure out the right magic incantations to get Word to do what I want. So, no, I really wasn't exaggerating. Word really is that bad.
OOXML is similar to existing World formats in structure, and so existing code is easily modified to use it, where ODF requires an entirely new approach and so is far harder to add to existing software
I would rather wait another year or two for tools that implement a good spec than get MORE tools that implement Word's fundamentally broken document model. I would rather work in raw HTML 1.0 using ED than try and write anything sophisticated in a program like Word (or Pages, for that matter, which uses the same structure). Unfortunately since I work with people who use these formats, I must adapt.
People are basically jumping on him and calling him a scumbag for having an opinion.
Technical proficiency does not prevent someone from being a scumbag, either, if that's the term you want to use rather than the more diplomatic "unwise". I'm not sure why people are (or even IF people are) jumping up and down on him more for this than for his other pro-Microsoft positions in the past. At the very least, this shouldn't be a horrible surprise...
I've seen this over and over, not only in the tech field. Somebody who is "highly respected" by a great number of people, because of technical proficiency, wisdom, or what have you, expresses an opinion that a lot of people disagree with.
One can disagree with someone without losing sight of their strengths, and respect someone's strengths without losing sight of their weaknesses. In this case: just because someone is technically proficient, that doesn't mean he's wise. I don't consider depending on standards that Microsoft (or any company) controls "wise", whether that's OOXML, CIL, or Silverlight. Miguel's score on the subject is public knowledge.
Not even Steve Jobs can live up to the Steve Jobs hype.
Not living up to the Steve Jobs hype is not "dismal sales".
I can't understand how anybody intelligent would claim Apple cut prices two months after release because it's selling too well.
I'm not seeing that claim here. I'm seeing the claim that sales were "dismal". The distance between "dismal sales" and "selling too well" or "living up to the hype" covers, well, pretty much every product ever made.
Instead, the phone companies should be required to divulge that alternatives exist.
They would just make it unpleasant and expensive enough to get a phone without a contract that it wouldn't matter for most people.
And manufacturers need to be required to make the phones available to domestic resellers under standand warranty sale.
It wold be more useful to make limitations on any warranties (or other restrictions on purchase or use) based on the country violations of free trade agreements.
But that kind of *consumer friendly* interpretation of globalism is about as unlikely as getting laws that force companies in Europe to sell products in the US.
Of course, they are irrelevant to you as a Mac user.
They're also irrelevant to me as a free UNIX user.
several of them are a standard part of Gnome installs
I don't use Gnome on free UNIX. Never have, even when free UNIX was my primary desktop. Gnome and KDE don't give me anything I need or want.
You can't even figure out a five line Mono program,
That's not what "I don't know whether you're showing me a realistic example" means. It's obvious what that code does. The question is this: do real full-blown applications behave the same way, and run completely standalone in a single UNIX process with no long-running shared background process that maintains shared state between separately invoked applications?
unfounded and incorrect claims about how Mono is Microsoft's tool to world domination?
Microsoft doesn't do anything that doesn't support their market share. Microsoft would not be promoting Mono (and they are) if they did not believe it would improve their control over the software business. That's just how Microsoft works.
You might be able to convince me that Mono may be able to have Microsoft's strings removed, but it wouldn't have Microsoft's support if they didn't believe they had those strings in their hands, so don't try and tell me they don't exist.
Especially when at the same time you see strings attached to Apple's open source releases.
I attack them because they are setting bad, proprietary standards and because their PR department makes unfounded statements.
Everyone's PR department makes unfounded and deceptive statements. Even the FSF's. Heck, for many years RMS was pushing people to adopt bad, proprietary GCC extensions to lock people into GCC. The inability to compile GCC-specific code was the biggest factor in killing competing open-source compilers. If you hate Apple for this reason, you should hate the FSF for the same reason.
For that matter, Cocoa is no more proprietary as a standard than Qt or Gtk. There's a single implementation of each, and the API is defined by what that implementation does.
I don't see that open source has any problems on the desktop.
I wish you were right. It took me a while to see why the market was willing to put up with Windows and classic Mac OS, too. It's possible that you'll never have to, that your beliefs will become true, but I don't think it'll happen... too many people just don't see the problems.
The fact that Mono does the same thing as any other OOP on POSIX and provides reasonable high-level classes (in addition to POSIX!) to access files and sockets bothers you? And how exactly are Cocoa's NSInputStream/NSOutputStream any different?
Nobody's writing non-GUI software using Cocoa. Cocoa is a desktop API, it's not a replacement system API. Writing code that works with Cocoa doesn't lock you into Cocoa.
Look at it this way. You can write code on OS X that is completely portable to any other UNIX system. You can write code that you happen to call from Cocoa and it's still useful for someone not using a Mac, not using Cocoa, without using some kind of foreign code gateway.
Mono and.NET completely replace the native API with their own bindings. No part of a program in.NET (or Java, or any other similar API) is directly compatible with any native OS code. You can't develop software using it that links with native code. You can't link native code with it directly, and code you write in it can't be directly used except by Mono or.NET.
Maybe if you lived in a BSD bubble.
Hardly. Until 2000 I was still keeping a Xenix 286 box running so I could make sure my code still compiled and ran on that. I started writing UNIX code on 6th and 7th Edition, I've worked on Xenix, System III, Regulus, Cromix, as well as virtually all the mini and mainframe UNIX variants, through the last System V systems and all the Xenix and SCO UNIX variants, as well as current hybrids, BSD-based systems, and Linux. I've also ported C code between VMS, MS-DOS, Windows, AmigaOS, BeOS, and more... about the only platform where I couldn't write most of my code in a portable way was PalmOS. Writing portable code is a matter of discipline. IF you have the will to do it, you can do it.
So, basically you're saying that you're miffed that your favorite windowing platform didn't win
I have no "favorite windowing platform". I'd like to have had the opportunity to find one, but the ones that looked like they were really trying to address the problem of GUI development in a clean way were all pretty oddball.
I'm miffed that the whole category of GUI API design seems to have been swept aside.
As long as Apple delivers you a BSD command line, a C compiler, and a kernel API, the rest of the world and open source can go to hell.
As long as Apple delivers that, Apple can't lock me in to Apple. As long as Apple delivers that, they are no different than any other vendor that ships a proprietary GUI on top of an open platform.
Any code anyone writes for proprietary systems like Windows or.NET is born locked in. It's not part of the open systems world.
What you're saying is that as long as you can port your proprietary coding environment onto UNIX, the rest of the world and open systems can go to hell.
Here is a lost of Mono/Gtk# applications from 2 years ago; many more have been added, and several ship standard with Ubuntu and Debian.
Interesting. I could go in and attack them as irrelevant-to-me, or attack them for being trivial, the way you were attacking Apple's open source contributions a few messages back, but I won't. I'd just like you to think about why.
As for the Mono example, I don't know enough about it to know whether you're showing me a realistic example or not, but the kinds of symptoms I described have been reported and killing a background process created by the mono runtime does alleviate them. Reading things like "Note: make may fail the first time here, for some unknown reason, running make a second time works." on mono-project.com doesn't instill me with a sense that mono is really a happy participant in the UNIX world.
1. Attacking Apple's participation in the open source community because they're Apple and not Red Hat is stupid.
2. Attacking Apple's participation in the open source community and then trusting Microsoft's participation is insane.
3. Attacking Apple as the source of open source software's problems on the desktop is being willfully blind.
in your ideal world, what relationship would you like to see between the open source world, Apple, and Microsoft?
In my ideal world Microsoft wouldn't have dumped Xenix and would be another UNIX vendor like Apple, Sun, Red Hat, or HP. Obviously, I'm not going to *get* my ideal world, but I'll settle for one where open systems matter to open source people.
That's basically it, I'd like the open source community to care about open systems as well.
Apple, like Microsoft, is just another software company, free of regulation, which is why I don't trust Apple any more than I trust Microsoft.
I'm not asking you to trust Apple.
The difference between Apple-and-Cocoa and Microsoft-and-.NET is this:
Apple is not the source of the underlying API in the system. They don't control UNIX, they don't control the platform they're working on, and they have made sure they can't control it. Unless you need the GUI, software for OS X is just generic UNIX software, it will run natively on any UNIX and Apple can't change the specs under your feet. BECAUSE Apple isn't the source, you don't need to trust them, your software doesn't depend on Apple for anything.
Microsoft controls the underlying.NET API, down to the ground. It doesn't matter whether your.NET software uses a GUI or not, if it's portable then it's using Microsoft-controlled APIs, no matter whether it's written on Mono or.NET.
Why am I going on about the GUI? Because GUIs are a separate battle, and one I don't see how open source can win. And you put your finger on why, even if you can't see it.
Futhermore, I also lived through the UNIX wars. Do you remember them?
Sure. I've been watching them happen again, between KDE and Gnome and between Debian and Red Hat and Ubuntu and Gentoo, It doesn't matter whether the reason for the fragmentation is "my proprietary closed source GUI is better" or "my prorietary open-source GUI is better"... the result is that and users are seeing Apple and Microsoft as the only viable desktops.
There is no open high level GUI standard, there are just a bunch of proprietary ones, some of which are open source, some of which aren't. There's some components like X11 and OpenGL that have a good enough spec that you can have multiple independent implementations that have equivalent strength and control over their destiny, but Qt and Gtk and *step/Cocoa and Microsoft's collection of APIs... they're each pulling their own way like Sun and DEC and AT&T and "Unix International" were. Perhaps a GUI is too complex for an open systems GUI to ever beat out the ones built around a single organization... but we're not going to find out as long as the desktop wars continue.
So the desktop is lost to proprietary systems. I came to that conclusion years ago, after I watched all the really interesting windowing platforms and toolkits fall by the wayside leaving the open-source field to KDE and Gnome on X11. And KDE and Gnome are just Windows-wannabes... and KDE is beholden to *just another software company*, Trolltech.
But below the desktop, at the network and command line, the open APIs were dominant. The same APIs everywhere but Windows, and on Windows you've got a choice of implementations so you CAN run the UNIX command line and Berkeley sockets there as well.
Until.Net and Mono. Now Microsoft's got a foothold there as well. If I despair, I have reason.
You start out saying that contracts shouldn't be banned, and then every point after the first (contracts make financing a new phone simpler) is a problem caused by the ubiquity of contracts or tricks they use to force you into a contract. Delete the first paragraph and the remaining points are all good arguments for banning long-term cellphone contracts.
Every file upload is 10 Linden Dollars (L$10), that's about 3c. Every group you create costs L$100, about 30c. Advertising costs L$. Land is paid for directly in US$, but you can earn that US$ credit in L$, or rent from someone else in L$ who pays monthly in US$... so you can pay for everything in L$, one way or another.
Mono has full bindings to all the standard open source APIs
So does Windows NT. That's the same argument that Microsoft used to claim NT was POSIX compliant. Real Windows applications did not use the POSIX API, they used Microsoft's proprietary API. Virtually all real.NET applications, even written under Mono, are going to be written to Microsoft's APIs... not open ones... because damn few people are going to write Mono apps if they don't plan on them being portable to Windows.
And even aside from that, Mono apps do NOT run like standard UNIX applications on UNIX. Set your environment variables, start up a Mono app, it doesn't see them because it's running in the same background VM as the one you started three hours ago as a side effect of running some other Mono app for some unrelated purpose.
Mono apps do not run native under UNIX, and are not written to UNIX APIs.
And who cares who came up with it? When GNU and Linux started, UNIX was completely controlled by AT&T.
And AT&T did not have a history of creating trojan horses, and they did not create UNIX as a trojen horse. The UNIX API was simple, easy to implement on other operating systems tin a way that left the resulting applications behaving as native applications. AT&T's treatment of UNIX and the UNIX APIs pretty much *created* the open systems movement. The AT&T that existed *at the time UNIX was developed* did everything to *avoid* control. Their turnabout in the '90s (after they finally managed to shake off the inertia of decades as a regulated monopoly) was 20 years too late.
And by the way... Linux is a newcomer. The first non-AT&T implementations of UNIX were in the late '70s, long before Linux and even before GNU and most of the events that led to the GNU manifesto. Linux wouldn't exist without that history of disparate yet interoperable instances of UNIX... no proprietary operating systems could have developed the kind of common code base... outside of UNIX pretty much all you had were user group libraries... each for one particular OS... and high level libraries written in painstakingly portable Fortran. Even non-OS-specific languages like COBOL and Modula made portable application programming painful.
Programmers today have no idea how much work it was writing portable code before UNIX and C... my first programming job was porting COBOL libraries from one Honeywell OS to another. EVEN WITHIN THE SAME VENDOR you didn't have a portable environment for writing code... and there was NO vendor-independent platform for writing portable code other than the Software Tool model of UNIX. Later, I found myself porting a Ratfor compiler from a textbook because it was *easier* to use that to compile Ratfor code from the Software Tools tape than to port a supposedly "portable" Fortran program from a user group tape for the wrong OS. And the Fortran community was more interested in portability than just about ANY group. If AT&T hadn't laid a light hand on UNIX we wouldn't have anything like the open systems and open source environment we do today.
If you didn't live through the start of the open systems revolution you have no idea how messed up things would have been if AT&T had been just another software company like Microsoft, able to act free of regulation.
First of all, Cocoa is "based on" Smalltalk, not UNIX
The low level APIs that are exposed through that interface are *all* UNIX APIs. Even Apple's file system extensions in HFS+ are second-class citizens. A Cocoa application runs as a native UNIX application, without a virtual machine, and properly inherits and uses the UNIX environment it's run under.
Objective-C and Cocoa syntax are completely different from all other UNIX and Linux libraries
The native UNIX APIs are the ones in the UPM, section 2 and some of section 3. Not the ones in the Qt or Gtk manuals.
Syntax? UNIX is an OS, not a programming language. But even so, the native programming lang
Look, Apple's sales targets for the iPhone are insane, you can't take them seriously. Which means that even absolutely staggering success could still leave them far short of the target. I mean "it failed to live up to some of the wilder expectations on Wall Street" is hardly unexpected or crushing news.
In any case, unless you missed it, this is not a stock market being measured. So why is a stock market version of "average" being used here?
OK, normally I'd respond with something like "this isn't limited to the stock market", but I already write that, so not only isn't my response 'no comment', it's right there in the same sentence that mentions stock markets! Did you stop reading half way through "You see variations on rolling averages used in situations from stock market graphs to real-time control systems"?
Rolling averages are used for removing short term fluctuations from a data source. They have been used for years in real time control systems (like this one) to efficiently clean up dirty data sources. The use of this kind of averaging is not only normal and expected, it's something that anyone who had ever written or worked on any software even vaguely similar to this should know about.
Either they're incompetent, or they're looking for things they can use to spin the results the way their customer wants. I suspect they're one of those "professional expert witness" companies, not a legitimate auditing firm at all.
Also, to head off the next obvious attack, I'm not making a claims about the quality of the software in the breathalyzer, I'm making a comment about the quality of the audit.
If it's had dismal sales, then I must be really lucking out, because I've seen more people using iPhones in the past week than I'd have ever imagined. I thought Apple's sales predictions were nuts, ten times too high for something that isn't even really a smartphone *and* required the majority of potential customers to change carriers, but I was totally wrong about that. I'm even getting interested now (not gonna get one until Apple supports a real API* *and* I can get it without changing carriers, though).
* Apple should license PalmOS for it and run it in a sandbox... most PalmOS applications have completely table-driven UI and layout and can be skinned with jello widgets.
I said the same thing when touch wheel interfaces came in. Maybe I'll be wrong.
You weren't really wrong about the touch wheel. See, even if the touch/click wheel interface works for you, it doesn't work for me. This is a general problem when one product or product line becomes dominant in a market... they can get away with marginal designs because a few people on the margin don't matter to them.
I really think that if they do keep a wheel model around it'll be in the midrange. Touch screens will eventually (if not initially) be cheaper to manufacture than wheels. I'm just hoping they keep the low end, or else I'll have to go back to Korea Incorporated models.
Yeh, it's not like you're going to go crazy and load HD movies on it. I mean, 160G is more than my MBP has.
And the new Nano looks like a chiclet. I don't see how they could have avoided that with that sized screen, though. Excepot to go with a touch screen. I suspect this will get replaced by the low end iPod Touch.
The current iPod Touch is really more like the iPhone's equivalent of the Treo 90. I only know one person who got a Treo 90, and it never had any descendants. The iPhone is only $100 more... this really looks like a stopgap until they get their new iPod Classic Touch with hard drive AND touch screen.
I predict the next generation of iPods will all be touch screens but the shuffle. Probably three models: the shuffle with no screen, a new re-streamlined Nano and a couple of hard disk models.
Slashdot Mirror
I'd rather have an open source implementation of a microsoft invention then some proprietary binary (like linux flash).
If those were the only options you might have something. But for the problem that Silverlight is supposed to solve you also have the choice of: a (finally) open source implementation of a Sun invention, and an open source implementation of an open standard, as well as a number of less well known browser plugins (some of which actually provide a real sandbox).
Between Flash, Java, and AJAX we don't need Microsoft barging in with another spin on ActiveX/.NET to "level the field".
You're half-right. Most users don't care about licenses. Most users who even think about licenses don't care about the differences between the BSDL, GPL2, GPL3, or even some random shareware license that lets them use a program for 30 days before they start getting nag dialogs... there's basically two licenses, ones they have to pay money for, and those they don't.
/usr/src/gnu and /usr/src/contrib, and there's no GPL code in the kernel.
Hell, a lot of *developers* don't care about licenses, and release their code using whatever license they run across first.
On the other hand, "Probably about 80% of your average FreeBSD desktop is GPL'd or some other non-BSD license." is misleading. You could build a Debian GNU/BSD and it would still have a BSD kernel, even if virtually all the userland was GPL. What FreeBSD gets you isn't a GPL-free system... heck, even Microsoft's shipped GPLed software on occasion... what it gets you is a system that doesn't need to be GPLed as a whole. The GPL components are roped off in
On the gripping hand, no, this won't drive "the vast majority of Linux users" from Linux to BSD. But the article wasn't about end-users, it was about companies that use Linux in their embedded systems, in set-top boxes and routers and mysterious gray boxes on street corners. These are the "users" Justin was writing about. And this is something that the FSF should be concerned about: the GPL has been used to extract the source code to a number of embedded systems, and the GPL3 is an attempt to bring more systems into the fold. But if companies making embedded systems switch from Linux to BSD it could end up having the opposite effect.
Everybody knows that younger people are getting more of their entertainment from interactive web-based sources (news from the web, online games, etc)
:)
I love getting lumped in with "younger people" like that. Makes me feel like a kid again.
Oh come on. Admit it. You're just exaggerating.
That's the thing that boggles my mind. I'm not. I have written documents in raw markup code using "ed" to edit them, and I've written similar documents in Word, and it really was less frustrating to use "ed" to edit things like SGML than to use Word to edit Word documents.
For one obvious example, Word doesn't even get simple stuff like nested lists right.
Move a block of text into a list in HTML, and the block retains all its markup intact while still inheriting markup like fonts and styles, and the list remains intact. Changing a paragraph in the block into a list entry does the right thing.
Do the same thing in Word and depending on how you do it, it either changes the paragraph markup to match the list, or splits the list into two lists. Markup is all or nothing... you have to manually change the font to match the list. Change a block into a list entry then and you end up with duplicate item numbers. And on top of that you may need to manually re-indent parts of the resulting list to the right nesting level.
If there's a table in that block of text things get even hairier. And moving a table into a table and Word will happily merge the cells in the inner table with the outer one. There's ways around this, but you have to plan your edits carefully to keep Word from doing the wrong thing.
Why? Because Word doesn't have any document structure other than paragraphs and table cells. Nesting is simulated by dynamically changing the type of paragraphs in a completely ad-hoc manner. It's nuts.
ODF has to support the Word list style for interoperability (under "numbered paragraphs" where it notes that this can be used as an alternative list style), but the standard way of managing lists is as a nested container that inherits styles from its parent and that child containers... including other lists and paragraphs... inherit styles from in turn.
I can quite easily see myself saving a Word document as ODF, and going in with a plain text editor and fixing up all the list styles directly, rather than trying to figure out the right magic incantations to get Word to do what I want. So, no, I really wasn't exaggerating. Word really is that bad.
OOXML is similar to existing World formats in structure, and so existing code is easily modified to use it, where ODF requires an entirely new approach and so is far harder to add to existing software
I would rather wait another year or two for tools that implement a good spec than get MORE tools that implement Word's fundamentally broken document model. I would rather work in raw HTML 1.0 using ED than try and write anything sophisticated in a program like Word (or Pages, for that matter, which uses the same structure). Unfortunately since I work with people who use these formats, I must adapt.
People are basically jumping on him and calling him a scumbag for having an opinion.
Technical proficiency does not prevent someone from being a scumbag, either, if that's the term you want to use rather than the more diplomatic "unwise". I'm not sure why people are (or even IF people are) jumping up and down on him more for this than for his other pro-Microsoft positions in the past. At the very least, this shouldn't be a horrible surprise...
I've seen this over and over, not only in the tech field. Somebody who is "highly respected" by a great number of people, because of technical proficiency, wisdom, or what have you, expresses an opinion that a lot of people disagree with.
One can disagree with someone without losing sight of their strengths, and respect someone's strengths without losing sight of their weaknesses. In this case: just because someone is technically proficient, that doesn't mean he's wise.
I don't consider depending on standards that Microsoft (or any company) controls "wise", whether that's OOXML, CIL, or Silverlight. Miguel's score on the subject is public knowledge.
It's failed to live up to the Steve Jobs hype.
Not even Steve Jobs can live up to the Steve Jobs hype.
Not living up to the Steve Jobs hype is not "dismal sales".
I can't understand how anybody intelligent would claim Apple cut prices two months after release because it's selling too well.
I'm not seeing that claim here. I'm seeing the claim that sales were "dismal". The distance between "dismal sales" and "selling too well" or "living up to the hype" covers, well, pretty much every product ever made.
Instead, the phone companies should be required to divulge that alternatives exist.
They would just make it unpleasant and expensive enough to get a phone without a contract that it wouldn't matter for most people.
And manufacturers need to be required to make the phones available to domestic resellers under standand warranty sale.
It wold be more useful to make limitations on any warranties (or other restrictions on purchase or use) based on the country violations of free trade agreements.
But that kind of *consumer friendly* interpretation of globalism is about as unlikely as getting laws that force companies in Europe to sell products in the US.
Of course, they are irrelevant to you as a Mac user.
They're also irrelevant to me as a free UNIX user.
several of them are a standard part of Gnome installs
I don't use Gnome on free UNIX. Never have, even when free UNIX was my primary desktop. Gnome and KDE don't give me anything I need or want.
You can't even figure out a five line Mono program,
That's not what "I don't know whether you're showing me a realistic example" means. It's obvious what that code does. The question is this: do real full-blown applications behave the same way, and run completely standalone in a single UNIX process with no long-running shared background process that maintains shared state between separately invoked applications?
unfounded and incorrect claims about how Mono is Microsoft's tool to world domination?
Microsoft doesn't do anything that doesn't support their market share. Microsoft would not be promoting Mono (and they are) if they did not believe it would improve their control over the software business. That's just how Microsoft works.
You might be able to convince me that Mono may be able to have Microsoft's strings removed, but it wouldn't have Microsoft's support if they didn't believe they had those strings in their hands, so don't try and tell me they don't exist.
Especially when at the same time you see strings attached to Apple's open source releases.
That's what I really don't understand.
I attack them because they are setting bad, proprietary standards and because their PR department makes unfounded statements.
Everyone's PR department makes unfounded and deceptive statements. Even the FSF's. Heck, for many years RMS was pushing people to adopt bad, proprietary GCC extensions to lock people into GCC. The inability to compile GCC-specific code was the biggest factor in killing competing open-source compilers. If you hate Apple for this reason, you should hate the FSF for the same reason.
For that matter, Cocoa is no more proprietary as a standard than Qt or Gtk. There's a single implementation of each, and the API is defined by what that implementation does.
I don't see that open source has any problems on the desktop.
I wish you were right. It took me a while to see why the market was willing to put up with Windows and classic Mac OS, too. It's possible that you'll never have to, that your beliefs will become true, but I don't think it'll happen... too many people just don't see the problems.
The fact that Mono does the same thing as any other OOP on POSIX and provides reasonable high-level classes (in addition to POSIX!) to access files and sockets bothers you? And how exactly are Cocoa's NSInputStream/NSOutputStream any different?
.NET completely replace the native API with their own bindings. No part of a program in .NET (or Java, or any other similar API) is directly compatible with any native OS code. You can't develop software using it that links with native code. You can't link native code with it directly, and code you write in it can't be directly used except by Mono or .NET.
.NET is born locked in. It's not part of the open systems world.
Nobody's writing non-GUI software using Cocoa. Cocoa is a desktop API, it's not a replacement system API. Writing code that works with Cocoa doesn't lock you into Cocoa.
Look at it this way. You can write code on OS X that is completely portable to any other UNIX system. You can write code that you happen to call from Cocoa and it's still useful for someone not using a Mac, not using Cocoa, without using some kind of foreign code gateway.
Mono and
Maybe if you lived in a BSD bubble.
Hardly. Until 2000 I was still keeping a Xenix 286 box running so I could make sure my code still compiled and ran on that. I started writing UNIX code on 6th and 7th Edition, I've worked on Xenix, System III, Regulus, Cromix, as well as virtually all the mini and mainframe UNIX variants, through the last System V systems and all the Xenix and SCO UNIX variants, as well as current hybrids, BSD-based systems, and Linux. I've also ported C code between VMS, MS-DOS, Windows, AmigaOS, BeOS, and more... about the only platform where I couldn't write most of my code in a portable way was PalmOS. Writing portable code is a matter of discipline. IF you have the will to do it, you can do it.
So, basically you're saying that you're miffed that your favorite windowing platform didn't win
I have no "favorite windowing platform". I'd like to have had the opportunity to find one, but the ones that looked like they were really trying to address the problem of GUI development in a clean way were all pretty oddball.
I'm miffed that the whole category of GUI API design seems to have been swept aside.
As long as Apple delivers you a BSD command line, a C compiler, and a kernel API, the rest of the world and open source can go to hell.
As long as Apple delivers that, Apple can't lock me in to Apple. As long as Apple delivers that, they are no different than any other vendor that ships a proprietary GUI on top of an open platform.
Any code anyone writes for proprietary systems like Windows or
What you're saying is that as long as you can port your proprietary coding environment onto UNIX, the rest of the world and open systems can go to hell.
Here is a lost of Mono/Gtk# applications from 2 years ago; many more have been added, and several ship standard with Ubuntu and Debian.
Interesting. I could go in and attack them as irrelevant-to-me, or attack them for being trivial, the way you were attacking Apple's open source contributions a few messages back, but I won't. I'd just like you to think about why.
As for the Mono example, I don't know enough about it to know whether you're showing me a realistic example or not, but the kinds of symptoms I described have been reported and killing a background process created by the mono runtime does alleviate them. Reading things like "Note: make may fail the first time here, for some unknown reason, running make a second time works." on mono-project.com doesn't instill me with a sense that mono is really a happy participant in the UNIX world.
What exactly are you arguing?
1. Attacking Apple's participation in the open source community because they're Apple and not Red Hat is stupid.
2. Attacking Apple's participation in the open source community and then trusting Microsoft's participation is insane.
3. Attacking Apple as the source of open source software's problems on the desktop is being willfully blind.
in your ideal world, what relationship would you like to see between the open source world, Apple, and Microsoft?
In my ideal world Microsoft wouldn't have dumped Xenix and would be another UNIX vendor like Apple, Sun, Red Hat, or HP. Obviously, I'm not going to *get* my ideal world, but I'll settle for one where open systems matter to open source people.
That's basically it, I'd like the open source community to care about open systems as well.
Apple, like Microsoft, is just another software company, free of regulation, which is why I don't trust Apple any more than I trust Microsoft.
.NET API, down to the ground. It doesn't matter whether your .NET software uses a GUI or not, if it's portable then it's using Microsoft-controlled APIs, no matter whether it's written on Mono or .NET.
.Net and Mono. Now Microsoft's got a foothold there as well. If I despair, I have reason.
I'm not asking you to trust Apple.
The difference between Apple-and-Cocoa and Microsoft-and-.NET is this:
Apple is not the source of the underlying API in the system. They don't control UNIX, they don't control the platform they're working on, and they have made sure they can't control it. Unless you need the GUI, software for OS X is just generic UNIX software, it will run natively on any UNIX and Apple can't change the specs under your feet. BECAUSE Apple isn't the source, you don't need to trust them, your software doesn't depend on Apple for anything.
Microsoft controls the underlying
Why am I going on about the GUI? Because GUIs are a separate battle, and one I don't see how open source can win. And you put your finger on why, even if you can't see it.
Futhermore, I also lived through the UNIX wars. Do you remember them?
Sure. I've been watching them happen again, between KDE and Gnome and between Debian and Red Hat and Ubuntu and Gentoo, It doesn't matter whether the reason for the fragmentation is "my proprietary closed source GUI is better" or "my prorietary open-source GUI is better"... the result is that and users are seeing Apple and Microsoft as the only viable desktops.
There is no open high level GUI standard, there are just a bunch of proprietary ones, some of which are open source, some of which aren't. There's some components like X11 and OpenGL that have a good enough spec that you can have multiple independent implementations that have equivalent strength and control over their destiny, but Qt and Gtk and *step/Cocoa and Microsoft's collection of APIs... they're each pulling their own way like Sun and DEC and AT&T and "Unix International" were. Perhaps a GUI is too complex for an open systems GUI to ever beat out the ones built around a single organization... but we're not going to find out as long as the desktop wars continue.
So the desktop is lost to proprietary systems. I came to that conclusion years ago, after I watched all the really interesting windowing platforms and toolkits fall by the wayside leaving the open-source field to KDE and Gnome on X11. And KDE and Gnome are just Windows-wannabes... and KDE is beholden to *just another software company*, Trolltech.
But below the desktop, at the network and command line, the open APIs were dominant. The same APIs everywhere but Windows, and on Windows you've got a choice of implementations so you CAN run the UNIX command line and Berkeley sockets there as well.
Until
Don't worry, if it's good enough for NASA and Dr Schlock, it should be OK for boats.
You start out saying that contracts shouldn't be banned, and then every point after the first (contracts make financing a new phone simpler) is a problem caused by the ubiquity of contracts or tricks they use to force you into a contract. Delete the first paragraph and the remaining points are all good arguments for banning long-term cellphone contracts.
Think of it as a transition drug.
Once she's used to one UNIX desktop, switching to another will be easier.
Every file upload is 10 Linden Dollars (L$10), that's about 3c. Every group you create costs L$100, about 30c. Advertising costs L$. Land is paid for directly in US$, but you can earn that US$ credit in L$, or rent from someone else in L$ who pays monthly in US$... so you can pay for everything in L$, one way or another.
Mono has full bindings to all the standard open source APIs
.NET applications, even written under Mono, are going to be written to Microsoft's APIs... not open ones... because damn few people are going to write Mono apps if they don't plan on them being portable to Windows.
So does Windows NT. That's the same argument that Microsoft used to claim NT was POSIX compliant. Real Windows applications did not use the POSIX API, they used Microsoft's proprietary API. Virtually all real
And even aside from that, Mono apps do NOT run like standard UNIX applications on UNIX. Set your environment variables, start up a Mono app, it doesn't see them because it's running in the same background VM as the one you started three hours ago as a side effect of running some other Mono app for some unrelated purpose.
Mono apps do not run native under UNIX, and are not written to UNIX APIs.
And who cares who came up with it? When GNU and Linux started, UNIX was completely controlled by AT&T.
And AT&T did not have a history of creating trojan horses, and they did not create UNIX as a trojen horse. The UNIX API was simple, easy to implement on other operating systems tin a way that left the resulting applications behaving as native applications. AT&T's treatment of UNIX and the UNIX APIs pretty much *created* the open systems movement. The AT&T that existed *at the time UNIX was developed* did everything to *avoid* control. Their turnabout in the '90s (after they finally managed to shake off the inertia of decades as a regulated monopoly) was 20 years too late.
And by the way... Linux is a newcomer. The first non-AT&T implementations of UNIX were in the late '70s, long before Linux and even before GNU and most of the events that led to the GNU manifesto. Linux wouldn't exist without that history of disparate yet interoperable instances of UNIX... no proprietary operating systems could have developed the kind of common code base... outside of UNIX pretty much all you had were user group libraries... each for one particular OS... and high level libraries written in painstakingly portable Fortran. Even non-OS-specific languages like COBOL and Modula made portable application programming painful.
Programmers today have no idea how much work it was writing portable code before UNIX and C... my first programming job was porting COBOL libraries from one Honeywell OS to another. EVEN WITHIN THE SAME VENDOR you didn't have a portable environment for writing code... and there was NO vendor-independent platform for writing portable code other than the Software Tool model of UNIX. Later, I found myself porting a Ratfor compiler from a textbook because it was *easier* to use that to compile Ratfor code from the Software Tools tape than to port a supposedly "portable" Fortran program from a user group tape for the wrong OS. And the Fortran community was more interested in portability than just about ANY group. If AT&T hadn't laid a light hand on UNIX we wouldn't have anything like the open systems and open source environment we do today.
If you didn't live through the start of the open systems revolution you have no idea how messed up things would have been if AT&T had been just another software company like Microsoft, able to act free of regulation.
First of all, Cocoa is "based on" Smalltalk, not UNIX
The low level APIs that are exposed through that interface are *all* UNIX APIs. Even Apple's file system extensions in HFS+ are second-class citizens. A Cocoa application runs as a native UNIX application, without a virtual machine, and properly inherits and uses the UNIX environment it's run under.
Objective-C and Cocoa syntax are completely different from all other UNIX and Linux libraries
The native UNIX APIs are the ones in the UPM, section 2 and some of section 3. Not the ones in the Qt or Gtk manuals.
Syntax? UNIX is an OS, not a programming language. But even so, the native programming lang
Look, Apple's sales targets for the iPhone are insane, you can't take them seriously. Which means that even absolutely staggering success could still leave them far short of the target. I mean "it failed to live up to some of the wilder expectations on Wall Street" is hardly unexpected or crushing news.
Sheesh.
In any case, unless you missed it, this is not a stock market being measured. So why is a stock market version of "average" being used here?
OK, normally I'd respond with something like "this isn't limited to the stock market", but I already write that, so not only isn't my response 'no comment', it's right there in the same sentence that mentions stock markets! Did you stop reading half way through "You see variations on rolling averages used in situations from stock market graphs to real-time control systems"?
Rolling averages are used for removing short term fluctuations from a data source. They have been used for years in real time control systems (like this one) to efficiently clean up dirty data sources. The use of this kind of averaging is not only normal and expected, it's something that anyone who had ever written or worked on any software even vaguely similar to this should know about.
Either they're incompetent, or they're looking for things they can use to spin the results the way their customer wants. I suspect they're one of those "professional expert witness" companies, not a legitimate auditing firm at all.
Also, to head off the next obvious attack, I'm not making a claims about the quality of the software in the breathalyzer, I'm making a comment about the quality of the audit.
If it's had dismal sales, then I must be really lucking out, because I've seen more people using iPhones in the past week than I'd have ever imagined. I thought Apple's sales predictions were nuts, ten times too high for something that isn't even really a smartphone *and* required the majority of potential customers to change carriers, but I was totally wrong about that. I'm even getting interested now (not gonna get one until Apple supports a real API* *and* I can get it without changing carriers, though).
* Apple should license PalmOS for it and run it in a sandbox... most PalmOS applications have completely table-driven UI and layout and can be skinned with jello widgets.
I said the same thing when touch wheel interfaces came in. Maybe I'll be wrong.
You weren't really wrong about the touch wheel. See, even if the touch/click wheel interface works for you, it doesn't work for me. This is a general problem when one product or product line becomes dominant in a market... they can get away with marginal designs because a few people on the margin don't matter to them.
I really think that if they do keep a wheel model around it'll be in the midrange. Touch screens will eventually (if not initially) be cheaper to manufacture than wheels. I'm just hoping they keep the low end, or else I'll have to go back to Korea Incorporated models.
Yeh, it's not like you're going to go crazy and load HD movies on it. I mean, 160G is more than my MBP has.
And the new Nano looks like a chiclet. I don't see how they could have avoided that with that sized screen, though. Excepot to go with a touch screen. I suspect this will get replaced by the low end iPod Touch.
The current iPod Touch is really more like the iPhone's equivalent of the Treo 90. I only know one person who got a Treo 90, and it never had any descendants. The iPhone is only $100 more... this really looks like a stopgap until they get their new iPod Classic Touch with hard drive AND touch screen.
I predict the next generation of iPods will all be touch screens but the shuffle. Probably three models: the shuffle with no screen, a new re-streamlined Nano and a couple of hard disk models.