What people seem to be forgetting is that service providers only want a phone with a music player if they can provide the music.
Yep. If you just want a phone with a music player, the Pocket PC Phone Edition has been out for a while. There's nothing new in that capability, and it's definitely not an iPod killer. Not even an iPod Shuffle killer. If it was, that would already have happened.
I've already been in Bill's fantasy world. The results of being able to play MP3s on my Pocket PC Phone edition was that the battery in the phone was flat when I needed to use it as a phone.
But only once.
I solved the problem of music flattening the battery on my phone by not using it as anything but a phone. It's an easy and obvious solution, and works well. It's also the solution to the problem of using my phone as a handheld videogame or an e-book reader and having THAT flatten the battery. You can tell when you're onto something when you solve one problem and it takes care of a bunch of others.
I solved the problem of having a phone that actually crashed and had to reboot by getting a simple phone that was just a phone. AND it got better battery life still. It's amazing how that works out.
Re:Its only the bad things we head about?
on
Safari vs. KHTML
·
· Score: 2, Informative
I've found a few googling around using likely strings, like this one...
date: 2003/06/13 00:14:07; author: jkh; state: Exp; lines: +6 -6 Fixes to locale code to properly use indirect pointers in order to prevent memory leaks (fixes bugs earlier purported to be fixed). Submitted by: Ed Moy <emoy at apple.com> Obtained from: Apple Computer, Inc. MFC after: 2 weeks
Try something as simple as moving the window widgets (eg close button) to the right side.
Mind if I repeat something I wrote a couple of messages back: "These apps don't just change the window borders, they change every detail of every control in every application."
Hey, having the ability to change from one window manager to another is a really neat idea. It lets people install Enlightenment and think they're customizing the user interface, because they can customize the window borders in ways no sane person would dream of. But they're not, they're just customizing one application.
On the Mac that particular application is less customizable, at least in that way. But others are more so. For example, you can go in to any regular Cocoa application and a lot of Carbon ones and move *all* the widgets around, rename or move menu items, even copy them from one part of the program to another.
Also, the method for theming in OSX is a hack. You can see the results of this -- some applications get past shapeshifter without being themed.
If I open up an xterm... you know what, it doesn't use my Qt theme! Why is that? Is it because Qt theming is a hack, or is it because it's using Athena Widgets instead of Qt? Of course nobody would say Qt theming was a hack, but the fact is there's so many competing toolkits on X11 that this is normal and expected. There's nothing you can do about it except to exterminate all the competitors (you have to provide your own cyborgs).
In Mac OS X, on the other hand, there are only two official toolkits... so the theming that's built into it at a low level is well supported, and every app that uses Carbon, Cocoa, or even many of the third-party toolkits (because they look up the theme and follow it) will follow the themes.
Re:Its only the bad things we head about?
on
Safari vs. KHTML
·
· Score: 1
I'd imagine he (or she) was saying something along the lines of...
You don't have to imagine. The text is right there.
Re:I see nothing wrong with it
on
Safari vs. KHTML
·
· Score: 4, Insightful
If they would just shut the hell up then we could look at Apple as what they are, a passive OSS user.
You have obviously never looked at how companies that are really passive open source software users behave. Microsoft, for example.
Right now Apple is putting some really interesting code out there for people to pick up. They've provided a framework in darwin for completely changing the way UNIX systems are managed, in nicely packaged tools like launchd, complete with "configure" scripts ready for dropping in peicemeal or packaging for debian or Red Hat.
There's a whole damned revolution waiting on opensource.apple.com and nobody's paying attention to it. Why? because it's from Apple? because nobody knows it's there? Because it's not the Linux Way? I don't know. You tell me.
Apple has always imposed the most limits on the user's ability to customize his computer look and feel of any OS.
Actually, Mac OS X is extremely customizable down to a very low level. Apple doesn't give you a nice GUI for making these changes, because they consider the look and feel a brand, but neither have they made any deliberate effort to prevent people from providing the missing components. In fact, if they didn't hold their developers responsible for maintaining that look and feel it would be harder to go in and modify the GUI.
The company that is currently doing the most to take advantage of and develop the various hooks Apple has provided is Unsanity, and Shapeshifter is the premier tool of this type:
And there have been other applications going all the way back to Kaleidoscope on Mac OS 8. These apps don't just change the window borders, they change every detail of every control in every application... and Kaleidoscope did it first.
Re:Its only the bad things we head about?
on
Safari vs. KHTML
·
· Score: 1
Patch dumps clearly aren't the preferred form according to the original developers.
OK, would this be better: how about a complete compilable source tree with changes specific to Apple's code marked out with ifdefs?
Re:Its only the bad things we head about?
on
Safari vs. KHTML
·
· Score: 3, Interesting
The LGPL says that changes have to be returned in the "preferred form" for exactly this reason
OK, I'm trying to figure out a definition of "the preferred form" that means "compatible with a toolkit they're not even using". Because that's a huge problem... the changes Apple's made involve porting what started out as KHTML to a completely different API, and no matter how frequently Apple released the patches, or in what sized chunks they released the patches, they'd still be full of changes related to the fact that Apple's APIs have evolved along a completely separate path from X11 for their entire lives. Carbon's API can be traced all the way back to the original Macintosh, and Cocoa is based on the NeXT ObjectiveC + Adobe Display Postscript code... and there's only one X11 toolkit that either of those APIs have any relationship at all with, and it's neither of the Big Two.
The only way to keep that from being a problem would be to have both projects agree to a common API for the GUI, and stick to it.
Do you honestly see that happening? Especially since the best compromise technically would involve the KDE people switching to GNUstep.
Re:Its only the bad things we head about?
on
Safari vs. KHTML
·
· Score: 1
the GPL would have prevented all this
The GPL would have prevented Apple from releasing their divergent source tree in a way that the KDE people couldn't use it? I'm not sure I understand... I don't recall anything in the GPL that would have obligated Apple to do anything they're not already doing.
That could actually be kind of cool. If Apple has to release patches that are compatible with a toolkit they're not actually using, then does that mean KDE would have to do the same thing? That would be one way to untangle the incestuous web of internal dependencies that keep the KDE and Gnome worlds apart. I vote for using GNUstep as the glue layer.
Re:Its only the bad things we head about?
on
Safari vs. KHTML
·
· Score: 2, Interesting
Apple just spit on their courtesy
Are you honestly saying that Apple deliberately made their patches as hard as possible to deal with out of malice? Or are you just using a provocative phrase because you're upset that it hasn't worked out the way you expected, and whether Apple was honestly trying to be helpful despite their rapidly diverging source tree or not you feel justified in taking your disappointment out on them?
If my Linux system is going to be hacked, even if the guy doesn't have a rootkit that'll work on me I'm going to have to reinstall anyway.
And yes, there's Linux software you can't easily port to OS X (or FreeBSD, or Solaris, or Tru64, or HPUX...), but then there's Linux software you can't run on PPC because it's binary-only... so you're still better off with an x86 Linux box.
Sugar-coated or not, however, it is still a restriction and places the license outside of the realm of Free Software licenses.
If having a restriction places a license outside the realm of free software licenses, then the only license that's free is placing the software in the public domain. EVERY other license places a restriction on the licensee, however light that restriction may be. Whatever other advantages it may give them indirectly, it still restricts their actions.
That's the whole purpose of retaining copyright and attaching a license.
The GPL established the precedent that you can have a significant restriction that's very broadly applicable, and still have that software be considered "free", if that restriction supported the goal of promoting the otherwise unencumbered use of free software. Well, the APSL has a restriction... but, you know what, that restriction ALSO supports that goal. It would have been better, in fact, if it were broader and thus more restrictive.
If you think software patents are, on balance, a good thing... well, you might not like this conclusion. I don't know if that's your position, but it's certainly NOT the position of a significant number of the members of the FSF (certainly not the ones who are also members of the LPF). And if you want to convince pretty much anyone that the APSL is non-free, you're going to have to start by dealing with that.
Yeh, for a long time I was able to get the same kind of value from the FreeBSD source tree when I was trying to deal with problems in early versions of Tru64 (Digital UNIX, OSF/1) as a network admin. It's not that you need this stuff that often, but when you need it it makes a BIG difference.
I'd love to know an x86 that comes in the same form factor as the mini with comparable performance.
"paperback"? Well, maybe, if you count something half the size of a phonebook as a "paperback". But, yeh, it's pretty small thanks to its laptop technology. So let's see what you can get in the PC world if you use similar techniques...
Googling around it took me about a minute to find a 1.13 GHz Pentium III laptop for $530. That's a bit slower than a mini, but not by much, and that includes a display, keyboard, and mouse... and wireless.
Every time someone posts a GPL-violation story here, there's always an AC making this same comment with almost exactly the same wording, despite the fact that every time he makes it a bunch of people (1) point out that they are pro-GPL but don't engage in or promote violating music or video copyrights, (2) explain why there are legitimate reasons to oppose DRM that have nothing to do with the inconvenience it adds to playing illicitly acquired media, and (3) point to examples of successful online vendors that shun DRM... so even if the AC hasn't always read the followups he'd have to be deliberately remaining ignorant to miss them all.
I wonder whether he's being paid by Microsoft or the RIAA.
When you're testing software, it has to be in the environment that it will run on in production. If it's expected to run on Linux PPC, you test it on Linux PPC.
That just begs the question "why are you running LinuxPPC in production"?
Slashdot Mirror
you cannot install Firefox over another copy of Firefox without having two versions in "Add/Remove Programs" in Windows
You are SO ready for a Mac.
they could polish it just a little more for the average user.
Include a copy of PearPC?
The one after that won't be.
Not after the first time you couldn't get a call because your MP3 player had flattened your phone's batteries.
If you run the battery down on the iPod, you can still place a call on your cellphone.
What people seem to be forgetting is that service providers only want a phone with a music player if they can provide the music.
Yep. If you just want a phone with a music player, the Pocket PC Phone Edition has been out for a while. There's nothing new in that capability, and it's definitely not an iPod killer. Not even an iPod Shuffle killer. If it was, that would already have happened.
I've already been in Bill's fantasy world. The results of being able to play MP3s on my Pocket PC Phone edition was that the battery in the phone was flat when I needed to use it as a phone.
But only once.
I solved the problem of music flattening the battery on my phone by not using it as anything but a phone. It's an easy and obvious solution, and works well. It's also the solution to the problem of using my phone as a handheld videogame or an e-book reader and having THAT flatten the battery. You can tell when you're onto something when you solve one problem and it takes care of a bunch of others.
I solved the problem of having a phone that actually crashed and had to reboot by getting a simple phone that was just a phone. AND it got better battery life still. It's amazing how that works out.
Try something as simple as moving the window widgets (eg close button) to the right side.
Mind if I repeat something I wrote a couple of messages back: "These apps don't just change the window borders, they change every detail of every control in every application."
Hey, having the ability to change from one window manager to another is a really neat idea. It lets people install Enlightenment and think they're customizing the user interface, because they can customize the window borders in ways no sane person would dream of. But they're not, they're just customizing one application.
On the Mac that particular application is less customizable, at least in that way. But others are more so. For example, you can go in to any regular Cocoa application and a lot of Carbon ones and move *all* the widgets around, rename or move menu items, even copy them from one part of the program to another.
Also, the method for theming in OSX is a hack. You can see the results of this -- some applications get past shapeshifter without being themed.
If I open up an xterm... you know what, it doesn't use my Qt theme! Why is that? Is it because Qt theming is a hack, or is it because it's using Athena Widgets instead of Qt? Of course nobody would say Qt theming was a hack, but the fact is there's so many competing toolkits on X11 that this is normal and expected. There's nothing you can do about it except to exterminate all the competitors (you have to provide your own cyborgs).
In Mac OS X, on the other hand, there are only two official toolkits... so the theming that's built into it at a low level is well supported, and every app that uses Carbon, Cocoa, or even many of the third-party toolkits (because they look up the theme and follow it) will follow the themes.
I'd imagine he (or she) was saying something along the lines of...
You don't have to imagine. The text is right there.
If they would just shut the hell up then we could look at Apple as what they are, a passive OSS user.
You have obviously never looked at how companies that are really passive open source software users behave. Microsoft, for example.
Right now Apple is putting some really interesting code out there for people to pick up. They've provided a framework in darwin for completely changing the way UNIX systems are managed, in nicely packaged tools like launchd, complete with "configure" scripts ready for dropping in peicemeal or packaging for debian or Red Hat.
There's a whole damned revolution waiting on opensource.apple.com and nobody's paying attention to it. Why? because it's from Apple? because nobody knows it's there? Because it's not the Linux Way? I don't know. You tell me.
Apple has always imposed the most limits on the user's ability to customize his computer look and feel of any OS.
Actually, Mac OS X is extremely customizable down to a very low level. Apple doesn't give you a nice GUI for making these changes, because they consider the look and feel a brand, but neither have they made any deliberate effort to prevent people from providing the missing components. In fact, if they didn't hold their developers responsible for maintaining that look and feel it would be harder to go in and modify the GUI.
The company that is currently doing the most to take advantage of and develop the various hooks Apple has provided is Unsanity, and Shapeshifter is the premier tool of this type:
http://www.unsanity.com/haxies/shapeshifter
But there's also an open source project:
http://themechanger.sourceforge.net/
And there have been other applications going all the way back to Kaleidoscope on Mac OS 8. These apps don't just change the window borders, they change every detail of every control in every application... and Kaleidoscope did it first.
Patch dumps clearly aren't the preferred form according to the original developers.
OK, would this be better: how about a complete compilable source tree with changes specific to Apple's code marked out with ifdefs?
The LGPL says that changes have to be returned in the "preferred form" for exactly this reason
OK, I'm trying to figure out a definition of "the preferred form" that means "compatible with a toolkit they're not even using". Because that's a huge problem... the changes Apple's made involve porting what started out as KHTML to a completely different API, and no matter how frequently Apple released the patches, or in what sized chunks they released the patches, they'd still be full of changes related to the fact that Apple's APIs have evolved along a completely separate path from X11 for their entire lives. Carbon's API can be traced all the way back to the original Macintosh, and Cocoa is based on the NeXT ObjectiveC + Adobe Display Postscript code... and there's only one X11 toolkit that either of those APIs have any relationship at all with, and it's neither of the Big Two.
The only way to keep that from being a problem would be to have both projects agree to a common API for the GUI, and stick to it.
Do you honestly see that happening? Especially since the best compromise technically would involve the KDE people switching to GNUstep.
the GPL would have prevented all this
The GPL would have prevented Apple from releasing their divergent source tree in a way that the KDE people couldn't use it? I'm not sure I understand... I don't recall anything in the GPL that would have obligated Apple to do anything they're not already doing.
That could actually be kind of cool. If Apple has to release patches that are compatible with a toolkit they're not actually using, then does that mean KDE would have to do the same thing? That would be one way to untangle the incestuous web of internal dependencies that keep the KDE and Gnome worlds apart. I vote for using GNUstep as the glue layer.
Apple just spit on their courtesy
Are you honestly saying that Apple deliberately made their patches as hard as possible to deal with out of malice? Or are you just using a provocative phrase because you're upset that it hasn't worked out the way you expected, and whether Apple was honestly trying to be helpful despite their rapidly diverging source tree or not you feel justified in taking your disappointment out on them?
if your Linux system is going to be hacked [...]
If my Linux system is going to be hacked, even if the guy doesn't have a rootkit that'll work on me I'm going to have to reinstall anyway.
And yes, there's Linux software you can't easily port to OS X (or FreeBSD, or Solaris, or Tru64, or HPUX...), but then there's Linux software you can't run on PPC because it's binary-only... so you're still better off with an x86 Linux box.
Sugar-coated or not, however, it is still a restriction and places the license outside of the realm of Free Software licenses.
If having a restriction places a license outside the realm of free software licenses, then the only license that's free is placing the software in the public domain. EVERY other license places a restriction on the licensee, however light that restriction may be. Whatever other advantages it may give them indirectly, it still restricts their actions.
That's the whole purpose of retaining copyright and attaching a license.
The GPL established the precedent that you can have a significant restriction that's very broadly applicable, and still have that software be considered "free", if that restriction supported the goal of promoting the otherwise unencumbered use of free software. Well, the APSL has a restriction... but, you know what, that restriction ALSO supports that goal. It would have been better, in fact, if it were broader and thus more restrictive.
If you think software patents are, on balance, a good thing... well, you might not like this conclusion. I don't know if that's your position, but it's certainly NOT the position of a significant number of the members of the FSF (certainly not the ones who are also members of the LPF). And if you want to convince pretty much anyone that the APSL is non-free, you're going to have to start by dealing with that.
Everything else is crap that's not even worth talking about.
... I guess you're a Windows user then.
Without open source software there would be no Mac OS X, no Safari, no Dashboard,
Yeh, for a long time I was able to get the same kind of value from the FreeBSD source tree when I was trying to deal with problems in early versions of Tru64 (Digital UNIX, OSF/1) as a network admin. It's not that you need this stuff that often, but when you need it it makes a BIG difference.
am I the only English major in the house
On Slashdot? Probably.
I'd love to know an x86 that comes in the same form factor as the mini with comparable performance.
... and wireless.
"paperback"? Well, maybe, if you count something half the size of a phonebook as a "paperback". But, yeh, it's pretty small thanks to its laptop technology. So let's see what you can get in the PC world if you use similar techniques...
Googling around it took me about a minute to find a 1.13 GHz Pentium III laptop for $530. That's a bit slower than a mini, but not by much, and that includes a display, keyboard, and mouse
Because people who post to slashdot [...] ARE likely to steal^H^H^H^H^Hviolate other copyrights.
Nice insinuation. How do you like this one?
"People who work for the RIAA ARE likely to pad their expense accounts and double-dip by claiming the expense on their own tax return."
Every time someone posts a GPL-violation story here, there's always an AC making this same comment with almost exactly the same wording, despite the fact that every time he makes it a bunch of people (1) point out that they are pro-GPL but don't engage in or promote violating music or video copyrights, (2) explain why there are legitimate reasons to oppose DRM that have nothing to do with the inconvenience it adds to playing illicitly acquired media, and (3) point to examples of successful online vendors that shun DRM... so even if the AC hasn't always read the followups he'd have to be deliberately remaining ignorant to miss them all.
I wonder whether he's being paid by Microsoft or the RIAA.
OK, fair enough. I was conflating "using LinuxPPC in production" with "using Linux on Mac in production".
Now you've pointed it out, it's obvious.
I found that Linux is well geared to developing applience like applications. [...]
All a good answer for "why Linux?".
But that's not the question. The question is "why Linux on a Mac?". The question is "why not x86 or x86_64?".
When you're testing software, it has to be in the environment that it will run on in production. If it's expected to run on Linux PPC, you test it on Linux PPC.
That just begs the question "why are you running LinuxPPC in production"?