The design posted says a watch with bluetooth, and the picture shows a color screen.
I wasn't talking about the silly designs posted, but about what you'd actually do to make an iPod watch.
you take a device the size of a shuffle,
No, you take a device the size of the shuffle's internal components, and build up from there. You use a mini-USB jack instead of the full-size USB plug that with the cap takes up about 1/5th of the Shuffle's volume all by itself. The shuffle isn't spectacularly small for a flash device, it's got plenty of room to shrink.
Fossil sells a full-on Palm III-compatible device that fits in a watch, including a higher-res LCD than you'd need with a touch screen!
Personally, I have certain expectations of my graphical operating systems, and in this day and age, those expectations include the ability to play sound and video out of the box.
"Play sound and video" is not equivalent to "embed video clips in a text document".
everybody complains that IE sent Netscape away?
I don't care, personally, about that... so long as IE had remained a web browser and was not embedded deeply into the OS in a way that makes it impossible to secure. Careless embedding is Microsoft's forte, and WMP is simply an example of the general problem.
The fact that Tk was built on top of and for Tcl and yet could be modified to support multiple different scripting languages, however clumsily, shows the design was fundamentally good. The implementation was less language independant than it could have been, but still good enough to let it work.
The fact that there has not been a single other GUI toolkit that has even tried to address the same problems, perhaps it's time to reconsider Tk.
Less than a year after mono 1.0 was released, beagle, muine, monodevelop, ikvm and other mono apps are in the top of the list of apps people want (see gnomefiles).
Given that I can't think of a single Gnome application I want to use, that's hardly a resounding compliment.
Figuring out how to make one that's light and easy to wear, has a reasonable amount of memory, bluetooth, a nice color screen, a convenient interface to your computer, and a price tag under $500-- that would be innovative.
For a watch?
Nah, the iPod Watch would be more like the iPod Shuffle then the iPod Photo. Take the existing shuffle chipset, which already has LCD support, and add a clock (the Shuffle doesn't have a clock, which is why you can't get your iPod Shuffle use logged with Audioscrobbler), and put the ring of controls around the bezel. To pause, gently squeeze the crystal. The on/off/shuffle/mode control would be at the crown position.
But really, this is no different than dependency problems in the FOSS world. Like a previous poster said, take away Gtk/Gnome and then try running a Gtk dependent app on a KDE-only setup, and you're fubared.
Not even vaguely bloody equivalent, Sunshine. If you took away MSVCRT40 and Word stopped working, and I said "word shouldn't be dependent on that", you'd be right to complain about a Gnome app needing a core Gnome library. But the WMP control isn't a core function of the OS, and the software shouldn't be dependent on it.
This would be like Firefox failing in some ugly way if the Quicktime plugin was missing.
Tk's API is one of the better attempts at the same simplification to GUI APIs that the UNIX shell and pipe/filter model was for CLI APIs. It's not nearly as successful, but it sure seems like a better approach than just about anything else I've used.
Wait and see until the new apps based on C# and mono become mainstream in linux distributions
There's other languages that have a couple of apps based on them without ever becoming anything more than "yet another bloody dependency".
And Mono looks to become the next great evil dependency salad. I can't wait.
I think the comment made by the just previous poster is an appropriate interpretation:
Somebody has to point out that the Windows infrastructure is such an unholy mess, Microsoft might have just botched the change they made for EU compliance.
Basically, if Word is written so that it breaks unpleasantly when the WMP components are missing, that's a bug in Word. This is similar to the design flaws in other Windows components that make them dependent on rather than merely enhanced by the HTML control.
Which is why you can't run Windows 2000 applications in Windows XP, right?
Your logic is backwards. It would make more sense if you'd said "Which is why you can't run Windows XP applications in Windows 2000, right?". Of course, if Microsoft didn't ship updates for Windows 2000 that get packaged with the applications (and occasionally cause DLL Hell as apps install patches that break older apps), you wouldn't be able to do that.
There is no way Microsoft can change.NET, such that it will be impossible for Mono to run.NET applications, that will not also make it impossible for.NET to run existing.NET applications.
Good thing I didn't suggest that. What I'm talking about is Microsoft introducing new APIs such that new applications which use them will not run on older unpatched versions of.NET (now at 25M and growing), and of course their new updated libraries won't work on Mono.
And if they include DRM components in the libraries it may actually be illegal (or legally unpleasant and expensive) to reverse-engineer them to keep Mono in sync.
This is and has been a standard tactic that Microsoft has used for twenty years now. The opposite tactic would of course not work, but that's not what I'm talking about and I can't imagine what you're bringing it up for.
Do they know what protein the gene in question codes for?
Is it possible that some similar protein is doing the same job, or some mechnism "patching" the defective protein? That is, are the "normalised" plants using the same mechanism to produce the same effect?
You must be a windows.net programmer if you're worried about that.
Them's fighting words.
We build mono as a development platform for use on free software systems: compatibility with the MS runtime is only a nice side effect of implementing a standard.
There are quite a lot of very nice development platforms on free software systems, from integrated environments like Squeak to libraries that can be linked with many languages, like Tk. They each have many things to recommend them. So far as I can tell the advantages to C# are that it's C-like, arguably better than other C-like languages, potentially faster than the typical Java implementation at some cost in security since it's not as well adapted to sandboxing, and compatible with something Microsoft is doing.
Other than that last point, there are so many excellent alternatives already in use that I can't see any anything but Microsoft compatibility as being the "killer app" for Mono.
1. If the DRM is weak enough that I can bypass it with modest effort but it's too onerous for large-scale abuse... something to encourage honesty, the equivalent of "rot13" or putting "nospam" in your email address. For example, burning a CD and then ripping it.
2. If the DRM only applies to a system that's cheap enough I can throw the whole system (software and hardware) away without worrying about the cost. Say, if you bought an album and you got a durable epoxy-potted MP3 player with the music in it, for the equivalent of a couple of bucks.
3. If it's more expensive, but the DRM operated as an escrow, say I bought the epoxy-potted MP3 player and it had a timer in it so that it'd start giving me the raw data after 17 years (or some reasonable compromise between copyright and fair use) and it cost me the equivalent of a popular CD now.
I suggest you try to write (or port) a simple program in Mono/C#/Gtk#, and see how more concise it is compared to something similar in C.
I suggest you try to port a simple program from C/C++/Java/C# to Lisp, Scheme, Tcl. Python, or Perl, and see how much more concise it is compared to something in a C-like language.
5. Microsoft controls.NET. If they see Mono actually cutting into their pie, they'll change.NET faster than Mono can keep up. This has been their policy for over 20 years now, it's not going to change.
However, the.NET framework really is pretty slick stuff (mostly ideas copied from JAVA). It isn't that bad anymore.
1. It's still Microsoft, they still have a policy of effectively encouraging bad developers by accomodating bad habits. Their only mechanism for fighting this seems to be to come up with a "new broom" API to try and sweep away the old mess every few years, and then fall back in the same old bad habits until they need another new API to keep the buzz going. DotNET appears to be another one of these, a bit more aggressively pushed than most.
2. They have for many years had this fascination with client-based security and the use of signed certificates instead of a healthy paranoia about code imported from untrusted sources. This has produced a recurring series of dramatic security failures that have turned Windows into a kind of toxic ecosystem for malware incubation DotNET carries this security model with it, somewhat cleaned up but still depending too much on the kindness of strangers.
3. The best way to eat into the Windows monopoly is by being better than Windows. Firefox didn't start taking down Internet Explorer by emulating it, warts and all (and don't for one moment believe that compatibility with.NET won't need that), but by doing a better job and avoiding the security nightmare mentioned in point 2 up there.
4. The white kool-aid is taking bites out of Microsoft, and they're already open-source friendly. If you need to copy something to fight Microsoft, copy something that's already fighting Microsoft.
Having seen some of the new Apple API's development stuff, I was blown away but what a company with a vision can do to leverage open source for development.
And there's already a working open-source project that's got an awful lot of source-code compatibility with them.:)
it has always been VERY easy to develop applications for Windows.
It's very easy to develop badly behaved applications for Windows.
The only reason that Windows applications run as well as they do is because Microsoft has traditionally bent over backwards to accomodate bad behaviour.
Unless Miguel's committed to duplicating that kind of codependant regime as well as the API, it doesn't matter whether there's millions of.NET programmers or not.
And there's fewer.NET programmers than Microsoft thinks. They claim they'yre finally droping support for VB6, for example... I wonder if it'll "take" this time.
If you want to attract good programmers who are used to coding to the API instead of having it propped up accomodate their bugs, upgrade GNUstep and track Cocoa and Mac OS X...
Apple's iTunes client adds the DRM because it needs the client to generate the key.
It needs something derived from the key to do the encryyption, you mean, and the key lives in the client.. so the design is slightly easier this way.
Doing it any other way would likely be a tremendous processor increase on the iTunes servers.
Other DRM schemes, including all the eBook schemes I know of, do it in the server. And CPU time is cheap: I'll bet there's more CPU use in a gooogle search, and that's "free".
The way I see it, there's only one safe path for Apple.
Do the encryption in the server.
Like I said before, if they do it right, Jon can't 'break' them. That's apparently too big an 'if'.
Slashdot Mirror
The design posted says a watch with bluetooth, and the picture shows a color screen.
I wasn't talking about the silly designs posted, but about what you'd actually do to make an iPod watch.
you take a device the size of a shuffle,
No, you take a device the size of the shuffle's internal components, and build up from there. You use a mini-USB jack instead of the full-size USB plug that with the cap takes up about 1/5th of the Shuffle's volume all by itself. The shuffle isn't spectacularly small for a flash device, it's got plenty of room to shrink.
Fossil sells a full-on Palm III-compatible device that fits in a watch, including a higher-res LCD than you'd need with a touch screen!
Personally, I have certain expectations of my graphical operating systems, and in this day and age, those expectations include the ability to play sound and video out of the box.
"Play sound and video" is not equivalent to "embed video clips in a text document".
everybody complains that IE sent Netscape away?
I don't care, personally, about that... so long as IE had remained a web browser and was not embedded deeply into the OS in a way that makes it impossible to secure. Careless embedding is Microsoft's forte, and WMP is simply an example of the general problem.
Tk [...] is so tied to Tcl
The fact that Tk was built on top of and for Tcl and yet could be modified to support multiple different scripting languages, however clumsily, shows the design was fundamentally good. The implementation was less language independant than it could have been, but still good enough to let it work.
The fact that there has not been a single other GUI toolkit that has even tried to address the same problems, perhaps it's time to reconsider Tk.
Less than a year after mono 1.0 was released, beagle, muine, monodevelop, ikvm and other mono apps are in the top of the list of apps people want (see gnomefiles).
Given that I can't think of a single Gnome application I want to use, that's hardly a resounding compliment.
Figuring out how to make one that's light and easy to wear, has a reasonable amount of memory, bluetooth, a nice color screen, a convenient interface to your computer, and a price tag under $500-- that would be innovative.
For a watch?
Nah, the iPod Watch would be more like the iPod Shuffle then the iPod Photo. Take the existing shuffle chipset, which already has LCD support, and add a clock (the Shuffle doesn't have a clock, which is why you can't get your iPod Shuffle use logged with Audioscrobbler), and put the ring of controls around the bezel. To pause, gently squeeze the crystal. The on/off/shuffle/mode control would be at the crown position.
'IE is part of the Windows Operating System so that parts of the OS and other applications can rely on the functionality and APIs being present.
The functionality is dangerous and the APIs make security inherently impossible to achieve.
THAT is why having IE as part of the OS is a problem. Bringing up the "hidden APIs" issue is just muddying the waters.
But really, this is no different than dependency problems in the FOSS world. Like a previous poster said, take away Gtk/Gnome and then try running a Gtk dependent app on a KDE-only setup, and you're fubared.
Not even vaguely bloody equivalent, Sunshine. If you took away MSVCRT40 and Word stopped working, and I said "word shouldn't be dependent on that", you'd be right to complain about a Gnome app needing a core Gnome library. But the WMP control isn't a core function of the OS, and the software shouldn't be dependent on it.
This would be like Firefox failing in some ugly way if the Quicktime plugin was missing.
Tk was nice 8 years ago.
UNIX was nice 30 years ago. It's still nice.
Tk's API is one of the better attempts at the same simplification to GUI APIs that the UNIX shell and pipe/filter model was for CLI APIs. It's not nearly as successful, but it sure seems like a better approach than just about anything else I've used.
Wait and see until the new apps based on C# and mono become mainstream in linux distributions
There's other languages that have a couple of apps based on them without ever becoming anything more than "yet another bloody dependency".
And Mono looks to become the next great evil dependency salad. I can't wait.
I think the comment made by the just previous poster is an appropriate interpretation:
Somebody has to point out that the Windows infrastructure is such an unholy mess, Microsoft might have just botched the change they made for EU compliance.
Basically, if Word is written so that it breaks unpleasantly when the WMP components are missing, that's a bug in Word. This is similar to the design flaws in other Windows components that make them dependent on rather than merely enhanced by the HTML control.
Which is why you can't run Windows 2000 applications in Windows XP, right?
.NET, such that it will be impossible for Mono to run .NET applications, that will not also make it impossible for .NET to run existing .NET applications.
.NET (now at 25M and growing), and of course their new updated libraries won't work on Mono.
Your logic is backwards. It would make more sense if you'd said "Which is why you can't run Windows XP applications in Windows 2000, right?". Of course, if Microsoft didn't ship updates for Windows 2000 that get packaged with the applications (and occasionally cause DLL Hell as apps install patches that break older apps), you wouldn't be able to do that.
There is no way Microsoft can change
Good thing I didn't suggest that. What I'm talking about is Microsoft introducing new APIs such that new applications which use them will not run on older unpatched versions of
And if they include DRM components in the libraries it may actually be illegal (or legally unpleasant and expensive) to reverse-engineer them to keep Mono in sync.
This is and has been a standard tactic that Microsoft has used for twenty years now. The opposite tactic would of course not work, but that's not what I'm talking about and I can't imagine what you're bringing it up for.
you specific exactly what types of access each type of application gets, and the best part is you don't need to be a sysadmin guru to use it.
What, no "security zones"?
how to treat applications that originate locally, intranet, trusted internet, and untrusted internet.
Oh. Well, I hate to tell you, but this doesn't help.
The "security zone" model is inherently broken, can't be fixed, and we will see cross-zone exploits hitting DotNET.
Do they know what protein the gene in question codes for?
Is it possible that some similar protein is doing the same job, or some mechnism "patching" the defective protein? That is, are the "normalised" plants using the same mechanism to produce the same effect?
given that most OSS developers still use C/C++, I'd say a move to C# is still a positive thing.
That's like going out in the rain so you can replace your dandruff problem with a cold.
Once you're done, you've got dandruff *and* a cold. Once you're done, you've got Mono *and* C++.
You must be a windows .net programmer if you're worried about that.
Them's fighting words.
We build mono as a development platform for use on free software systems: compatibility with the MS runtime is only a nice side effect of implementing a standard.
There are quite a lot of very nice development platforms on free software systems, from integrated environments like Squeak to libraries that can be linked with many languages, like Tk. They each have many things to recommend them. So far as I can tell the advantages to C# are that it's C-like, arguably better than other C-like languages, potentially faster than the typical Java implementation at some cost in security since it's not as well adapted to sandboxing, and compatible with something Microsoft is doing.
Other than that last point, there are so many excellent alternatives already in use that I can't see any anything but Microsoft compatibility as being the "killer app" for Mono.
I personally detest Perl, but you can sure write concise Perl code. It may be unreadable and cryptic, but it's $ure $_{as->hell}%concise.
1. If the DRM is weak enough that I can bypass it with modest effort but it's too onerous for large-scale abuse... something to encourage honesty, the equivalent of "rot13" or putting "nospam" in your email address. For example, burning a CD and then ripping it.
2. If the DRM only applies to a system that's cheap enough I can throw the whole system (software and hardware) away without worrying about the cost. Say, if you bought an album and you got a durable epoxy-potted MP3 player with the music in it, for the equivalent of a couple of bucks.
3. If it's more expensive, but the DRM operated as an escrow, say I bought the epoxy-potted MP3 player and it had a timer in it so that it'd start giving me the raw data after 17 years (or some reasonable compromise between copyright and fair use) and it cost me the equivalent of a popular CD now.
I suggest you try to write (or port) a simple program in Mono/C#/Gtk#, and see how more concise it is compared to something similar in C.
I suggest you try to port a simple program from C/C++/Java/C# to Lisp, Scheme, Tcl. Python, or Perl, and see how much more concise it is compared to something in a C-like language.
5. Microsoft controls .NET. If they see Mono actually cutting into their pie, they'll change .NET faster than Mono can keep up. This has been their policy for over 20 years now, it's not going to change.
However, the .NET framework really is pretty slick stuff (mostly ideas copied from JAVA). It isn't that bad anymore.
.NET won't need that), but by doing a better job and avoiding the security nightmare mentioned in point 2 up there.
1. It's still Microsoft, they still have a policy of effectively encouraging bad developers by accomodating bad habits. Their only mechanism for fighting this seems to be to come up with a "new broom" API to try and sweep away the old mess every few years, and then fall back in the same old bad habits until they need another new API to keep the buzz going. DotNET appears to be another one of these, a bit more aggressively pushed than most.
2. They have for many years had this fascination with client-based security and the use of signed certificates instead of a healthy paranoia about code imported from untrusted sources. This has produced a recurring series of dramatic security failures that have turned Windows into a kind of toxic ecosystem for malware incubation DotNET carries this security model with it, somewhat cleaned up but still depending too much on the kindness of strangers.
3. The best way to eat into the Windows monopoly is by being better than Windows. Firefox didn't start taking down Internet Explorer by emulating it, warts and all (and don't for one moment believe that compatibility with
4. The white kool-aid is taking bites out of Microsoft, and they're already open-source friendly. If you need to copy something to fight Microsoft, copy something that's already fighting Microsoft.
Why not combine GNUstep and MONO.
.NET, how each is built, how they work, the languages and APIs they're built around.
It'd be even more fun than a Klingon-Esperanto dialect.
I guess you haven't looked at GNUstep and
Having seen some of the new Apple API's development stuff, I was blown away but what a company with a vision can do to leverage open source for development.
:)
And there's already a working open-source project that's got an awful lot of source-code compatibility with them.
it has always been VERY easy to develop applications for Windows.
.NET programmers or not.
.NET programmers than Microsoft thinks. They claim they'yre finally droping support for VB6, for example... I wonder if it'll "take" this time.
It's very easy to develop badly behaved applications for Windows.
The only reason that Windows applications run as well as they do is because Microsoft has traditionally bent over backwards to accomodate bad behaviour.
Unless Miguel's committed to duplicating that kind of codependant regime as well as the API, it doesn't matter whether there's millions of
And there's fewer
If you want to attract good programmers who are used to coding to the API instead of having it propped up accomodate their bugs, upgrade GNUstep and track Cocoa and Mac OS X...
I've met more actual people who have tried and loved GNUstep in real life than Mono.
That's because GNUstep is based on something that doesn't suck.
(sugar-free white kool-aid)
Rip, mix, burn is what you do to a CD. Get it stright. :)
And as someone else commented, it's not limited to 5 times.
That SHOULD be all the nudge-nudge-wink-wink you need, sheesh.
Apple's iTunes client adds the DRM because it needs the client to generate the key.
It needs something derived from the key to do the encryyption, you mean, and the key lives in the client.. so the design is slightly easier this way.
Doing it any other way would likely be a tremendous processor increase on the iTunes servers.
Other DRM schemes, including all the eBook schemes I know of, do it in the server. And CPU time is cheap: I'll bet there's more CPU use in a gooogle search, and that's "free".
The way I see it, there's only one safe path for Apple.
Do the encryption in the server.
Like I said before, if they do it right, Jon can't 'break' them. That's apparently too big an 'if'.
Presumably, Microsoft doesn't add the encryption in the client the way Apple does.